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

----- Original Message -----
From: "Martin v. Loewis" <>
To: "David Abrahams" <>
Cc: "Mark Mitchell" <>; "Jason Merrill"
<>; "Ralf W. Grosse-Kunstleve" <>;
Sent: Monday, May 13, 2002 12:58 AM
Subject: Re: Minimal GCC/Linux shared lib + EH bug example

> "David Abrahams" <> 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
> > 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 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"?


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