This is the mail archive of the
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
From: "Martin v. Loewis" <email@example.com>
> "David Abrahams" <firstname.lastname@example.org> writes:
> > > No. For template static data, it *only* emits them as .comm, not as
> > > .weak. For initialized data that need to be merged at run-time (such
> > > as vtables), it emits them as weak.
> > Hmm; don't initialized instances of a template static data member need
> > be merged at run-time?
> Yes. It turns out that weak symbols only contribute lightly to
> run-time semantics of symbol resolution: Even if a symbol is strong,
> the dynamic linker will deal with multiple definitions gracefully, and
> take the first one it finds.
That's only "graceful handling" for some kinds of definitions, but I take
> Weak symbols matter in that case only if
> the first one it finds is weak: a later strong symbol may then
> override the resolution.
> .comm is only relevant for object files (relocatable objects):
By this do you mean what we normally use "*.o" names for? From looking at
the ELF spec, it wasn't clear if "object" meant something else, e.g.
> the (static) linker will eliminate duplicates of .comm (common data). It
> will do so by finding the definition of the symbol that is largest (so
> they even might have different sizes), and then allocate a global
> symbol in the .bss section.
So, for a symbol in a C++ shared library composed of a single object file,
even .comm would not be needed?