Is gprof ever works on os4 ? It is! And can be still!

@All


EDIT: If anyone want to know how to make "gprof" works today on modern compilers read this: https://www.amigans.net/modules/xforum ... id=128257#forumpost128257



Is "gprof" even works on os4 ? I know in very beginning it works on pegasos2 , micro and co, but tried now on peg2 and micro and it seems don't work anymore.

Maybe anyone aware when it stop working, after which update, and maybe there an report about already or something ?

Thanks.

@kas1e

isn't it related to the x5000/debug/gdb/gcc issue?
newer gprof might need a newer glibc (the whole posix signal/timer thing). If you are compiling from source and you are using gcc 9/10/11 I would suspect that gprof stopped working somewhere between gcc 4 and gcc 8.

@trgswe
Quote:

Not sure, as far as I remember it works on pegasos2 and micros back in years, but now it definitely not on the same peg2 and micro (and that tested and by gcc 4,2, and by gcc8.x and by gcc 10.x).

If I remember right, someone some years ago complain about and even that there is some bug reported about, but i can't find it not on adtools (both old sourceforge link and new github one), and not in aos4 internal Bugzilla too

@kas1e

Might it have been this one?
https://github.com/sba1/adtools/issues/72

It's not gprof related at all, but it seems that profiling is broken all the way (on compiler level) anyway on our platform.

@Raziel

The amigaos 4.1 does lack the posix signals related to profiling (I should say does not implement them...) one would have to look how Linux has implemented them and do the same for amigaos 4.1 but someone at ?hyperion? would have to do that since it needs to be done officially (ssolie??) generally I would like to see Posix 2.x completely implemented somehow...

@Raziel
No, not this one. This one you point out is about a crash when performance monitor resource is not found (all new machines like x5000, sam460, etc). That crash was fixed on the newlib's side by Frederik some time ago. But only crashes were fixed, as it was just a null-pointer because performance monitor isn't implemented for newer machines.

The things i have problems with, is with whole thing which pretend to work before on older machines (such as pegasos2 , micros, etc, where perfomance monitor implemented).

On those older machines -pg created gmon.out file, all fine, but using gprof on it show nothing. So, want to know if gprof ever works on our side before on those old machines. As far as i know - it works before, just stopped work at some point. And there should be somewhere BZ about.

@kas1e

If I remember correctly, gprof worked in 2005 on BPPC :) I was trying to profile OpenMortal. I cannot remember GCC versions but game was uploaded to OS4Depot in October 2005.

kas1e summarized well the situation. gprof relies on many elements: compiler, libc (and with have 2 of them), performance monitor support, signals (?), gprof tool ... At the end, it seems that gprof worked a long time ago. We don't know when it stopped to work even on machines that are supposed to get it running well (I tested yesterday on my MicroAOne).

About the crash, Fredrik fixed it in newlib. The same should be done in clib2.

Let's collect more information but I think all that is not in a good shape.

But what we need, after all, is the profiling feature. For me, I can help on some points about gprof but I am clearly going to focus on improving my profiling tool, Hieronymus (yes, I know that in the past, I already said that and nothing was released).

Just to mention that I've just pushed a pull request in clib2 project to fix the crash. At least, that must be done whatever the status of gprof is.

It worked in the 4.0 era.. after some point it didn't work anymore. I remember i've used a lot for Mplayer on AmigaOne. However IIRC also the CPU needs to be supported by gprof. And for example AMCC 460ex isn't

@afxgroup
For example pegasos2 for sure supported, but didn't work for now.

I may try to install on pegasos2 the first version of OS4 which works on pegasos2 , to see if gprof works on, and if so, can find out step by step in which update it was broken, and then maybe there will be some luck to find out guilty component. But that of course hardcore a bit :)

@kas1e I'am afraid that would be a lot of work for a small benefit.

If it is really considered as necessary, I think this is the kind of feature to work on in an updated set of development tools (compiler, clib, binutils, ...).

@All

I create BZ about all the findings with non-working "gprof" on our side, there is:

https://github.com/sba1/adtools/issues/111

Maybe someone can contribute in findings what going wrong with it.

@all
Continue to investigate what is wrong with gprof, and find out that gprof have "--debug" options, so it shows a lot of in-the-middle info before throwing the final result.

So, there is a result for clib2 build and running gprof on it (which give us empty functions output in end):

https://kas1e.mikendezign.com/aos4/debug/gprof/clib2_debug.txt

And there to compare the same output for the same test case, but on Cygwin/x86 (which show info correctly):

https://kas1e.mikendezign.com/aos4/debug/gprof/debug_cygwin.txt

Did anyone see anything interesting?

So far what i can see now, is that in working (cygwin) gprof output we have things like:

Quote:

And

Quote:


But in our case, we didn't have at all that, but only:

Quote:

The next step which i want to do is just trying to create my own hand-made gmon.out, so to see, if the current gprof amigaos4 binary can handle at all gmon.out when there are "correct" values placed.

@kas1e
Quote:
The correctness of those values depends on the binary though. How would would you create such a file? I might be missing something here.

@sTix
Quote:

Of course native binary size/structs/sections/data need to be taken into account.

I will manually re-parse the whole structure of the gmon.out file (seems that old a.out format), understand what each field means and to what it a point, and then change the necessary data inside our already created gmon.out. I already made a very simple test case for cygwin, so it just 2 bytes of gmon.out, and will try to understand each byte of it, so to made manually one for os4.

Almost like i do there for Elf before:
https://wiki.amigaos.net/wiki/File:HackingWayPart1-3.png


Then, if it will work, and gprof will show anything at all in the empty fields we have now, it will mean that gprof itself is ok, and issue in the clib2's (and newlib too) aos4-profiling-specific code.

In the meantime, i also wrote to Thomas as it was him who add that to clib2 in 2005 as i can see from clib2 changelog (c.lib 1.194 (15.7.2005) ). So theoretically things should work if i will build with the very first versions of SDK (something like SDK 51.15 from 2005 as well) and use gprof from the same times. But anyway need to undertand what exactly guilty first.

@kas1e

Excellent, hardcore digging :)

@all
Ok, some very good news!

I installed the very first AmigaOS4 SDK from the year 2005 on today's version of AmigaOS4 with all the latest stuff. That was version 51.15 from 2004-2005 years.

It has inside GCC 3.4.4.

Now, if I build my test cases over that version of GCC with "-pg" and clib2 - then i can see profiling info via gprof ! But what is most important, i can see it not only via old gprof, but also via new, latest gprof!

But, not all that fancy-dancy. For first, all the results show 0.00% of the time. But at least show all the functions involved, etc ,etc. So everything looks ok for clib2 builds, just actual time is not meassured. That is the same if i check via old 2.14 gprov and via "new" 2.32.2 gprof.

For newlib builds things are different. Via gprof2.14 it shows nothing, almost the same empty stuff as we have now. Via gprof2.32.2 it shows all functions but not main() (in clib2 we have main(). And, all the values are also 0.00% and time didn't take into account.


By this we can say that:

1). Current kernel, os4 structures, etc, etc: all fine. Nothing hard-broken there, maybe just something shifts somewhere only or maybe some changes in the actual code need it. The kernel itself is ok. Until for x5000 kernel with performance monitor not released, all things can be checked on pegasos2/a1/etc where performance monitor works.

2). Current GPROF has no needs to be changed probably. It works as it. As i say i just tried one from old SDK (gprof v2.14) and one from the latest adtools (gprof v2.32.2) : and my gmon.out created with -pg over that old GCC are parsed the same (maybe even better in the case with newlib for example).

3). The changes which need to be done are profiling code in clib2 and maybe some BFD parts of Binutils (but that is unclear for now).


So, i will now install SDK by SDK, one by one, to see, when things start to be :

1). stop working to produce anything

2). when the timer start works (if it). Maybe on current kernel timer need to be changed in the profiling code of clib2/newlib, but that to be seen once i test more of old SDKs.

There i attach what i have from that test case : https://www.thegeekstuff.com/2012/08/gprof-tutorial/

compiled over newlib and clib2 via old gcc 3.4.4 and parsed via gprof2.14 (old one) and 2.32.2 (current):

gprof 2.14 clib2 from old 51.15 SDK:
https://kas1e.mikendezign.com/aos4/debug/gprof/gprof_2_14_clib2.txt

gprof 2.14 newlib from old 51.15 SDK:
https://kas1e.mikendezign.com/aos4/deb ... rof/gprof_2_14_newlib.txt

gprof 2.32.2 over the same clib2 from old SDK binary:
https://kas1e.mikendezign.com/aos4/deb ... of/gprof_2_32_2_clib2.txt

gprov 2.32.2 over the same newlib from old SDK binary:
https://kas1e.mikendezign.com/aos4/deb ... f/gprof_2_32_2_newlib.txt

And compare it with cygwin's current gprof output of the same test case:
https://kas1e.mikendezign.com/aos4/deb ... f/gprof_2_35_2_cygwin.txt

As can be seen, the one from the gprof 2.32.2 from Clib2 build is the same as Cygwin's current one, just the timer didn't work.

So, will try to find if Timer works at all anywhere in any older SDK in clib2 on our current AmigaOS.


EDIT1: SDK53.1 (the year 2008). Still working gmon.out/gprof, but still with 0.00% everywhere about a timer. Same missing "main" from newlib builds. Need to check on pegasos2, maybe the timer issue can be differences between different implementations of performance monitor?

EDIT2: SDK53.6 (the same year 2008)- gmon.out created, but gprof can't parse the output anymore.

So somewhere between SDK 53.1 and SDK53.6 something changes somewhere. Will find the guilty one tomorrow and will check the working one on pegasos2, to see if it x5000 issue only, or general with the latest os4.

ps. so the funny thing, that gprof seems don't work for about 14 years :)

@All
So the results are: in SDK 53.2 "-pg" switch works as expected and still outputs all the values, while in SDK 53.3 it stops working and starts to produce empty output. I tested created gmon.out from SDK 53.2 on Pegasos2 (with older performance monitor realization), and there all the timer stuff works. Everything profiles fine, and the timer works correctly. So things about 0.00% and no timer are related to the beta of performance monitor on x5000/tabor.

Interestingly, in both SDK 53.2 and SDK 53.3 we have GCC 4.2.4. So that not switch to newer GCC cause that, but something else (some changes in includes probably or something?) but i need to compare those 2 SDKs firstly.

That can be a kind of good sign IMHO, i was fear it's the GCC switch cause of that, so BFD issues and all that. But now it seems like something else.

So.. next steps are:

1). bug report to perfomance monitor on x5000/tabor
2). compare SDK 53.3 and 53.2 and find out what was changed and one by one replace SDKs components until things start working again => will find the guilty part.


The good thing is that on pegasos2 i test everything on the latest OS4 with all the latest components. Mean that fixes can be done by a 3d party (not for x5000/tabor through at moment, but it anyway in beta, so for the public maybe will be fixed too).

@All
Uh, that was hardcore, but find out which component starting from SDK 53.3 start to give issues with gprof: that is "ld" binary from GCC core.

If i just install 53.3 and replaced its "ld" by "ld" from 53.2, then i can compile with "-pg" binaries which on running create working gmon.out and which can be seen by any version of gprof.

Now .. interesting that "ld" from both SDKs are the same :
"GNU ld (Gnu Binutils) 2.18". But sizes are very different. The size of "ld" from the working SDK is 5.353.142. The size of "ld" from the next (and non-working) SDK are 1.130.076.

That is just because "ld" binary from working SDK is not stripped. Once I strip it out, then it starts to be 1.144.736, which is not 1.130.076 as from the next, non-working SDK. So changes were done for sure in that terms. And while the core, Binutils, and GCC are all of the same version, something was changed in "ld".

Now, need to think a bit about what to do next with all that finding.. Will be good to know what exactly changed in, but at moment can't find any changelog about (as those SDKs are too old, not sure they even save somewhere).

Maybe it's something about ld-scripts being in use by default.. That is also a good candidate to check. But pure replacing ones from working SDK didn't do the trick, and only replacing of "ld" binary make the trick.

Any ideas ?:)