[Valgrind-developers] Callgrind for VG 3.0.x (Beta1)

[Josef W. <Jos...@gm...>]

Hi,

finally, I have a version which should work quite well with VG 3.0.x,
both on x86 and AMD64.

Please try it out from
 http://kcachegrind.sourceforge.net/callgrind-0.9.13-VG30-beta1.tar.gz
I'm very interested in any feedback.

Note that recently, I released a standalone KCachegrind bugfix version,
which should compile fine on AMD64.

Fixes:
* Correct Ir counts (when cache simulation is switched off) and
correct generation of jump arrow info. You can check this out with

 callgrind --dump-instr=yes --collect-jumps=yes <app>

and look at KCachegrinds assembler annotation. E.g. "_dl_elf_hash"
should look fine now (a BB of this function is an example of VEX
generating a BB with 5 exits).

* Correct handling of REP instructions (first in the history of Callgrind!).
Example of REP on x86 (and probably on x86_64, too) can be found in memcpy.
E.g. if cx=0 for a repz with memory access, the simulator will show
Ir=1, but D=0. For this, I added a few more simulator calls (like 0I1Dr).

* Better call graph generation with calls into the runtime linker, avoiding
cycles (this previously went wrong on x86_64; the hack for x86 is removed).
This works with special handling for "_dl_runtime_resolve": this function
gets a flag "simulate a jump into another function via RET and CALL"
(short: "pop-on-jump"). Checking for this function name does not work
with newer glibc, as this function is not exported any more.
When running callgrind/KCachegrind, and you do not see this function
(but big cycles), look for the caller of "__libc_start_main". This
should look like "0x0000000000ABCDEF". For further callgrind run,
use "--pop-on-jump=0x0000000000ABCDEF" as further argument.
Better would be to use GOT[1], as John Reiser pointed out, as this
has to contain a pointer to runtime_resolve, according to the ABI.
I will look into this before the release.

Josef