|
From: Josef W. <Jos...@gm...> - 2005-10-02 20:23:54
|
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 |
|
From: Josef W. <Jos...@gm...> - 2005-10-02 23:06:34
|
On Saturday 01 October 2005 00:15, Josef Weidendorfer wrote: > 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. Is there an easy way to get GOT[1] from a tool? I can sweep through the whole segment, checking with VG_(seginfo_sect_kind)(Addr) for the first address returning Vg_SectGOT, but that seems like wasting of time, as gotstart is a member of SegInfo. VG probably should provide iterator functions to allow a tool to browse through available debuginfo (as PIN has). Currently, we only have this for SegInfo via VG_(next_seginfo). What about SectInfo* VG_(first_sectinfo)(const SegInfo*); SectInfo* VG_(next_sectinfo)(const SectInfo*); Addr VG_(sectinfo_start)(const SectInfo*); SizeT VG_(sectinfo_size)(const SectInfo*); VgSectKind VG_(sectinfo_kind)(const SectInfo*); ? Similar for source files, debug lines, function symbols, data symbols... Perhaps this is overkill, and it should be only added when a tool ever will need it, as it probably has overhead. Another way would be to provide hooks for a tool to be notified about a debug info entry when being loaded, like SK_gotSymbol(const SegInfo*, const SymbolInfo*) with VG_(symbolinfo_name/kind/start/size). The tool could return a boolean to request that the SymbolInfo should be allocated until the segment is discarded. I really would like to add a callgrind mode being able to provide the info how often some data structure was accessed from which code. For this, I need above way to build up a structure for fast mapping of data addresses to data structure names. What is the general opinion here? Josef > I will look into this before the release. > > Josef > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |