public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: ransom@cs.pdx.edu
To: gcc@gcc.gnu.org
Cc: Janis Johnson <janis187@earthlink.net>
Subject: [RFC] gcov tool, comparing coverage across platforms
Date: Thu, 23 Jun 2005 18:41:00 -0000	[thread overview]
Message-ID: <1a2da76c1e1cee6a2486ac9ef61bd3c7@cs.pdx.edu> (raw)

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

             reply	other threads:[~2005-06-23 18:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-23 18:41 ransom [this message]
2005-06-27 12:18 ` Nathan Sidwell
2005-06-27 16:40 ` Joe Buck
2005-06-27 15:05 Dan Kegel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a2da76c1e1cee6a2486ac9ef61bd3c7@cs.pdx.edu \
    --to=ransom@cs.pdx.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=janis187@earthlink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).