gcov on gdb

gcov on gdb

[Elena Zannoni]

I have run gcov on a testsuite run of gdb on my laptop (stock RHL 7.2).
It is really easy, in case somebody wants to try, you just need to compile
gdb like this:

make CFLAGS='-O0 -fprofile-arcs -ftest-coverage'

then, after the run, you'll notice all these *.bb, *.bbg, *.da files
in your objdir.  For each source file, then you can say 'gcov blah.c'
and this will produce the actually interesting data, in the form of a
copy of the source file (with a .gcov extension) with each line
annotated with the number of times it was executed, or with '###' if
it was never run.

For instance:
[ezannoni@localhost gdb]$ gcov stabsread.c
 52.76% of 2280 source lines executed in file /home/ezannoni/sources/src/gdb/stabsread.c
Creating stabsread.c.gcov.

In doing so, I've noticed that a lot of lines in the stabread.c file
are never executed because they are old functions (1996) to support
cfront.  I think we could obsolete this stuff.  I've not found anything
in a google search for cfront that was more recent than 1995.

Anyway, I think the gcov data is too bulky to post. But it could be a good
way to spot stuff that is old, or stuff that is untested.

Elena

Re: gcov on gdb

[Daniel Jacobowitz]

On Mon, Jan 06, 2003 at 09:26:26PM -0500, Elena Zannoni wrote:
> 
> I have run gcov on a testsuite run of gdb on my laptop (stock RHL 7.2).
> It is really easy, in case somebody wants to try, you just need to compile
> gdb like this:
> 
> make CFLAGS='-O0 -fprofile-arcs -ftest-coverage'
> 
> then, after the run, you'll notice all these *.bb, *.bbg, *.da files
> in your objdir.  For each source file, then you can say 'gcov blah.c'
> and this will produce the actually interesting data, in the form of a
> copy of the source file (with a .gcov extension) with each line
> annotated with the number of times it was executed, or with '###' if
> it was never run.

I've done this once.  I was trying to write a full-coverage (or mostly
full coverage...) testsuite for c-typeprint.c; I'll get back to that
One Of These Days.

> For instance:
> [ezannoni@localhost gdb]$ gcov stabsread.c
>  52.76% of 2280 source lines executed in file /home/ezannoni/sources/src/gdb/stabsread.c
> Creating stabsread.c.gcov.
> 
> In doing so, I've noticed that a lot of lines in the stabread.c file
> are never executed because they are old functions (1996) to support
> cfront.  I think we could obsolete this stuff.  I've not found anything
> in a google search for cfront that was more recent than 1995.
> 
> Anyway, I think the gcov data is too bulky to post. But it could be a good
> way to spot stuff that is old, or stuff that is untested.

I think this is a really, really, really good idea.  I can absolutely
guarantee that the C++ language support won't work with CFront any
more, and I've never seen a complaint, so I'm inclined to think it
doesn't have current users (or current users interested in GDB).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcov on gdb

[Andrew Cagney]

> I have run gcov on a testsuite run of gdb on my laptop (stock RHL 7.2).
> It is really easy, in case somebody wants to try, you just need to compile
> gdb like this:
> 
> make CFLAGS='-O0 -fprofile-arcs -ftest-coverage'
> 
> then, after the run, you'll notice all these *.bb, *.bbg, *.da files
> in your objdir.  For each source file, then you can say 'gcov blah.c'
> and this will produce the actually interesting data, in the form of a
> copy of the source file (with a .gcov extension) with each line
> annotated with the number of times it was executed, or with '###' if
> it was never run.
> 
> For instance:
> [ezannoni@localhost gdb]$ gcov stabsread.c
>  52.76% of 2280 source lines executed in file /home/ezannoni/sources/src/gdb/stabsread.c
> Creating stabsread.c.gcov.
> 
> In doing so, I've noticed that a lot of lines in the stabread.c file
> are never executed because they are old functions (1996) to support
> cfront.  I think we could obsolete this stuff.  I've not found anything
> in a google search for cfront that was more recent than 1995.
> 
> Anyway, I think the gcov data is too bulky to post. But it could be a good
> way to spot stuff that is old, or stuff that is untested.

Don't know of a script that can convert the gcov into html so that it is 
web browsable?

Anyway, what about putting it on the ftp server?

Andrew

Re: gcov on gdb

[Daniel Jacobowitz]

On Mon, Jan 06, 2003 at 10:17:15PM -0600, Michael Elizabeth Chastain wrote:
> Elena Zannoni writes:
> > In doing so, I've noticed that a lot of lines in the stabread.c file
> > are never executed because they are old functions (1996) to support
> > cfront.  I think we could obsolete this stuff.  I've not found anything
> > in a google search for cfront that was more recent than 1995.
> 
> More generally, I wish gdb had documentation about which compilers,
> assemblers, and linkers that gdb supports, especially for C++.

C++: in practice, GNU GCC 2.95, and GNU GCC 3.x.  In theory, HP aCC
also, but I haven't gotten around to seeing how well it works; and
frankly, the HP debug info is so overengineered that it's a royal pain
to work with.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcov on gdb

[Michael Elizabeth Chastain]

Elena Zannoni writes:
> In doing so, I've noticed that a lot of lines in the stabread.c file
> are never executed because they are old functions (1996) to support
> cfront.  I think we could obsolete this stuff.  I've not found anything
> in a google search for cfront that was more recent than 1995.

More generally, I wish gdb had documentation about which compilers,
assemblers, and linkers that gdb supports, especially for C++.

Personally, I take the view that I prefer to test-bed gdb with other
Free Software.  Specifically that means these licenses:

  http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
  http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

I don't know what FSF policy is on this.

Michael C
apologies to elena z for the tangent on her thread