|
From: Chris A. <ch...@at...> - 2004-03-11 19:54:12
|
Hi all, I started working on a code coverage skin for valgrind...Mostly as a learning project to see how valgrind works. A patch against current CVS can be found at: http://atlee.ca/coverage.patch.gz The skin is pretty stupid, it just records hits on instructions when it sees the INCEIP instruction. It also tries to do some conditional jump analysis. I've written a python script that will annotate source and show you what lines have been executed. Known bugs: - I get hits recorded in the middle of functions in completely unrelated files sometimes... - Really slow, it actually writes out to a file descriptor for every instruction hit...The skin should probably just maintain a list of line hits and write it all out at the end like cachegrind. Cheers, Chris |
|
From: Jeremy F. <je...@go...> - 2004-03-11 22:04:31
|
On Thu, 2004-03-11 at 11:43, Chris AtLee wrote: > Hi all, > > I started working on a code coverage skin for valgrind...Mostly as a > learning project to see how valgrind works. A patch against current CVS > can be found at: > http://atlee.ca/coverage.patch.gz > > The skin is pretty stupid, it just records hits on instructions when it > sees the INCEIP instruction. It also tries to do some conditional jump > analysis. I've written a python script that will annotate source and > show you what lines have been executed. Erm, wouldn't it be enough to just record each basic block? By definition, once you've run the first instruction, you're going to run all the rest (unless your code does *lots* of exceptions). That should reduce the rate of events quite a bit. > - Really slow, it actually writes out to a file descriptor for every > instruction hit...The skin should probably just maintain a list of line > hits and write it all out at the end like cachegrind. You might want to have a look at vgprof. I wrote it with the intention of making Valgrind interoperate with gprof by generating gprof-format files. Unfortunately, the gprof format is horrible and inextensible, so the only way it can work is by hacking gprof itself, which isn't fun. Anyway, you might get some ideas from it: http://www.goop.org/~jeremy/valgrind/12-vgprof.patch http://www.goop.org/~jeremy/valgrind/vgprof.html J |
|
From: Chris A. <ch...@at...> - 2004-03-11 22:16:07
|
On Thu, 2004-03-11 at 16:52, Jeremy Fitzhardinge wrote: > Erm, wouldn't it be enough to just record each basic block? By > definition, once you've run the first instruction, you're going to run > all the rest (unless your code does *lots* of exceptions). That should > reduce the rate of events quite a bit. What about conditional jumps? I'm not sure what constitutes a basic block, which is why I did it the way that I did. Cheers, Chris |
|
From: Tom H. <th...@cy...> - 2004-03-11 23:16:52
|
In message <1079042725.25599.209.camel@antigua>
Chris AtLee <ch...@at...> wrote:
> On Thu, 2004-03-11 at 16:52, Jeremy Fitzhardinge wrote:
> > Erm, wouldn't it be enough to just record each basic block? By
> > definition, once you've run the first instruction, you're going to run
> > all the rest (unless your code does *lots* of exceptions). That should
> > reduce the rate of events quite a bit.
>
> What about conditional jumps? I'm not sure what constitutes a basic
> block, which is why I did it the way that I did.
Any sort of jump will end a basic block. That's what a basic block
is - a chunk of code that is always executes to the end once it has
started, at least if you exclude processor exceptions.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Josef W. <Jos...@gm...> - 2004-03-14 00:15:03
|
Am Thursday 11 March 2004 22:52 schrieb Jeremy Fitzhardinge: > On Thu, 2004-03-11 at 11:43, Chris AtLee wrote: > > Hi all, > > > > I started working on a code coverage skin for valgrind...Mostly as a > > learning project to see how valgrind works. A patch against current CVS > > can be found at: > > http://atlee.ca/coverage.patch.gz > > > > The skin is pretty stupid, it just records hits on instructions when it > > sees the INCEIP instruction. It also tries to do some conditional jump > > analysis. I've written a python script that will annotate source and > > show you what lines have been executed. Stupid question: Can't you use Cachegrind for this? > You might want to have a look at vgprof. I wrote it with the intention > of making Valgrind interoperate with gprof by generating gprof-format > files. Unfortunately, the gprof format is horrible and inextensible, so > the only way it can work is by hacking gprof itself, which isn't fun. So better use Cachegrind format? You will get source annotation for free (using cg_annotate or KCachegrind). I found the Cachegrind file format to be astonishing flexible to use for different purposes (in contrast to my own extensions .-). And it is quite space saving because of ASCII (!), too: No need to store 8 bytes for a 64 bit counter in a binary format, as most of the counters are small numbers. Josef > > Anyway, you might get some ideas from it: > http://www.goop.org/~jeremy/valgrind/12-vgprof.patch > http://www.goop.org/~jeremy/valgrind/vgprof.html > > J > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2004-03-14 11:14:19
|
On Sun, 14 Mar 2004, Josef Weidendorfer wrote: > > > The skin is pretty stupid, it just records hits on instructions when it > > > sees the INCEIP instruction. It also tries to do some conditional jump > > > analysis. I've written a python script that will annotate source and > > > show you what lines have been executed. > > Stupid question: Can't you use Cachegrind for this? Yes, I think the --show=Ir option will give you it. > > You might want to have a look at vgprof. I wrote it with the intention > > of making Valgrind interoperate with gprof by generating gprof-format > > files. Unfortunately, the gprof format is horrible and inextensible, so > > the only way it can work is by hacking gprof itself, which isn't fun. > > So better use Cachegrind format? You will get source annotation for free > (using cg_annotate or KCachegrind). > I found the Cachegrind file format to be astonishing flexible to use for > different purposes (in contrast to my own extensions .-). And it is quite > space saving because of ASCII (!), too: No need to store 8 bytes for a 64 bit > counter in a binary format, as most of the counters are small numbers. Main problem with using Cachegrind for coverage is that it's massive overkill -- it will run much slowler than necessary because of all the cache simulation stuff. 2nd problem is that you can't aggregate counts over multiple runs of a program. Enough people have asked about coverage that I wonder if it's worth doing properly with a separate tool? Jeremy's VGProf is a good start, but requiring a patched gprof is not nice. N |
|
From: Josef W. <Jos...@gm...> - 2004-03-14 20:59:54
|
Am Sunday 14 March 2004 12:14 schrieb Nicholas Nethercote: > Main problem with using Cachegrind for coverage is that it's massive > overkill -- it will run much slowler than necessary because of all the In calltree, I did some optimization for this case. Use --simulate-cache=no, and it will skip instrumentation for every instruction, and thus quite fast. > cache simulation stuff. 2nd problem is that you can't aggregate counts > over multiple runs of a program. Enough people have asked about coverage KCachegrind does this if you load multiple dumps together. It should be no problem to provide a PERL script to do this for 2 cachegrind files. > that I wonder if it's worth doing properly with a separate tool? Jeremy's > VGProf is a good start, but requiring a patched gprof is not nice So if we want to do a seperate tool for this, I vote for the ASCII cachegrind format. I think that for coverage, you *need* also the number of distinct instruction never touched. Currenty, Cachegrind does not do this. Josef > . > > N |
|
From: Nicholas N. <nj...@ca...> - 2004-03-15 14:08:07
|
On Sun, 14 Mar 2004, Josef Weidendorfer wrote: > I think that for coverage, you *need* also the number of distinct instruction > never touched. Currenty, Cachegrind does not do this. Oh, yeah. And that's hard to find, since it never instruments code it never sees Maybe it could be done somehow in the post-annotation script. N |
|
From: Josef W. <Jos...@gm...> - 2004-03-15 19:39:01
|
On Monday 15 March 2004 15:07, Nicholas Nethercote wrote:
> On Sun, 14 Mar 2004, Josef Weidendorfer wrote:
> > I think that for coverage, you *need* also the number of distinct
> > instruction never touched. Currenty, Cachegrind does not do this.
>
> Oh, yeah. And that's hard to find, since it never instruments code it
> never sees Maybe it could be done somehow in the post-annotation script.
I made a small skin for this some time ago, which translates all basic blocks
with debug info into UCode using VG_(disBB), and writes out a cachegrind.out
file for instructions found. Unfortunately, I had to do
=========================================
...
/* functions from valgrind core not found in vg_skin.h ;-( */
extern UCodeBlock* VG_(alloc_UCodeBlock) ( void );
extern Int VG_(disBB) ( UCodeBlock* cb, Addr eip0 );
/* Expandable arrays of uinstrs. */
struct _UCodeBlock {
Addr orig_eip;
Int used;
Int size;
UInstr* instrs;
Int nextTemp;
};
...
cb = VG_(alloc_UCodeBlock)();
cb->orig_eip = addr;
size = VG_(disBB)(cb, addr);
...
============================================
Opinions on putting
VG_(alloc_UCodeBlock)(Addr orig_eip)
VG_(disBB) ( UCodeBlock*, Addr)
into vg_skin.h ?
Josef
>
> N
|