|
From: Josef W. <Jos...@gm...> - 2003-11-18 00:30:03
Attachments:
sg_main.c
|
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 |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 16:31:12
|
On Tue, 18 Nov 2003, Josef Weidendorfer wrote: > 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? I would if I understood it! Am I right in thinking that you want KCachegrind to give a code coverage figure, ie. percentage of code exercised? Apart from that I'm confused: - this "(Ir>0 @Instr) / DIr" stuff is confusing me, I don't understand your notation - what is a "distinct instruction fetch", how does it differ from an "instruction fetch"? - er, just generally not understanding Maybe you could try re-explaining using shorter words and sentences? I'm feeling dim today :) N |