[Valgrind-developers] Skin (Tool) for static information about ELF objects...

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

Hi,

to let KCachegrind act as code coverage tool, I need a cachegrind.out file
covering all instructions with source line debug info of an ELF object (say 
event type "DIr" for "distinct instruction fetches"). Together with real 
cachegrind data (i.e. type "Ir"), this can be combined to show the percentage 
of executed code to all code
by specifying a derived cost type "(Ir>0 @Instr) / DIr".

For this, I use profile data granularity at instruction level (this is an 
extension of the original cachegrind format). Thus, "Ir>0 @ Instr" is a 
threshold operator acting at instruction level, i.e. this cost metric is 1 
(=true) for every instruction executed at least once. The "/" (ratio 
operator) is always applied last, i.e. for a file/object/function/line you 
get this way the ratio of all distinct instructions executed at least once to 
all distinct instructions of that file/... . This should be the correct 
notion for code coverage, shouldn't it?
BTW, to get a coverage metric on line granularity, I would use
"(Ir>0 @ Line) / (DIr>0 @ Line)".

I just wrote a skin to get data covering the full code of an ELF object, see 
attached file. It is working quite fine with VG 2.0.0, but it's a little ugly 
as e.g. VG_(disBB) isn't exported to skins (and the structure UCodeBlock) ;-(
Doing this with objdump and a small script is unfortunately not possible, as 
objdump can't cope with DWARF-2 debug line info (?).
The file can be loaded in KCachegrind 0.4.x, but derived metrics with above 
operators is currently not possible.

Can you comment on my approach?

Note: it would be by far more efficient if there would be iterators for line 
debug info...

Aside from that, I added event types "DInt" and "DFp" for distinct integer/
float arithmetic instructions. Unfortunately, this is totally screwed. It's 
not working with SSE/MMX, and even multiply is not recognized as this is
translated to calls to helper functions.

But events "MrSize" and "MwSize" (size of memory read/write accesses of an 
instruction) should be quite interesting: In combination with cachegrind 
data, e.g. "Dr * MrSize" gives you the amount of all memory read accesses 
issued by a function, and together with the cycle estimation, we get an 
estimation for the bandwidth.

Josef