This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate dataobjects in shared libraries)
- From: Jason Merrill <jason at redhat dot com>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: GNU C Library <libc-alpha at sources dot redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 10 Apr 2003 13:49:26 +0100
- Subject: Re: PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate dataobjects in shared libraries)
- References: <76260000.1021912729@warlock.codesourcery.com><wvlhel2ocz3.fsf@prospero.cambridge.redhat.com><60630000.1021922077@gandalf.codesourcery.com><00ba01c20035$805388a0$6601a8c0@boostconsulting.com><wvln0uumvqt.fsf@prospero.cambridge.redhat.com><08b101c201f0$d511fd60$6601a8c0@boostconsulting.com><wvloff7ea9a.fsf@prospero.cambridge.redhat.com><20020529130945.A16909@lucon.org><039401c20759$a3ba1400$6601a8c0@boostconsulting.com><wvl8z615rsz.fsf@prospero.cambridge.redhat.com><1022790116.22692.205.camel@myware.mynet><wvlit54530i.fsf@prospero.cambridge.redhat.com>
On Fri, 31 May 2002 00:56:29 -0400, Jason Merrill <jason at redhat dot com> wrote:
>>>>>> "Ulrich" == Ulrich Drepper <drepper at redhat dot 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