new edge coverage profiler on gcc 3.3

new edge coverage profiler on gcc 3.3

[Qiong Cai]

Hi,


I compile the program with -fprofile-arcs and
-ftest-coverage, but gcc3.3(latest snapshot)
does not generate "*.da" files after running the program.

I'd like to know wether the implemenation of
new edge coverage profiler on gcc3.3 complete
or not.  Thanks.

Qiong

Re: new edge coverage profiler on gcc 3.3

[Jan Hubicka]

> Hi,
> 
> 
> I compile the program with -fprofile-arcs and
> -ftest-coverage, but gcc3.3(latest snapshot)
> does not generate "*.da" files after running the program.
> 
> I'd like to know wether the implemenation of
> new edge coverage profiler on gcc3.3 complete
> or not.  Thanks.
It is complete and it should produce .da files.
Does the program crash at the end?  There seems to be common collision
with the routines in glibc handling of profiler format.

Honza
> 
> Qiong

Re: new edge coverage profiler on gcc 3.3

[Nathan Sidwell]

Jan Hubicka wrote:

> It is complete and it should produce .da files.
> Does the program crash at the end?  There seems to be common collision
> with the routines in glibc handling of profiler format.
do you think we should rename those routines for 3.3?

(Separately) I think we should break them out of libgcc into a libgcov,
so that they work with a shared link of libgcc. We can have a spec which
turns -fcoverage into -lgcov. This is appropriate for 3.4, but is it
too for 3.3?

Oh, yes. Does your recent change to use the mangled name for functions
require tweaks in the stuff I did on b-i-b?

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: new edge coverage profiler on gcc 3.3

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> >It is complete and it should produce .da files.
> >Does the program crash at the end?  There seems to be common collision
> >with the routines in glibc handling of profiler format.
> do you think we should rename those routines for 3.3?
> 
> (Separately) I think we should break them out of libgcc into a libgcov,
> so that they work with a shared link of libgcc. We can have a spec which
> turns -fcoverage into -lgcov. This is appropriate for 3.4, but is it
> too for 3.3?
I hope so.
> 
> Oh, yes. Does your recent change to use the mangled name for functions
> require tweaks in the stuff I did on b-i-b?
Hope it will merge easilly.

Honza
> 
> nathan
> 
> -- 
> Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
>          'But that's a lie.' - 'Yes it is. What's your point?'
> nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
> 

Re: new edge coverage profiler on gcc 3.3

[Mark Mitchell]

> (Separately) I think we should break them out of libgcc into a libgcov,
> so that they work with a shared link of libgcc. We can have a spec which
> turns -fcoverage into -lgcov. This is appropriate for 3.4, but is it
> too for 3.3?

I think you're asking "too late".

If so, the answer is yes, it's too late. :-(

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: new edge coverage profiler on gcc 3.3

[J.T. Conklin]

Nathan Sidwell <nathan@codesourcery.com> writes:
> (Separately) I think we should break them out of libgcc into a
> libgcov, so that they work with a shared link of libgcc. We can have
> a spec which turns -fcoverage into -lgcov. This is appropriate for
> 3.4, but is it too for 3.3?

While I've only been playing with coverage for a few days, I think a
separate library for the coverage infrastructure code makes a lot of
sense.  Perhaps we need to go beyond a single -lgcov library that is
automatically linked with -fcoverage though.  Some of the processors
I'd like to get coverage information from don't have access to
nicities like filesystems, so information that is collected has to be
proxied to the control plane, then later transfered to a workstation
for analysis.  

I guess I'm saying that in addition to separating the coverage code
into its own library, we mustn't preclude users from supplying their
own versions.  With that in mind, it would be nice if there was
adequate documentation of the coverage API for users to write their
own.

        --jtc

-- 
J.T. Conklin

Re: new edge coverage profiler on gcc 3.3

[Nathan Sidwell]

J.T. Conklin wrote:

> I guess I'm saying that in addition to separating the coverage code
> into its own library, we mustn't preclude users from supplying their
> own versions.  With that in mind, it would be nice if there was
> adequate documentation of the coverage API for users to write their
> own.
The file gcov-io.h on the b-i-b branch should contain sufficient
documentation. If it does not, ask me what is unclear, so I can fix it.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org