|
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
|