|
From: Benoit P. <ben...@en...> - 2005-04-26 18:14:12
|
Hi,=20 This is a first version of my coverage tool.=20 You can find it at http://b.peccatte.free.fr/cover-0.01.tgz To build it : - extract cover.tgz into the valgrind directory - add cover to Makefile.am in the 'TOOL =3D ...' line - build as usualy To use it simply call valgrind withe --tool=3Dcover This produces a cover.pid file. This file can be read with cg_annotate=20 or kcachegrind. This is not really tested. It currently produces warnings because I use ob=3D inappropriatly. I made a script to get clean summary of coverage information. Simply run ./cover cover.pid ./cover -h will give you explanations on how to use it. Benoit |
|
From: Josef W. <Jos...@gm...> - 2005-04-26 21:43:19
|
On Tuesday 26 April 2005 20:13, Benoit Peccatte wrote: > Hi, > > This is a first version of my coverage tool. > You can find it at http://b.peccatte.free.fr/cover-0.01.tgz Cool, it even compiles with VG 2.4.0 without problems. > To build it : > - extract cover.tgz into the valgrind directory > - add cover to Makefile.am in the 'TOOL = ...' line I needed to add the directory also at the end of configure.in, so that configure creates the Makefile. I think the script (cover) should be installed, too, via a bin_SCRIPT line in Makefile.am. > To use it simply call valgrind withe --tool=cover > This produces a cover.pid file. This file can be read with cg_annotate This works good if you rename it to "cachegrind.out.*" (aside from the warnings because of the "ob=" lines). Especially the source annotation looks good. Small example for a small test loop: ==================================== ... hasDebug executed execCount . . . int main() 1 1 1 { 1 1 1 int i, j=0; . . . 1 1 2 printf("Hello World!\n"); . . . 2 2 202 for(i=0;i<100;i++) 1 1 200 j += a(i); . . . 1 1 1 return j; 1 1 1 } ... ======================================= What is the exact semantic of the numbers? I am curious because of "executed=2" for the printf line, "hasDebug=2" on the for() line, and "execCount=200" on the loop body line. > or kcachegrind. This works fine out of the box, with function grouping according to object file and similar annotation as above. The function overview is currently limited to show only one event type... Regarding a patch for iterators for debug info for Valgrind: best is to send it to the mailing list (or a link to it if it's long), and ask for inclusion. Josef > This is not really tested. It currently produces warnings > because I use ob= inappropriatly. > > I made a script to get clean summary of coverage information. > Simply run > ./cover cover.pid > ./cover -h will give you explanations on how to use it. > > Benoit |
|
From: Nicholas N. <nj...@cs...> - 2005-04-26 22:01:27
|
On Tue, 26 Apr 2005, Benoit Peccatte wrote: > This is a first version of my coverage tool. > You can find it at http://b.peccatte.free.fr/cover-0.01.tgz > > To build it : > - extract cover.tgz into the valgrind directory > - add cover to Makefile.am in the 'TOOL = ...' line > - build as usualy > > To use it simply call valgrind withe --tool=cover > This produces a cover.pid file. This file can be read with cg_annotate > or kcachegrind. This is not really tested. It currently produces warnings > because I use ob= inappropriatly. > > I made a script to get clean summary of coverage information. > Simply run > ./cover cover.pid > ./cover -h will give you explanations on how to use it. Nice job. I've only scanned the code quickly so far, but I have three immediate questions: - Are you sure you're developing from the Subversion repository? It really looks to me like you're working from CVS. - Is a new output file generated for each execution? An important feature of coverage tools is that you want to be able to run a program multiple times, and get the total coverage from all the executions, not just a single one. So that way you can, for example, run your test suite with many tests and then at the end get a coverage figure. - Does cv_header.h need to be separate -- could its contents just be put into cv_main.c? Thanks for releasing this version! :) N |
|
From: Benoit P. <ben...@en...> - 2005-04-26 22:44:30
|
On Tue, 26 Apr 2005 17:01:17 -0500 (CDT) Nicholas Nethercote <nj...@cs...> wrote: > Nice job. I've only scanned the code quickly so far, but I have three > immediate questions: >=20 > - Are you sure you're developing from the Subversion repository? It=20 > really looks to me like you're working from CVS. Oops, you're right. > - Is a new output file generated for each execution? An important=20 > feature of coverage tools is that you want to be able to run a program=20 > multiple times, and get the total coverage from all the executions, not=20 > just a single one. So that way you can, for example, run your test suite= =20 > with many tests and then at the end get a coverage figure. The output is named using the process's pid. But using the cover script you can merge two output files into a new one. > - Does cv_header.h need to be separate -- could its contents just be pu= t=20 > into cv_main.c? It can be put into cv_main.c, I separated it for readability and because=20 I thought it didn't really belong to the tool. > Thanks for releasing this version! :) Next one soon :) Benoit PS: No need to CC me, I'm on the list now. |
|
From: Benoit P. <ben...@en...> - 2005-04-26 22:36:02
|
On Tue, 26 Apr 2005 23:44:12 +0200
Josef Weidendorfer <Jos...@gm...> wrote:
> [Suggestions ...]
I'll take this into account.
> Small example for a small test loop:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> ...
> hasDebug executed execCount
>=20
> . . . int main()
> 1 1 1 {
> 1 1 1 int i, j=3D0;
> . . .
> 1 1 2 printf("Hello World!\n");
> . . .
> 2 2 202 for(i=3D0;i<100;i++)
> 1 1 200 j +=3D a(i);
> . . .
> 1 1 1 return j;
> 1 1 1 }
> ...
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> What is the exact semantic of the numbers? I am curious because of=20
> "executed=3D2" for the printf line, "hasDebug=3D2" on the for() line, and=
=20
> "execCount=3D200" on the loop body line.
hasDebug is the number of executable instructions in the line
executed is the number of executable instructions the code passed through i=
n the line
execCount is the number of times the code passed through the line
Benoit
|
|
From: Nicholas N. <nj...@cs...> - 2005-04-27 01:21:37
|
On Wed, 27 Apr 2005, Benoit Peccatte wrote:
>> Small example for a small test loop:
>> ====================================
>> ...
>> hasDebug executed execCount
>>
>> . . . int main()
>> 1 1 1 {
>> 1 1 1 int i, j=0;
>> . . .
>> 1 1 2 printf("Hello World!\n");
>> . . .
>> 2 2 202 for(i=0;i<100;i++)
>> 1 1 200 j += a(i);
>> . . .
>> 1 1 1 return j;
>> 1 1 1 }
>> ...
>> =======================================
>>
>> What is the exact semantic of the numbers? I am curious because of
>> "executed=2" for the printf line, "hasDebug=2" on the for() line, and
>> "execCount=200" on the loop body line.
>
> hasDebug is the number of executable instructions in the line
> executed is the number of executable instructions the code passed through in the line
> execCount is the number of times the code passed through the line
Are "hasDebug" and "executed" ever different? I guess it's possible if
you have more than one statement in a single line.
More importantly, are "hasDebug" and "executed" interesting to a user?
I just show "execCount", which is consistent with how gcov works.
N
|
|
From: Benoit P. <ben...@en...> - 2005-04-29 09:33:52
|
Here is a new version of my code coverage tool. http://b.peccatte.free.fr/cover-0.03.tgz - I'm now using svn version for developpement - C++ members are demangled About the cover script, it has several arguments, use -h to get a list. Cover can now annotate source files (use -as for short annotate and -al for long annotate). Long annotate should be the same as cg_annotate when not using -1. Short annotate displays '.' for no information, '#' for a line that have not been executed and 100% or a percentage for a line that have been executed. |