main missing

[githubaf]

I try to get familiar with gprof profiling and use gprof2dot to visualize the results. The used gcc is a cross compiler that produces Amiga executables. gprof2dot produces pretty pictures for big projects.. Now I have an understanding problem. Please see the attached tiny example. In the produced picture I see no main(). Is that abug or am I doing something wrong?

gprof test | gprof2dot -n0 -e0 | dot -Tpng -o output.png && mirage output.png

granularity: each sample hit covers 2 byte(s) for 100.00% of 0.02 seconds

index % time    self  children    called     name
                                                 <spontaneous>
[1]    100.0    0.02    0.00                 strlen [1]
-----------------------------------------------
                0.00    0.00       1/1           main [53]
[2]      0.0    0.00    0.00       1         fct_1 [2]
                0.00    0.00       1/1           fct_2 [3]
-----------------------------------------------
                0.00    0.00       1/1           fct_1 [2]
[3]      0.0    0.00    0.00       1         fct_2 [3]
-----------------------------------------------

test.tar.gz

[jrfonseca]

There are 2 problems here:

• gprof couldn't figure out who called strlen. Perhaps because libc had no debug information, or due to some limitation with m68k architecture (e.g., no stack frame pointer by default)?

• gprof lists main as a caller (ie, an edge on the call graph), but didn't create a node for it in the report. No idea why. I never seen this with x86. Perhaps gprof's -c/--static-call-graph help.

Both issues are in gcc/gprof domain, not the gprof2dot tool. The missing main issue is minor IMO. But the strlen is a showstopper -- if time spent in libc functions is not accurately billed to the callers, then the whole graph will end up biased and useless.

I hope this helps.

[githubaf]

Thank you very much for the explaination! It's very much appreciated. I am sure it will help our m68k gprof.

Happy New Year!

[ildar]

I had main() missing on x86_64. But then I used alternative approach:

valgrind --tool=callgrind