|
From: Bob R. <bo...@br...> - 2005-03-24 03:15:52
|
Hi, Has anyone considered adding a coverage tool to valgrind? It seems that it would be able to do this well. Also, how about a source level profiler (gprof replacement)? Has any work ever gone into researching these ideas? If this has been brought up before, and it was decided that these tools would not fit well into valgrind, please let me know. Thanks, Bob Rossi |
|
From: Jeremy F. <je...@go...> - 2005-03-24 05:52:45
|
Bob Rossi wrote:
>Hi,
>
>Has anyone considered adding a coverage tool to valgrind? It seems that
>it would be able to do this well.
>
>Also, how about a source level profiler (gprof replacement)?
>
>Has any work ever gone into researching these ideas?
>
>If this has been brought up before, and it was decided that these tools
>would not fit well into valgrind, please let me know.
>
>
I wrote a tool called "vgprof", which produced gprof-compatible(ish)
output. Unfortunately it has sadly aged. I've made a start as
resurrecting it, but it isn't there yet. One of the problems is that
the gprof file format is pretty broken, and its unclear that it is the
best to use; oprofile might be a better bet.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-24 14:57:16
|
On Wed, 23 Mar 2005, Jeremy Fitzhardinge wrote: >> Has anyone considered adding a coverage tool to valgrind? It seems that >> it would be able to do this well. >> >> Also, how about a source level profiler (gprof replacement)? >> >> Has any work ever gone into researching these ideas? >> >> If this has been brought up before, and it was decided that these tools >> would not fit well into valgrind, please let me know. > > I wrote a tool called "vgprof", which produced gprof-compatible(ish) > output. Unfortunately it has sadly aged. I've made a start as > resurrecting it, but it isn't there yet. One of the problems is that > the gprof file format is pretty broken, and its unclear that it is the > best to use; oprofile might be a better bet. As for coverage, Cachegrind can give you a crude form of coverage information, but it doesn't give percentage coverage. I believe Ben Elliston was looking at writing a coverage tool with Valgrind that would produce gcov-compatible output files. AIUI, one of the difficulties is that gcov output is done on a basic block basis, and Valgrind's notion of a basic block is subtly different from that of a compiler's. The Valgrind 3.0 series will use the new dynamic binary translator Vex, which translates multiple basic blocks at a time; this may make things trickier again. N |
|
From: Jeremy F. <je...@go...> - 2005-03-24 21:27:12
|
Nicholas Nethercote wrote:
> As for coverage, Cachegrind can give you a crude form of coverage
> information, but it doesn't give percentage coverage. I believe Ben
> Elliston was looking at writing a coverage tool with Valgrind that
> would produce gcov-compatible output files. AIUI, one of the
> difficulties is that gcov output is done on a basic block basis, and
> Valgrind's notion of a basic block is subtly different from that of a
> compiler's.
I guess that might be an issue. Valgrind doesn't really know where a BB
starts, only where it started executing. If you have a loop of the form:
start: preamble
loop: body
code
if !done goto loop
then Valgrind sees that as two basic blocks: one extending from start to
the goto, and one from loop to goto.
> The Valgrind 3.0 series will use the new dynamic binary translator
> Vex, which translates multiple basic blocks at a time; this may make
> things trickier again.
One presumes the instrumenter can (or could in principle) find out where
Vex decided to merge BBs, and can insert per-BB code at those points.
J
|
|
From: Julian S. <js...@ac...> - 2005-03-25 12:51:37
|
> > The Valgrind 3.0 series will use the new dynamic binary translator
> > Vex, which translates multiple basic blocks at a time; this may make
> > things trickier again.
>
> One presumes the instrumenter can (or could in principle) find out where
> Vex decided to merge BBs, and can insert per-BB code at those points.
Yes. In fact I'd say doing this kind of thing is easier now
than it ever was with UCode.
Like UCode, Vex translates each original instruction into an
intermediate representation (IR). The IR for each original
instruction is preceded by an IRStmt_IMark construct, which
tells you the original address and length of the instruction.
No more pissing around trying to reconstruct this info by
looking at simulated program-counter updates.
This should give all the info needed to build a coverage tool
that works on all valgrind-supported targets. You can easily
enough identify the original bbs from the IMark sequence.
Each IMark gives an (address, length) pair. You can see where
Vex jumped bbs by looking for places where
address_{n} + length_{n} != address_{n+1}
Alternatively you can simply tell vex not to chase over bb
boundaries by setting VexControl.guest_chase_thresh to zero
at library-initialisation time. This will reduce performance
though.
J
|