Alexander Monakov
2018-09-24 22:21:55 UTC
Hello,
Here's the promised "libgcov summary"; sorry about the delay.
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.
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)
- 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.
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).
Alexander
Here's the promised "libgcov summary"; sorry about the delay.
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.
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)
- 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.
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).
Alexander