re: [RFC] gcov tool, comparing coverage across platforms

re: [RFC] gcov tool, comparing coverage across platforms

[Dan Kegel]

> We are a group of undergrads at Portland State University who accepted as our senior capstone software engineering project a proposed tool for use with gcov for summarizing gcov outputs for a given piece of source code tested on multiple architecture/OS platforms. A summary of the initial proposal is here:
> http://www.clutchplate.org/gcov/gcov_proposal.txt
> 
> A rough overview of our proposed design is as follows:
> We would build a tool which would accept as input:
> on the command line, paths to each .gcov file to be included in the summary,
> each of these to be followed by a string which would be the platform identifier for
> that .gcov file.
> The .gcov files would be combined so that the format would parallel the existing output,
> with the summarized report listing each line of the source once, followed immediately
> by a line for each platform id and the coverage data for that platform.

Sounds like a fun project.

Rather than taking the path to each .gcov file on
the commandline, you might consider searching
from them, as lcov does.
Come to think of it, maybe you could steal
some ideas or even code from lcov. See
http://ltp.sourceforge.net/coverage/lcov.php
ltp is written in perl, for what it's worth.

I like using Bourne shell for projects it's a good
fit for, but you may find yourself needing
something like perl, since you'll be wrangling
lots of files and lots of text.
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

[RFC] gcov tool, comparing coverage across platforms

[ransom]

We are a group of undergrads at Portland State University who accepted 
as our senior capstone software engineering project a proposed tool for 
use with gcov for summarizing gcov outputs for a given piece of source 
code tested on multiple architecture/OS platforms. A summary of the 
initial proposal is here:
http://www.clutchplate.org/gcov/gcov_proposal.txt

A rough overview of our proposed design is as follows:
We would build a tool which would accept as input:
   on the command line, paths to each .gcov file to be included in the 
summary,
   each of these to be followed by a string which would be the platform 
identifier for
   that .gcov file.
   The .gcov files would be combined so that the format would parallel 
the existing output,
   with the summarized report listing each line of the source once, 
followed immediately
   by a line for each platform id and the coverage data for that 
platform.

Our closest interpretation of this is to provide a tool in the form of 
a shell script which would provide a listing very much like the current 
gcov output, but which would for each line or section of source provide 
coverage information for each platform with a note associating each 
output with its specific platform identifier.

Current questions include whether this tool needs to be used on 
platforms for which a bourne shell script is inappropriate and whether 
this tool needs to be coded in C instead. Also, whether the -a, -b, -c 
and -f output types from gcov all need to be accounted for or whether 
only some of these outputs are of types for which cross-platform 
comparison makes sense. We have little doubt that regular users of gcov 
will see other concerns as obvious which we haven't foreseen at all. We 
welcome exactly these observations.

Most importantly, since there is no one clear party who has 
commissioned this tool, we need input as to whether we are on the right 
track to build a useful tool. Our time is limited and our deadline for 
a finished item is the end of July. We would be most grateful for any 
comment or guidance, any instance of a point a user might need to make 
use of this tool.

Thanks,
Jesse Burkett
gcov capstone team at PSU
gcov-capstone@cs.pdx.edu

Re: [RFC] gcov tool, comparing coverage across platforms

[Nathan Sidwell]

ransom@cs.pdx.edu wrote:

> Current questions include whether this tool needs to be used on 
> platforms for which a bourne shell script is inappropriate and whether 
> this tool needs to be coded in C instead.

as you're somewhat deadline bound, write it in whatever language suits your 
needs.  bash would certainly be acceptable, but I wouldn't particularly mind if 
it was in perl or python, which might be somewhat easier to work with.

> Also, whether the -a, -b, -c 
> and -f output types from gcov all need to be accounted for or whether 
> only some of these outputs are of types for which cross-platform 
> comparison makes sense. We have little doubt that regular users of gcov 
Seems a reasonable choice.

One other use of such a tool, that I suggested to Janis when she mentioned you 
all, is to compare gcov results for the same target machine but at different 
optimization levels.  this might or might not change the block structure to a 
greater extent.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: [RFC] gcov tool, comparing coverage across platforms

[Joe Buck]

On Thu, Jun 23, 2005 at 11:41:04AM -0700, ransom@cs.pdx.edu wrote:
> We are a group of undergrads at Portland State University who accepted 
> as our senior capstone software engineering project a proposed tool for 
> use with gcov for summarizing gcov outputs for a given piece of source 
> code tested on multiple architecture/OS platforms. A summary of the 
> initial proposal is here:
> http://www.clutchplate.org/gcov/gcov_proposal.txt

It seems that you may be imposing a restriction on your tool that puts
an unnecessary limitation on its usefulness.

What you are really producing is a mechanism to combine information from
gcov reports, that allows attributes to be placed on the gcov reports.
You have identified one possible attribute: the architecture/OS platform.
But that's only one possibility.

Remember, gcov produces one report per .o file.  But that .o file might
be linked into many different possible programs.  If you were testing
something Gnome or KDE, you might be interested in which lines of code
in libraries are touched by calls from which user applications, for
example.  A software development project might want to know which lines
are hit only by unit tests, and which are actually used by the full
application.  The list goes on.

The thing is, you don't need to do any additional work to handle this
more general application, just be less restrictive about what the
property means that you are calling "architecture/OS platform".