This is the mail archive of the
mailing list for the GCC project.
Re: libgcov as shared library and other issues
- From: Martin Liška <mliska at suse dot cz>
- To: Alexander Monakov <amonakov at ispras dot ru>, gcc at gcc dot gnu dot org
- Cc: Richard Biener <richard dot guenther at gmail dot com>
- Date: Wed, 26 Sep 2018 11:46:56 +0200
- Subject: Re: libgcov as shared library and other issues
- References: <alpine.LNX.email@example.com>
On 9/25/18 12:21 AM, Alexander Monakov wrote:
> Here's the promised "libgcov summary"; sorry about the delay.
Thank you Alexander, I take it as productive discussion starting point.
> So libgcov has a bit unusual design where:
> - on the one hand, the library is static-only, has PIC code and may be linked
> into shared libraries,
> - almost all gcov symbols have "hidden" visibility so they don't participate
> in dynamic linking
> - on the other hand, the __gcov_master symbol deliberately has default
> visibility, presumably with the intention that a running program has exactly
> one instance of this symbol, although the exact motivation is unclear to me.
The only usage I see right now is support of __gcov_reset, __gcov_dump function.
Which in my opinion should cover all loaded DSOs in an executable.
> This latter point does not reliably work as intended though: there are scenarios
> where a dynamically linked program will have multiple __gcov_masters anyway:
> - via repeated dlopen(RTLD_LOCAL) with main executable not linked against libgcov
> or not exporting libgcov symbols (as in PR 83879)
Here we have a work-around: --dynamic-list-data.
> - when shared libraries have version scripts that hide their __gcov_master
> - when -Bsymbolic is in effect
> Additionally, indirect call profiling symbols are not hidden either, and that
> leads to extra complications. Since there are multiple symbols, during dynamic
> linking they may be partially interposed. PR 84107 demonstrates how this leads
> to libgcov segfaulting in a fairly simple and legitimate program.
For this one, we have a working work-around: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00961.html
> Bottom line: static linking code with default-visibility symbols
> into shared libraries is problematic.
> So one strategy is to ensure all gcov symbols have hidden visibility. That would
> isolate gcov instances in each shared library loaded in the program, and each
> library would have the responsibility to write out its counters when unloaded.
> Also, __gcov_dump would dump only the counters specific to the current library.
> I may be missing something here so it might be nice to unearth why exactly
> __gcov_master is intended to be global.
> Another strategy is to introduce libgcov.so and have it host either all libgcov
> symbols or just those that by design are required to exist once in the program.
> When talking to Richi at the Cauldron I got the impression he'd question if
> shared libgcov is worth the cost, e.g. would it make any easier for users to
> mix two libraries, one linked against older libgcov, and another with a newer
> (something that doesn't work at all now, but would be nice to support if I
> understood Richard correctly).
Note that I'm fan of the shared library. I actually prepared working patch for that.
So my strategy would be to first install the suggested patch:
and then we Richi is fine, we can also add the shared library patch.