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>
To: "David Abrahams" <david.abrahams@rcn.com>
Cc: "Mark Mitchell" <mark@codesourcery.com>; "Jason Merrill"
<jason@redhat.com>; "Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov>;
<gcc@gcc.gnu.org>
Sent: Monday, May 13, 2002 12:58 AM
Subject: Re: Minimal GCC/Linux shared lib + EH bug example
> "David Abrahams" <david.abrahams@rcn.com> writes:
>
> > > My feeling is that a user interface like this
> >
> > What do you mean by "like this"?
> >
> > > is just not worth having. It is true that these features
> >
> > Please be specific so that I can understand your position. Which are
"these
> > features"?
>
> Interpreting Mark: "this" is an interface that sometimes works,
> sometimes doesn't.
>
> > Have you read the rest of the thread? The reasons it doesn't work by
> > accident have been pretty fully explored; if you're still surprised
> > in light of that explanation I'd appreciate knowing why because the
> > rest of us are probably missing something important.
>
> Mark is right that you just found a special case of a more general
> problem, and that what you consider a solution (do string compares)
> just solves the special case, not the general problem.
I think that's a mischaracterization of my position. Have you read my other
postings (especially http://gcc.gnu.org/ml/gcc/2002-05/msg00869.html)? I
consider "do string compares" a viable workaround, not a general solution.
In a general solution the loader would resolve symbols differently.
> Consider:
>
> inline void
> inc_boost_counter()
> {
> static int counter = 0;
> counter++;
> if(counter % 1000 == 0)
> report_counter();
> }
>
> If this was part of the libboost headers, then, again, you would end
> up with three copies of the static variable (ext1, ext2, libcore). If
> ext1 is loaded first, libcore's usage is resolved to the copy in ext1,
> and expansions of the inline function in ext2 would use a second copy
> (the copy inside libcore would not be used).
I understand that's the way it works now, of course, because the loader's
got the wrong semantics.
> That would be equally wrong,
Wrongness can't be determined until the standard describes the behavior of
shared libs.
> but impossible to fix.
In this case a redesign of the library which uses a non-inline function
fixes the problem.
> Likewise for templates:
>
> template<typename T>
> class X{
> static T* singleton;
> };>
> template<typename T>T* X::singleton = new T;
>
> You would end up with up-to three copies of the singleton for any
> value of T.
Two, I think (if the loader semantics stay the same). Isn't the case
perfectly analogous to the one above?
> Your last straw is that this is a bug in the Linux dynamic loader,
> since the Solaris loader behaves differently. I'm not sure exactly how
> it behaves, but it probably has one of the following options:
>
> 1. resolve all weak symbols defined both in extN and libcore to
> libcore. Then, anybody linking agains libcore gets the definition
> of the symbols in libcore. This probably violates the symbol
> resolution order of the gABI, so this likely not happens.
>
> 2. When loading ext1, resolve weak symbols defined both in ext1 and
> libcore to the definition in ext1; this is what happens on Linux,
> too. When loading ext2, notice that some of the symbols defined
> both in ext2 and libcore have already been resolved, for those,
> use the pre-existing binding; this essentially results in ext1,
> ext2, and libcore sharing common symbols.
>
> You could try to report this as a bug in the Linux dynamic linker. For
> that, you probably have to construct an example that doesn't include
> C++, but instead directly involves weak symbols. Of course, you should
> make sure that your example "passes" on Solaris.
I wouldn't know where to start with that one. Is there an explicit way to
mark a symbol "weak"?
-Dave