On Thursday 07 July 2011, John Reiser wrote:
> > valgrind --tool=callgrind --ct-verbose=1 ...
>
> When I run callgrind and callgrind_annotate, then I don't understand
> the output. For instance, the connection between "73" and the number
> of actual dynamic calls to exit() is mysterious to me:
> =====
> $ valgrind --tool=callgrind /bin/date
> ==3790== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
> $ callgrind_annotate callgrind.out*
> Ir file:function
> 73 /usr/src/debug/glibc-2.13/stdlib/exit.c:exit [/lib64/libc-2.13.so]
The default for callgrind_annotate is to show self cost of the functions
for the given event types collected.
Thus, the "73" in the "Ir" column is the number of executed client instruction
inside of exit. It has nothing to do with the number of calls to exit.
Actually, callgrind_annotate only prints the number of calls for call arcs,
which are displayed e.g. with "--tree=caller":
> callgrind_annotate --tree=caller callgrind.out*
...
7,060 < ???:0x0000000000401d60 (1x) [/bin/date]
73 * /build/buildd/eglibc-2.13/stdlib/exit.c:exit
[/lib/x86_64-linux-gnu/libc-2.13.so]
...
This excerpt means that a function at "0x0000000000401d60" called
"exit" one time. It probably would be good to add a total call count number
for every function.
> For another instance, using the exact suggestion:
> $ valgrind --tool=callgrind --ct-verbose=1 /bin/date
> gives output such as:
> -----
> . . . > check_match.10789(0x3d, 0x5b, ...) [ld-2.13.so /
> 0x3d25a08a20]
> . . . .> strcmp(0x3d, 0x5b, ...) [ld-2.13.so / 0x3d25a16ac0]
> . . . . > strcmp(0x3d, 0x5b, ...) [ld-2.13.so / 0x3d25a16ac0]
> -----
> where the indicated parameters are nonsense,
Sure, it would be a nice feature!
But "--ct-verbose=..." is actually only for internal debugging, and
the output is not documented. The values show the stack content
(interpreted as unsigned ints, as far as I remember) when entering the
function - which was enough at the time I needed the debug output.
> and a function whose body
> is a loop displays as a recursion.
Please tell me a way how to distinguish loops from tail recursion optimization
at machine code level, when the loop jumps back to the first instruction
of a function.
Often quite some meta information is thrown away, and there
is no way to exactly reconstruct what has happened at the source level.
So callgrind must use heuristics which sometimes can go wrong. For the
high-optimized code of strcmp above, this heuristic obviously goes wrong.
But without source code, your claim of existance of a loop in strcmp
could actually be wrong. It could have been coded as recursive function,
resulting in the same machine code.
> It is hard for me to trust such output.
Please tell me the reason why you started with the assumption that the
discovered output must be buggy.
Actually, to improve the trustworthiness, I added machine code annotation
to callgrind.
Josef
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
