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

[Jason Merrill <jason@redhat.com>]

On Fri, 31 May 2002 00:56:29 -0400, Jason Merrill <jason@redhat.com> wrote:

>>>>>> "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.

Ping?

Jason