This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example

From: "Martin v. Loewis" <>

> "David Abrahams" <> 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
your point.

> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]