This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
----- Original Message -----
From: "Martin v. Loewis" <martin@v.loewis.de>
> "David Abrahams" <david.abrahams@rcn.com> writes:
>
> > If I understand correctly, weak symbols were introduced to allow things
> > like users replacing malloc, free, operator new, etc.
>
> That's why they were introduced, yes. It turns out that they are
> useful for a number of other things: you can emit duplicate
> definitions of the same symbol, and it won't be a linker error. This
> usage is particularly important for C++, to support virtual tables,
> typeinfo objects, template instantiations, etc.
Yes, thanks, I understand the reasons. However, there's a small difference
if I understand things correctly: in these C++ cases, typically /all/ of
the definitions are weak, right?
> > I think the same case could be made by putting malloc/free replacements
in
> > each of two extension modules which are linked to a common shared lib,
> > right?
>
> Not sure what "the same case" is, here.
I mean that we can make the "same" (well, analogous) argument for what the
symbol sharing behavior ought to be.
> > Then memory allocated by ext2 couldn't be freed by the common lib,
> > and vice-versa.
>
> If both ext1 and ext2 override the allocator in libcore, then all
> calls in libcore would use the definition in ext1, but calls in ext2
> would use their own definition, yes.
>
> > Can you think of a more-minimal or more-compelling test case?
>
> Think of: yes, I would just make three functions, each printing a
> different message. It's not a compelling test case, but it
> demonstrates the difference to Solaris, and it demonstrates that the
> libcore and ext2 use different definitions, even though they are
> linked together.
Yes, it's minimal, but when you don't attach some connotation of real-world
semantics to these functions it's easy to miss the reasons that it should
work differently.
-Dave