Bug 7970 - Arc profiling doesn't work reliably on global destructors
Summary: Arc profiling doesn't work reliably on global destructors
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: gcov-profile (show other bugs)
Version: 3.2.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 16855 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-09-18 06:56 UTC by asuffield
Modified: 2013-01-29 06:40 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-18 01:04:11


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description asuffield 2002-09-18 06:56:02 UTC
__bb_exit_func is registered with atexit(), to save the profiling data.

I haven't analysed the situation in detail, but this appears to run before functions declared with __attribute__((destructor)), at least. So those don't get profiled (and, slightly more importantly, test coverage misses them).

(If this isn't fixed in the next release, it should probably be documented as a limitation and referenced from the gcov manual).

Release:
gcc version 3.2.1 20020830 (Debian prerelease)
Comment 1 Dara Hazeghi 2003-05-31 20:19:51 UTC
Hello,

could you confirm whether this behavior is still the case in gcc 3.3? A testcase of the 
'unreliable' behavior would also be much apprecaited. Thanks,

Dara
Comment 2 Andrew Pinski 2003-11-05 07:47:59 UTC
The problem is that the write out for the data is done before global destructors are done.
Comment 3 Jan Hubicka 2003-12-29 11:35:20 UTC
I am not familiar with global destructors mechanizm, but can we assign each profiled file global destructor that will save profiles only for that file and manage priorities so they are run very last?  That would solve this problem as well as the problem with profile being corrupted when dlclose is called...
Honza
Comment 4 Andrew Pinski 2004-08-02 21:17:57 UTC
*** Bug 16855 has been marked as a duplicate of this bug. ***
Comment 5 David Hammen 2011-06-17 17:45:30 UTC
This bug *still* exists as of i686-apple-darwin10-g++-4.2.1. The problem is apparently the collision of two at_exit() handlers, with C++'s global destructor coming in last.