Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
62 user(s) are online (39 user(s) are browsing Forums)

Members: 0
Guests: 62

more...

Headlines

 
  Register To Post  

« 1 (2) 3 4 5 »
Re: Is gprof ever works on os4 ?
Just popping in
Just popping in


See User information
@kas1e

Good catch. My guess is that those two are built from different revisions of the patch sets found here:

https://sourceforge.net/p/adtools/code/254/log/?path=%2Ftrunk

As you can see they aren't exactly small and the commit messages aren't very descriptive.

The question is who built the SDK:s, and if that someone can be found, does he know what revisions he used?

This is all guesswork though, perhaps the patches used are hidden on some defunct harddrive somewhere in a landfill in central Europe.

Go to top
Re: Is gprof ever works on os4 ?
Not too shy to talk
Not too shy to talk


See User information
@kas1e

ld source code may be the same v2.18 ... just a small change to the include files can make huge diffrense on how it compiles and optimizes.. ie diffrent file size.

“The best thing about a boolean is even if you are wrong, you are only off by a bit.”
Go to top
Re: Is gprof ever works on os4 ?
Home away from home
Home away from home


See User information
@sTix
At least we move somewhere :) My bet is that "ld" in "working" SDK and "non-working" sdk just have inbuild use of different ldscripts (because simple copy of ldscripts from one SDK to another didn't help). That can explain the different size of created test-binary and of gmon.out. All those ld-scripts are for pointing out to linker how binary need to be constructed: what sections, etc, etc. So very possible that there things go wrong.

And i think we need to take into action that no one will find anything, and we are on our own.

And good find in the history of Sourceforge! I am good at that kind of thing like building revision by revision and checking what happens (i.e. stupid, routine, time-consuming work). We may try to build one revision my one. And check what happens.

Or, we can try to see if there is any change in the commits about "ld-scripts" and related parts in the "ld" code.

For now, i will try to get out all from the verbose logs of "ld", to see if there are any differences. Maybe things will be that simple like different use of different ldscripts.


@rwo
Quote:

ld source code may be the same v2.18 ... just a small change to the include files can make huge diffrense on how it compiles and optimizes.. ie diffrent file size.


Yeah, i know... Need to find what exactly causes our gprof issues in all "ld" since SDK 51.3

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ?
Home away from home
Home away from home


See User information
@All

Soo... I just go verbose mode, and just do "ld -verbose", and that what we have:

ld from SDK 53.2:
https://kas1e.mikendezign.com/aos4/debug/gprof/ld_SDK_53_2.txt

ld from SDK 53.3:
https://kas1e.mikendezign.com/aos4/debug/gprof/ld_SDK_53_3.txt

What i can see there is that those things changes:

Line 16/17 with "PROVIDE". There start address changes. Before it was 0x0000000 when things work, then it start to be 0x100000000.

Also in "working" version we have 2 more sections in .text segment : .rela.got1 and .rela.got2 (see lines 49 and 50 in the 53.2 version).

Also line around 90-95, ALIGN string also have changed.

Then some other changes on lines from 150 to 160 about sections/segments/etc

And then lines 190-200 changes about ALIGN as well.

So that is what causes those things: binary changes. Start address, alignment, and some sections for sure. And as it all comes from LD-Scripts, i assume i can try to change it somehow manually to find out exactly what part is the guilty one, and then it will be easer to deal with.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ?
Just popping in
Just popping in


See User information
@kas1e

Quote:

Added a COMMONPAGE define which has an effect to how the internal linker scripts are populated. Binaries that are produced now with the internally scripts use much less diskspace. I hope that this doesn't have any bad side effects.

Revision: 335
Date: 2010-05-12 21:19
State: Added
Branch: trunk
Author: sba


In amigaos.sh:

Quote:

#. ${srcdir}/emulparams/elf32ppccommon.sh
TEMPLATE_NAME=amigaos
SCRIPT_NAME=amigaos
OUTPUT_FORMAT="elf32-amigaos"
MAXPAGESIZE="CONSTANT (MAXPAGESIZE)"
++ COMMONPAGESIZE="CONSTANT (COMMONPAGESIZE)"
ALIGNMENT=16
ARCH=powerpc
MACHINE=
GENERATE_SHLIB_SCRIPT=yes


Maybe, maybe.


Go to top
Re: Is gprof ever works on os4 ?
Home away from home
Home away from home


See User information
@sTix
There i see "Date: 2010-05-12 21:19" , but things got broken in SDK 53.3, and all files inside 11/13/2008 (not sure though if we can trust those dates of course, maybe on Sourceforge they were reuploaded or something)

And next commit to what you point out set the new version for adtools: (adtools build 20100512)", while both ld binaries and working one and broken one, coming from SDKs both of which have "adtools build 20080706".

I also checked the dates of both "ld" binary from SDK 53.2 and 53.3: The working one was built 10/20/2008, and the non-working one was built 11/13/2008.

So just 23 days of commits should tell us something. Only to find the correct dates, as seems SourceForge ones a bit shifted seems so. Then if nothing is understandable from logs, i will try to compile version perversion to find out the guilty commit.


Edited by kas1e on 2022/1/21 19:59:08
Edited by kas1e on 2022/1/21 20:02:28
Edited by kas1e on 2022/1/21 20:19:07
Edited by kas1e on 2022/1/21 20:19:37
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ?
Home away from home
Home away from home


See User information
@sTix
I go commit per commit, to see when "adtools build 20080706" version changes in sourceforge repo, and the first one was :
commint 180:
https://sourceforge.net/p/adtools/code ... unk/gcc/gcc/version.c#l11


Then it was "20080706" till commit 231 included:
https://sourceforge.net/p/adtools/code ... unk/gcc/gcc/version.c#l11


So, between those 2 commits, we have 2 different SDK releases, in the first of which ld works, and after about a month - not.

The only question is if those commits contain aos4 changes at all. Or they just were applied after on top of something and those actual changes which were done for SDK are not here. Or they were applied just much later (already changed..).

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ?
Just popping in
Just popping in


See User information
@kas1e

True, no SDK:s come from the future. Almost only binutils changes between 180 and 231 it seems. No OS4 specific changes in binutils though. Some of it is obviously 68k, but I can't tell if there are generic Amiga changes in there as well.

Go to top
Re: Is gprof ever works on os4 ?
Home away from home
Home away from home


See User information
@sTix
It looks like that before sba commit the things, os4 version of SDK comes from patches "hidden on some defunct harddrive somewhere in a landfill in central Europe". Changelog of them probabaly lost. Then, Sebastian just add what he got as last code from brothers and so already "changed" probabaly right after broken ld are in ..

I wrote mail to Sebastan with all details asking for info if he remember any or so, will see what he say.

But what is for sure, is that we can try just in current compiler try to mimic what working ld giving us, just for test, and if it works, then we can dig in deeper to those changes to know why/when/for_what and maybe can find the better solution.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ?
Just popping in
Just popping in


See User information
@kas1e

Quote:
It looks like that before sba commit the things, os4 version of SDK comes from patches "hidden on some defunct harddrive somewhere in a landfill in central Europe". Changelog of them probabaly lost. Then, Sebastian just add what he got as last code from brothers and so already "changed" probabaly right after broken ld are in ..

I wrote mail to Sebastan with all details asking for info if he remember any or so, will see what he say.


Let's hope Sebastian remembers something. But it's a long long time to remember things like this.

Digging into binutils is a major mental challenge, it's a really depressing place to be :)


Go to top
Re: Is gprof ever works on os4 ?
Home away from home
Home away from home


See User information
@sTix
Another good progress!

I found that by default, "ld" has its own inbuild ldscript. I.e. just inside of "ld". And usually, that is the same script which we have in the SDK/gcc/ppc-amigaos/lib/ldsript/amigaos.x

You even can see in the binutils-cross-build-2.23.2/ld/eamigaos.c there are parts of that inbuild ldscript (search for "Default linker script").

Now, all that I do is just take the default "amigaos.x" ld-script from SDK 53.2 (when things work), and use that ld script manually with 53.3 SDK (when things do not work) and now even with the very latest SDK: and everything works! I mean with current LD etc. So issues id 100% in the default-inbuild linker script (or, an issue that things were forgotten to be changed in profile code of clib2, when internal ld-script were changed).

Through to provide manually ld-script a bit of pain, but for the tests more than enough, that how i compile it with working ld-script now:

Quote:

gcc -mcrt=clib2 -pg -c test_gprof.c
gcc -mcrt=clib2 -pg -c test_gprof_new.c
ld -T amigaos.x_53_2 --eh-frame-hdr --defsym __amigaos4__=1 -Bstatic -q -d -V -Qy -L/SDK/clib2/lib -o test_gprof_clib2_new_linker_script83 /SDK/clib2/lib/crtbegin.o /SDK/clib2/lib/crt0.o -L/gcc/lib/gcc/ppc-amigaos/4.2.4 test_gprof.o test_gprof_new.o -lprofile --start-group -lc --end-group -L/SDK/gcc/lib/gcc/ppc-amigaos/4.2.4/clib2/lib -lgcc -lgcc_eh /SDK/clib2/lib/crtend.o


And newly generated gmon.out by -pg from latest/current GCC works! I can see everything.

Now, what we need, is alter that ld-script bit by bit, so to find out what string exactly causes the differences. My bet is still as i expect from the beginning: the size of binary and shifting of sections cause in some field of gmon.out at the begining have wrong size => issues. Once we find out what exactly, then things can be fixed easy.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ?
Just popping in
Just popping in


See User information
@kas1e

Wow, fantastic. I admire your digging skills and patience :)

Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Site Builder
Site Builder


See User information
@kas1e
Awesome work Roman.
Those files are common in different gcc versions, right?

Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Home away from home
Home away from home


See User information
@sTix
Thanks, but that is only the beginning: now need to find what exactly causes issues, and how to fix them properly inside of the clib2 profiling code. But at least "bad routine" work done, and things start to be interesting now, yep.

Btw, if you check : https://github.com/sodero/clib2/blob/m ... brary/profile_gmon.c#L248

See there GetElfAttrsTags + GetSectionHeaderTags.. So constructions of gmon.out is definitely based on the structure of the binary itself and its fields. We only need to find what is wrong in terms of the current ldscript with that code.


@george
Quote:

Those files are common in different GCC versions, right?

Those ld-scripts come with the linker, yes, but they are different from SDK to SDK (depends on what was changed in the linker and related code, or when Binutils were changed, etc). And internal, inbuild, default linker-script also different depending on what was changed, etc.

GCC's Linker by itself it's just a command language taking linker scripts and building output binaries depending on the statements/etc in the scripts. Those scripts told how to build binaries in one or another situation (like default one, when -N options set, or -pie, or -r, etc, etc). Through default one, while coming separately in ldscripts directory, also inbuild inside of the linker too. Dunno why maybe to avoid setting it manually all the time.

Now what we found is that construction of the binary by ldscript from sdk 53.2 make generated gmon.out be correct one, while making a binary with all ld-scripts after that SDK build gmon.out which are bad. But all the linker scripts coming after were altered to have less size of binary, etc, etc, so just after some change to make a binary better gprof checking was missed by accident by SDK team probably, then no one uses it for some time, and once reports arise probably was too late to remember what can cause it.

For now, need to find what exactly changes in the ldscript started to cause that issue, and then, the clibs2 profiling code needs to be changed/fixed (depends on what we found and what exactly cause this issue). And then newlib too need to be adapted accordingly.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Home away from home
Home away from home


See User information
@sTix
Found, line 11 of SDK/gcc/ppc-amigaos/lib/ldsript/amigaos.x. The working was one when there were 0x00000000 in 2 places, and it did not work when it 0x01000000 in 2 places.

I just now take GCC 8.3.0, grab ldscript from, change only this line, rebuild with manually specific this ld-script and gprof are fine with.

Now to understand what is wrong with the code in gmon_out.c of clib2 profile, that elfheader data return something bad that broken gmon parsing.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


See User information
@kas1e

In revision 267 TEXT_START_ADDR=0x01000000 was added to binutils/ld/emulparams/amigaos.sh. Before there was no such entry, which maybe, perhaps, maybe results in a default value of 0x00000000.

In binutils/ld/emulparams/amigaos.sh TEXT_START_ADDR is explicitly set to 0x00000000.

The commit message in rev 267 and 265 says that the changes come from Hans-Joerg and Thomas Frieden. On other words the changes might be older than what the SVN log indicates which means that it might be included in the SDK from 2008. This is pure speculation though.

Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Home away from home
Home away from home


See User information
@All
So, to make things short, if anyone wants _RIGHT NOW_ to use gprof for profiling their amigaos4 binaries, you need

1). Have a machine with "performance monitor" working (Pegasos2, Eyetech's Amigaones and Classics. In beta also x5000 and Tabor, and soon should be x1000 as well)

2). In your SDK find the main "ld" binary (on native SDK installation that is in SDK:gcc/bin/ld, on cross-compiler setup that is /usr/local/amiga/bin/ppc-amigaos-ld.exe). Make a copy. Then in hex-editor (i use Zaphod), find the words "Default linker script, for normal executables" that will be only in one place. Next, you can see after about 160 bytes this string: "PROVIDE (__executable_start = 0x01000000); . = 0x01000000 + SIZEOF_HEADERS;". There you change in 2 places 0x01000000 on 0x0000000 i.e. you just delete "1" in addresses and put "0" instead). Now, every binary you will be compiled with those changes (binary will work, but how bad is it to have that change in the system meaning that unknown, but binary still works, and you can profile it). So you can have 2 copies of "ld" binary, one when you just need profiling working, and another one when you just need the "usual" binary.

3). After you patch LD you then build your binary with "-pg" and "-gstabs". You can use _only_ clib2 build as newlib's profiling code seems wasn't implemented properly (even the tests with old working SDK 53.2 from year 2008 show that and it is the same now as well).

To build clib2 build will be:

Quote:

ppc-amigaos-gcc -mcrt=clib2 -pg -gstabs test_gprof.c test_gprof_new.c -o test_gprof_clib2 -lprofile


4). It will create "gmon.out" file for you after you exit from your program, and then you just run "gprof name_of_binary".

Gprof can be used of any version (even the latest one from GCC 11.x). And SDK can be used the latest one and GCC too, just with the latest GCC you will have warning errors from gprof that "dwarf5 is not supported, only 2,4,5" but that harmless, profiling info is still there.


Now to raise the interest, if you on cross-compiler, you can use some python script called gprof2dot.py from https://github.com/jrfonseca/gprof2dot. The purpose of that script is to convert the output from many profilers into a dot graph (including gprof, of course). For that script to be used you need the "dot" command which is part of Graphviz packages (which I do not know if we have natively, but pure "dot" command for sure possible to port natively, so after a bit of work that can be used natively as well).

It can make from your profiling info all kinds of graphs, but i love colorful ones. Check some examples to see how important for us to have gprof working:

basic test case:
https://www.thegeekstuff.com/2012/08/gprof-tutorial/


output:
https://kas1e.mikendezign.com/aos4/debug/gprof/test_gprof_clib2.txt

graph (press open in new tab for full size):
Resized Image

Tequila from Capehill (yeah, profile the profiler) :
https://github.com/capehill/tequila


output:
https://kas1e.mikendezign.com/aos4/debug/gprof/tequila.txt

graph (press open in new tab for full size):
Resized Image

Horny app from Timo (that big one, yeah, binary 1.5 mb of size):
https://github.com/kas1e/midi-sequencer-amigaos


output:
https://kas1e.mikendezign.com/aos4/debug/gprof/horny.txt

graph (press open in new tab for full size):
Resized Image


Btw, from graphs, you can see straight away that in Horny not the main() is the "main" body used, but some "haupt()" function, which if you check the source code of Horny is it (so at least that part our profiler from clib2 take surely correct).

So.. What else needs to be done for "proper" gprof support:

1). Understand what is all about 0x01000000 vs 0x0000000 and fix it properly does not matter where it needs to be done.

2). Fix in X5000/Tabor performance monitor so clib2 profiler will work there too

3). Fix newlib profiler to make it work as expected (at least as in clib2 at minimum)

So that is not the end for now, but at least everyone who needs gprof right now can use it if have a necessary machine.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


See User information
@kas1e

Very nice. What happens if you build with the unpatched ld and add '-Ttext=0x0000000' when building?

What is the output from the following 3 commands:

> nm file_built_with_patched_ld
> nm file_built_with_normal_ld
> nm file_built_with_normal_ld_plus_text_option

Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Home away from home
Home away from home


See User information
@sTix
Quote:

What happens if you build with the unpatched ld and add '-Ttext=0x0000000' when building?


Works too ! I just do that:
ppc-amigaos-gcc -mcrt=clib2 -Ttext=0x0000000 -pg -gstabs test_gprof.c test_gprof_new.c -o test_gprof_clib2 -lprofile


And it works!


Quote:

> nm file_built_with_patched_ld


0001a600 d ____chdir_exit_dtor
0001a700 B __alloca_cleanup
00006850 T __allocate_memory
00000001 A __amigaos4__
0001a5e0 d __arg_init_ctor
0001a698 B __argc
0001a69c B __argv
0001a64c D __break_signal_mask
0001a660 D __bss_start
0001a650 D __cache_line_size
00007a38 t __chdir_exit_dtor
00004ce0 T __check_abort
0001a648 D __check_abort_enabled
0001a6bc B __check_detach
000014c0 T __close_all_files
0001a5f4 d __CTOR_LIST__
0001a5d8 d __CTOR_LIST__
0001a6f6 B __current_directory_changed
0001a6d8 B __current_memory_allocated
0001a6d0 B __current_num_memory_chunks_allocated
0001a658 D __default_pool_size
0001a65c D __default_puddle_size
0001a6c0 B __detach
0001a6c2 B __disable_dos_requesters
0001a688 B __dl_elf_handle
00007ae4 T __drop_iob_read_buffer
0001a614 d __DTOR_LIST__
0001a5f8 d __DTOR_LIST__
0001a690 B __ElfBase
0001ab20 B __end
0001a678 B __exit_blocked
0001a778 B __exit_jmp_buf
000062cc T __exit_trap_trigger
0001a640 D __exit_value
0001a664 B __fd
00007c10 T __fd_hook_entry
0000634c T __find_memory_node
00008ab8 T __floatundidf
00005010 T __flush
00005090 T __flush_all_files
000051d0 T __flush_iob_write_buffer
00005320 T __fputc
000052a8 T __fputc_check
000064a0 T __free_memory
00006354 T __free_memory_node
0001a6f0 B __free_memory_threshold
0001a6c4 B __get_default_stack_size
00005538 T __get_file_descriptor
00005590 T __get_file_descriptor_dont_resolve
000055dc T __grow_fd_table
000057bc T __grow_iob_table
0001a68c B __IElf
00008488 T __initialize_fd
0000850c T __initialize_iob
0001a66c B __iob
00006114 T __iob_hook_entry
0001a6c8 B __is_resident
0001a6a8 B __IUtility
0001a6dc B __maximum_memory_allocated
0001a6d4 B __maximum_num_memory_chunks_allocated
00000444 T __mcount
0001aa18 B __memory_list
0001a6cc B __memory_pool
0001a67c B __minimum_os_lib_error
0001a680 B __minimum_os_lib_version
0001a6b8 B __no_standard_io
0001a660 B __num_fd
0001a668 B __num_iob
0001a6f8 B __original_current_directory
0000a14c r __PRETTY_FUNCTION__.0
000079ac T __print_termination_message
0001a644 D __priority
0001a684 B __process_name
00000ed8 T __profiler_exit
00000eac T __profiler_init
0001a6e0 B __program_name
000085d0 T __remove_fd_alias
00008a98 T __safe_examine_file_handle
000085b8 T __safe_parent_of_file_handle
00006d74 T __set_errno
000037c8 T __set_process_window
0001a654 D __shell_escape_character
00003ad0 T __show_error
0001a628 D __signal_handler_table
0001a6b0 B __signals_blocked
00006d80 T __slab_allocate
0001aa28 B __slab_data
000078b4 T __slab_exit
00007468 T __slab_free
0000779c T __slab_init
0001a6e4 B __slab_max_size
0001a6e8 B __slab_purge_threshold
0001a67a B __stack_overflow
0001a694 B __stack_size
0001a608 d __stdio_exit_dtor
0001a5e4 d __stdio_file_init_ctor
0001a5e8 d __stdio_init_ctor
0001a6ec B __stdio_window_specification
0001a60c d __stdlib_memory_exit_dtor
0001a5ec d __stdlib_memory_init_ctor
0001a610 d __stdlib_program_name_exit_dtor
0001a5f0 d __stdlib_program_name_init_ctor
000042ac T __swap_stack_and_call
000086f0 T __translate_access_io_error_to_errno
00008684 T __translate_io_error_to_errno
00008afc T __udivdi3
00008ebc T __umoddi3
0001a6f4 B __unlock_current_directory
0001a6ac B __UtilityBase
0001a6b4 B __WBenchMsg
0001a604 d __workbench_exit_dtor
0001a618 D _DATA_BASE_
0001a660 D _edata
0001ab20 B _end
00002da4 T _exit
00002dd0 T _Exit
00000134 T _fini
0001a710 B _gmonparam
00000074 T _init
0000307c T _main
000003d8 T _mcount
00000444 t _mcount_end
00022640 D _SDA_BASE_
000001e0 T _start
0000619c T abort
00003db0 t arg_init_ctor
000061d8 T atexit
0001a884 b atexit_blocked
00002f5c t call_main
00004c50 T close
00002e84 t close_libraries
0000a434 r console_prefix.1
0000a448 r console_suffix.0
0001a760 b CounterInt
00000edc T CounterIntFn
00002f58 t detach_cleanup
0001a674 B DOSBase
0001a860 b elf_handle
0001a6fc B errno
00002dfc T 
exit
0001a88c b exit_node_table
0001aa0c b exit_trap_list
00004e90 T fclose
00001394 T fprintf
00005408 T fputc
00008318 T fputs
0000659c T free
0001aa24 b free_program_name
000001e4 T func1
00000260 t func2
00000f70 T GetCounterStart
0001a670 B IDOS
0001a6a0 B IExec
0001a87c b input
0001a744 b IPM
0001a708 b j.0
0001a864 b local_signals_blocked.0
000037a0 T longjmp
000002d8 T main
00006a58 T malloc
0000a49c r map_table.0
0000876c T memcpy
00004328 T memmove
0000488c T memset
00000634 T moncleanup
000005b0 T moncontrol
00000834 T mongetpcs
00000b08 T monstartup
00000360 T new_func1
0001a888 b num_exit_nodes_used
0001a86c b old_console_task
0001a874 b old_input
0001a878 b old_output
0001a880 b output
00001038 T profil
0001a748 b ProfileData
000015b8 T puts
00004d58 T raise
0001a868 b restore_console_task
0001a870 b restore_streams
0001a70c b s_scale
00003788 T setjmp
000037e0 T shared_obj_exit
000038e8 T shared_obj_init
000015b4 t stdio_exit_dtor
00005aa0 t stdio_file_init_ctor
00001470 t stdio_init_ctor
0000675c t stdlib_memory_exit_dtor
000066cc t stdlib_memory_init_ctor
00006d14 t stdlib_program_name_exit_dtor
00006c64 t stdlib_program_name_init_ctor
00004ba8 T strcat
00004bf0 T strcpy
00004c24 T strlen
0001a6a4 B SysBase
0001ab1c b termination_message_printed.0
000017fc T vfprintf
0000599c t workbench_exit_dtor




Quote:

> nm file_built_with_normal_ld

0001a600 d ____chdir_exit_dtor
0001a700 B __alloca_cleanup
00006850 T __allocate_memory
00000001 A __amigaos4__
0001a5e0 d __arg_init_ctor
0001a698 B __argc
0001a69c B __argv
0001a64c D __break_signal_mask
0001a660 D __bss_start
0001a650 D __cache_line_size
00007a38 t __chdir_exit_dtor
00004ce0 T __check_abort
0001a648 D __check_abort_enabled
0001a6bc B __check_detach
000014c0 T __close_all_files
0001a5f4 d __CTOR_LIST__
0001a5d8 d __CTOR_LIST__
0001a6f6 B __current_directory_changed
0001a6d8 B __current_memory_allocated
0001a6d0 B __current_num_memory_chunks_allocated
0001a658 D __default_pool_size
0001a65c D __default_puddle_size
0001a6c0 B __detach
0001a6c2 B __disable_dos_requesters
0001a688 B __dl_elf_handle
00007ae4 T __drop_iob_read_buffer
0001a614 d __DTOR_LIST__
0001a5f8 d __DTOR_LIST__
0001a690 B __ElfBase
0001ab20 B __end
0001a678 B __exit_blocked
0001a778 B __exit_jmp_buf
000062cc T __exit_trap_trigger
0001a640 D __exit_value
0001a664 B __fd
00007c10 T __fd_hook_entry
0000634c T __find_memory_node
00008ab8 T __floatundidf
00005010 T __flush
00005090 T __flush_all_files
000051d0 T __flush_iob_write_buffer
00005320 T __fputc
000052a8 T __fputc_check
000064a0 T __free_memory
00006354 T __free_memory_node
0001a6f0 B __free_memory_threshold
0001a6c4 B __get_default_stack_size
00005538 T __get_file_descriptor
00005590 T __get_file_descriptor_dont_resolve
000055dc T __grow_fd_table
000057bc T __grow_iob_table
0001a68c B __IElf
00008488 T __initialize_fd
0000850c T __initialize_iob
0001a66c B __iob
00006114 T __iob_hook_entry
0001a6c8 B __is_resident
0001a6a8 B __IUtility
0001a6dc B __maximum_memory_allocated
0001a6d4 B __maximum_num_memory_chunks_allocated
00000444 T __mcount
0001aa18 B __memory_list
0001a6cc B __memory_pool
0001a67c B __minimum_os_lib_error
0001a680 B __minimum_os_lib_version
0001a6b8 B __no_standard_io
0001a660 B __num_fd
0001a668 B __num_iob
0001a6f8 B __original_current_directory
0000a14c r __PRETTY_FUNCTION__.0
000079ac T __print_termination_message
0001a644 D __priority
0001a684 B __process_name
00000ed8 T __profiler_exit
00000eac T __profiler_init
0001a6e0 B __program_name
000085d0 T __remove_fd_alias
00008a98 T __safe_examine_file_handle
000085b8 T __safe_parent_of_file_handle
00006d74 T __set_errno
000037c8 T __set_process_window
0001a654 D __shell_escape_character
00003ad0 T __show_error
0001a628 D __signal_handler_table
0001a6b0 B __signals_blocked
00006d80 T __slab_allocate
0001aa28 B __slab_data
000078b4 T __slab_exit
00007468 T __slab_free
0000779c T __slab_init
0001a6e4 B __slab_max_size
0001a6e8 B __slab_purge_threshold
0001a67a B __stack_overflow
0001a694 B __stack_size
0001a608 d __stdio_exit_dtor
0001a5e4 d __stdio_file_init_ctor
0001a5e8 d __stdio_init_ctor
0001a6ec B __stdio_window_specification
0001a60c d __stdlib_memory_exit_dtor
0001a5ec d __stdlib_memory_init_ctor
0001a610 d __stdlib_program_name_exit_dtor
0001a5f0 d __stdlib_program_name_init_ctor
000042ac T __swap_stack_and_call
000086f0 T __translate_access_io_error_to_errno
00008684 T __translate_io_error_to_errno
00008afc T __udivdi3
00008ebc T __umoddi3
0001a6f4 B __unlock_current_directory
0001a6ac B __UtilityBase
0001a6b4 B __WBenchMsg
0001a604 d __workbench_exit_dtor
0001a618 D _DATA_BASE_
0001a660 D _edata
0001ab20 B _end
00002da4 T _exit
00002dd0 T _Exit
00000134 T _fini
0001a710 B _gmonparam
00000074 T _init
0000307c T _main
000003d8 T _mcount
00000444 t _mcount_end
00022640 D _SDA_BASE_
000001e0 T _start
0000619c T abort
00003db0 t arg_init_ctor
000061d8 T atexit
0001a884 b atexit_blocked
00002f5c t call_main
00004c50 T close
00002e84 t close_libraries
0000a434 r console_prefix.1
0000a448 r console_suffix.0
0001a760 b CounterInt
00000edc T CounterIntFn
00002f58 t detach_cleanup
0001a674 B DOSBase
0001a860 b elf_handle
0001a6fc B errno
00002dfc T 
exit
0001a88c b exit_node_table
0001aa0c b exit_trap_list
00004e90 T fclose
00001394 T fprintf
00005408 T fputc
00008318 T fputs
0000659c T free
0001aa24 b free_program_name
000001e4 T func1
00000260 t func2
00000f70 T GetCounterStart
0001a670 B IDOS
0001a6a0 B IExec
0001a87c b input
0001a744 b IPM
0001a708 b j.0
0001a864 b local_signals_blocked.0
000037a0 T longjmp
000002d8 T main
00006a58 T malloc
0000a49c r map_table.0
0000876c T memcpy
00004328 T memmove
0000488c T memset
00000634 T moncleanup
000005b0 T moncontrol
00000834 T mongetpcs
00000b08 T monstartup
00000360 T new_func1
0001a888 b num_exit_nodes_used
0001a86c b old_console_task
0001a874 b old_input
0001a878 b old_output
0001a880 b output
00001038 T profil
0001a748 b ProfileData
000015b8 T puts
00004d58 T raise
0001a868 b restore_console_task
0001a870 b restore_streams
0001a70c b s_scale
00003788 T setjmp
000037e0 T shared_obj_exit
000038e8 T shared_obj_init
000015b4 t stdio_exit_dtor
00005aa0 t stdio_file_init_ctor
00001470 t stdio_init_ctor
0000675c t stdlib_memory_exit_dtor
000066cc t stdlib_memory_init_ctor
00006d14 t stdlib_program_name_exit_dtor
00006c64 t stdlib_program_name_init_ctor
00004ba8 T strcat
00004bf0 T strcpy
00004c24 T strlen
0001a6a4 B SysBase
0001ab1c b termination_message_printed.0
000017fc T vfprintf
0000599c t workbench_exit_dtor



Quote:

> nm file_built_with_normal_ld_plus_text_option


0001a600 d ____chdir_exit_dtor
0001a700 B __alloca_cleanup
000067dc T __allocate_memory
00000001 A __amigaos4__
0001a5e0 d __arg_init_ctor
0001a698 B __argc
0001a69c B __argv
0001a64c D __break_signal_mask
0001a660 D __bss_start
0001a650 D __cache_line_size
000079c4 t __chdir_exit_dtor
00004c6c T __check_abort
0001a648 D __check_abort_enabled
0001a6bc B __check_detach
0000144c T __close_all_files
0001a5f4 d __CTOR_LIST__
0001a5d8 d __CTOR_LIST__
0001a6f6 B __current_directory_changed
0001a6d8 B __current_memory_allocated
0001a6d0 B __current_num_memory_chunks_allocated
0001a658 D __default_pool_size
0001a65c D __default_puddle_size
0001a6c0 B __detach
0001a6c2 B __disable_dos_requesters
0001a688 B __dl_elf_handle
00007a70 T __drop_iob_read_buffer
0001a614 d __DTOR_LIST__
0001a5f8 d __DTOR_LIST__
0001a690 B __ElfBase
0001ab20 B __end
0001a678 B __exit_blocked
0001a778 B __exit_jmp_buf
00006258 T __exit_trap_trigger
0001a640 D __exit_value
0001a664 B __fd
00007b9c T __fd_hook_entry
000062d8 T __find_memory_node
00008a44 T __floatundidf
00004f9c T __flush
0000501c T __flush_all_files
0000515c T __flush_iob_write_buffer
000052ac T __fputc
00005234 T __fputc_check
0000642c T __free_memory
000062e0 T __free_memory_node
0001a6f0 B __free_memory_threshold
0001a6c4 B __get_default_stack_size
000054c4 T __get_file_descriptor
0000551c T __get_file_descriptor_dont_resolve
00005568 T __grow_fd_table
00005748 T __grow_iob_table
0001a68c B __IElf
00008414 T __initialize_fd
00008498 T __initialize_iob
0001a66c B __iob
000060a0 T __iob_hook_entry
0001a6c8 B __is_resident
0001a6a8 B __IUtility
0001a6dc B __maximum_memory_allocated
0001a6d4 B __maximum_num_memory_chunks_allocated
000003d0 T __mcount
0001aa18 B __memory_list
0001a6cc B __memory_pool
0001a67c B __minimum_os_lib_error
0001a680 B __minimum_os_lib_version
0001a6b8 B __no_standard_io
0001a660 B __num_fd
0001a668 B __num_iob
0001a6f8 B __original_current_directory
0000a14c r __PRETTY_FUNCTION__.0
00007938 T __print_termination_message
0001a644 D __priority
0001a684 B __process_name
00000e64 T __profiler_exit
00000e38 T __profiler_init
0001a6e0 B __program_name
0000855c T __remove_fd_alias
00008a24 T __safe_examine_file_handle
00008544 T __safe_parent_of_file_handle
00006d00 T __set_errno
00003754 T __set_process_window
0001a654 D __shell_escape_character
00003a5c T __show_error
0001a628 D __signal_handler_table
0001a6b0 B __signals_blocked
00006d0c T __slab_allocate
0001aa28 B __slab_data
00007840 T __slab_exit
000073f4 T __slab_free
00007728 T __slab_init
0001a6e4 B __slab_max_size
0001a6e8 B __slab_purge_threshold
0001a67a B __stack_overflow
0001a694 B __stack_size
0001a608 d __stdio_exit_dtor
0001a5e4 d __stdio_file_init_ctor
0001a5e8 d __stdio_init_ctor
0001a6ec B __stdio_window_specification
0001a60c d __stdlib_memory_exit_dtor
0001a5ec d __stdlib_memory_init_ctor
0001a610 d __stdlib_program_name_exit_dtor
0001a5f0 d __stdlib_program_name_init_ctor
00004238 T __swap_stack_and_call
0000867c T __translate_access_io_error_to_errno
00008610 T __translate_io_error_to_errno
00008a88 T __udivdi3
00008e48 T __umoddi3
0001a6f4 B __unlock_current_directory
0001a6ac B __UtilityBase
0001a6b4 B __WBenchMsg
0001a604 d __workbench_exit_dtor
0001a618 D _DATA_BASE_
0001a660 D _edata
0001ab20 B _end
00002d30 T _exit
00002d5c T _Exit
000000c0 T _fini
0001a710 B _gmonparam
00000000 T _init
00003008 T _main
00000364 T _mcount
000003d0 t _mcount_end
00022640 D _SDA_BASE_
0000016c T _start
00006128 T abort
00003d3c t arg_init_ctor
00006164 T atexit
0001a884 b atexit_blocked
00002ee8 t call_main
00004bdc T close
00002e10 t close_libraries
0000a434 r console_prefix.1
0000a448 r console_suffix.0
0001a760 b CounterInt
00000e68 T CounterIntFn
00002ee4 t detach_cleanup
0001a674 B DOSBase
0001a860 b elf_handle
0001a6fc B errno
00002d88 T 
exit
0001a88c b exit_node_table
0001aa0c b exit_trap_list
00004e1c T fclose
00001320 T fprintf
00005394 T fputc
000082a4 T fputs
00006528 T free
0001aa24 b free_program_name
00000170 T func1
000001ec t func2
00000efc T GetCounterStart
0001a670 B IDOS
0001a6a0 B IExec
0001a87c b input
0001a744 b IPM
0001a708 b j.0
0001a864 b local_signals_blocked.0
0000372c T longjmp
00000264 T main
000069e4 T malloc
0000a49c r map_table.0
000086f8 T memcpy
000042b4 T memmove
00004818 T memset
000005c0 T moncleanup
0000053c T moncontrol
000007c0 T mongetpcs
00000a94 T monstartup
000002ec T new_func1
0001a888 b num_exit_nodes_used
0001a86c b old_console_task
0001a874 b old_input
0001a878 b old_output
0001a880 b output
00000fc4 T profil
0001a748 b ProfileData
00001544 T puts
00004ce4 T raise
0001a868 b restore_console_task
0001a870 b restore_streams
0001a70c b s_scale
00003714 T setjmp
0000376c T shared_obj_exit
00003874 T shared_obj_init
00001540 t stdio_exit_dtor
00005a2c t stdio_file_init_ctor
000013fc t stdio_init_ctor
000066e8 t stdlib_memory_exit_dtor
00006658 t stdlib_memory_init_ctor
00006ca0 t stdlib_program_name_exit_dtor
00006bf0 t stdlib_program_name_init_ctor
00004b34 T strcat
00004b7c T strcpy
00004bb0 T strlen
0001a6a4 B SysBase
0001ab1c b termination_message_printed.0
00001788 T vfprintf
00005928 t workbench_exit_dtor


Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


See User information
@kas1e
Quote:
Works too ! I just do that:
ppc-amigaos-gcc -mcrt=clib2 -Ttext=0x0000000 -pg -gstabs test_gprof.c test_gprof_new.c -o test_gprof_clib2 -lprofile


And it works!


Brilliant. I guess you could ask the original authors if there's a good reason for having text at 0x01000000 and not at 0x00000000? Are the Friedens on a beta-tester mailing list of some sort?

But the output from 'nm file_built_with_normal_ld' seems identical to 'nm file_built_with_patched_ld'?


Go to top

  Register To Post
« 1 (2) 3 4 5 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project