gcov questions

[Ed Swierk]

On Wed, 13 Aug 2003, Nathan Sidwell wrote:

> Ed Swierk wrote:
> > (1) A while back, I hacked up gcov to generate coverage statistics for 
> > multiple source files simultaneously.  Unfortunately the version I hacked 
> > up is fairly old (3.2.3), but I thought others might still find it useful.  
> > Where would be an appropriate place to post such a patch?
> here.

OK, I will post the patch shortly.

> > (2) Eventually I would like to migrate to a more recent version of gcc.  
> > I understand there were major changes in gcov in the 3.3 release, and a
> > perusal of the CVS archives reveals more recent changes to gcov.  Is there
> > a summary of recent gcov development activity, or features that are
> > expected to be included in the 3.4 release?
> no. There were some changes in 3.3 then the file format was completely
> redesigned for 3.4. I should probably write one ...

Are there likely to be further significant changes in gcov before 3.4 is 
released?

> > (3) The codebase on which I am running gcov is mostly C++ code that makes
> > heavy use of member functions defined inline within class definitions.  
> > Even when compiling in debug mode with no optimizations, I find that code
> > is not generated for such member functions if the compiler sees that they
> > are unused, and as a result those functions are not included in the
> > coverage statistics.
> it should still produce counts information for the lines of the inlined
> function based on their execution where they have been inlined. But you are
> right that there is no summary for those functions. Could you file a bug
> report about that so we don't forget -- it might be possible to do something

Will do.

> > As a workaround, I compile with the -fno-default-inline flag.  However,
> > this causes ld to fail unless I rebuild my entire codebase, including any
> > C++ libraries, with the same compiler flag.  Unfortunately some of those
> > libraries themselves do not compile with that flag.
> wouldn't -fno-inline be the right thing? I don't immediately see why either
> option would cause the problem your describe.

No, -fno-inline seems to have no effect for functions defined implicitly
inline (i.e. defined within a class definition).  With
-fno-default-inline, the inline-ness is ignored, and code is generated as
for a regular function, whether or not the function is called.  This lets
gcov indicate that the function isn't covered.

I can post sample code illustrating the problem if anyone is interested.

--Ed

-- 
Ed Swierk
eswierk@cs.stanford.edu