Re: [Valgrind-developers] Coverage tool

[Benoit P. <ben...@en...>]

Le lun 25/04/2005 =E0 18:02, Josef Weidendorfer a =E9crit :

> It would be good to have some iterator functions for debug info available=
 for=20
> tools. Structs are bad wrt. interface stability.

Yes.=20
If I want to provide a patch for this (and maybe for other tools) how
should I proceed ?

> > As the format is extensible, I'd like to keep a new information
> > associated with each file name : the soname where it has been found.
> > Can I add a so=3D... before fl=3D... ?
>=20
> Do you mean the file name of a shared library, or the soname defined in t=
he=20
> shared library? The file name of the shared lib is stored in callgrind fi=
les=20
> via "ob=3D" (meaning: ELF object). It would be nice if we could use the s=
ame.

Let's go for ob=3D


> BTW, what are you using this for?

I'm using this to group source files in the summary. Sources can be
grouped by library, or by directory. That's why I don't really mind if
it's the filename or the soname, though the filename may be more
explicit to developers.


> It seems quite natural for me to also do code coverage on this level. The=
n you=20
> would also get information for a source line like: "only 20% of instructi=
ons=20
> attributed to this source line are executed".

It does coverage at debug level, this means that if there are multiple
instructions associated with a line you can have 20% of a line executed.
But this is not assembler level, the compiler doesn't associate each
opcode with a line. For example a for loop line can be executed from 2
places (so either 0%, 50% or 100%).
I don't think getting deeper is usefull. Usually you don't want to get
assembler coverage for extern libraries. If you are coding in assembler,
doesn't your compiler add this information already ?

Benoit