On Wed, Sep 26, 2018 at 11:46 AM Martin Liška wrote:
>
> On 9/25/18 12:21 AM, Alexander Monakov wrote:
> > Hello,
> >
> > 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.
I guess so. That could be still implemented some dlsym walking though.
> >
> > 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).
> >
> > Alexander
> >
>
> 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:
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00961.html
>
> and then we Richi is fine, we can also add the shared library patch.
I don't stand in the way of a shared libgcov I just think it may be not worth
the trouble...
Richard.
> Martin
