Re: PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate dataobjects in shared libraries)

[Jason Merrill <jason at redhat dot com>]

>>>>> "Ulrich" == Ulrich Drepper <drepper@redhat.com> writes:

Thanks for responding.

> On Thu, 2002-05-30 at 13:01, Jason Merrill wrote:

>> No; Solaris' behavior is no more helpful for real-world C++ examples.

> Very specialized and maybe true for gcc.

The EDG frontend, used by Intel among many others, also relies on address
comparison for typeinfos.  And, indeed, the Intel compiler produces code
that fails in exactly the same way as the gcc output.

Intel also seems to use weak symbols, and even linkonce sections, for
template instantiations.

Sun CC 4.2 fails in the same way under Solaris 5.8 (after I make the
necessary changes to accomodate that ancient compiler; fortunately, it
supports EH).

Interestingly, SGI CC 7.30 passes the test, even though it also uses the
EDG frontend.  I'll investigate why; I'm guessing dlopen works differently
on Irix.

>> Is there any kind of a standard for ld.so symbol resolution behavior?

> Most things the generic ELF ABI covers.  But the behavior of dlopen() on
> the ELF level is not covered by any standard.

>> 1) Always prefer the last weak definition if no strong definition is seen.

> Special weak symbol handling is going away.  The ELF spec didn't clearly
> state what has to happen and so a few implementation (like glibc) added
> this kind of support.  But it's not portable and it's unnecessarily
> reducing the speed.

It's not portable because, as you say, there's no standard.  That seems
like an opportunity to explore what a future standard should say.

Speed should not trump correctness.  If you have a different idea for how
we can get proper C++ semantics, I'd love to hear it.

>> 2) If a DSO A has two unrelated dependencies B and C which both define (and
>> use) the same weak symbol, add C to the dependency list of this loaded
>> copy of B.

> If I understand this correctly you mean

>    A ---> B
>      |
>      +--> C

> and B defines and uses 'foo' and C defines and uses 'foo'.

> In this case it makes no difference whether C gets added to the
> dependency list of B since B's scope comes first.

Yes, I mentioned that this was only meaningful in conjunction with #1,
which would cause the last definition to be chosen.

>> 3) When resolving a relocation from a DSO loaded with RTLD_LOCAL, start
>> looking from the DSO itself; do not consider other RTLD_LOCAL objects
>> which depend on it.

> Starting with the DSO itself is what you select with DF_SYMBOLIC.  It's
> generally a very bad idea.  Which other scopes are searched depends
> heavily on the actual situation.  There won't be any "this is how C++
> needs it and therefore this is how it's gonna be".

Of course not, I'm mostly looking for input.  But C++ places more complex
demands on the linker, leading to situations that we hadn't considered
before; we need to consider what the right thing to do is in those
situations.  I've suggested what I think the right thing is, which I
believe is appropriate for all languages, not just C++, but I'm very
interested in your opinion; you are certainly more familiar with ld.so than
I.

> I'll look at all this hopefully in two weeks from now.

Thanks.

Jason