https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879
--- Comment #3 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Aha, this is the behaviour of the static linker. It is not placing
'__gcov_master' into main's dynamic symbol table. So dlloading the shared
objects do not see it, and have their own instance. To confuse things further,
the first dlloaded object creates this symbol and the second loaded object sees
that symbol.
from ld's man page:
When creating a dynamically linked executable, using the -E option or
the --export-dynamic option causes the linker
to add all symbols to the dynamic symbol table. The dynamic symbol
table is the set of symbols which are visible
from dynamic objects at run time.
If you do not use either of these options (or use the
--no-export-dynamic option to restore the default behavior),
the dynamic symbol table will normally contain only those symbols
which are referenced by some dynamic object
mentioned in the link.
If you use "dlopen" to load a dynamic object which needs to refer
back to the symbols defined by the program, rather
than some other dynamic object, then you will probably need to use
this option when linking the program itself.
You can also use the dynamic list to control what symbols should be
added to the dynamic symbol table if the output
format supports it. See the description of --dynamic-list.
Note that this option is specific to ELF targeted ports. PE targets
support a similar function to export all symbols
from a DLL or EXE; see the description of --export-all-symbols
below.
You can use '-dynamic' when invoking gcc to set this linker flag:
Pass the flag @option{-export-dynamic} to the ELF linker, on targets
that support it. This instructs the linker to add all symbols, not
only used ones, to the dynamic symbol table. This option is needed
for some uses of @code{dlopen} or to allow obtaining backtraces
from within a program.
Might be worth documenting this in gcov's options?
