This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate data objects in shared libraries)
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Ulrich Drepper <drepper at redhat dot com>,GNU C Library <libc-alpha at sources dot redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 10 Apr 2003 08:31:40 -0700
- Subject: Re: PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate data objects in shared libraries)
- References: <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> <wvl3ckqfrft.fsf@prospero.boston.redhat.com> <20030410080009.A25605@lucon.org>
Oops. I meant my patch SHOULDN'T change anything.
H.J.
On Thu, Apr 10, 2003 at 08:00:09AM -0700, H. J. Lu wrote:
> While we are on the topic, here is a patch. At the current glibc, it
> should change anything since l_searchlist.r_list[0] is always args.map.
> But it is used for RTLD_LOCAL change.
>
>
> H.J.
> ----
> 2002-05-30 H.J. Lu <hjl at gnu dot org>
>
> * elf/dl-open.c (_dl_open): Check args.map->l_opencount instead
> of args.map->l_searchlist.r_list[0]->l_opencount for error.
>
> --- elf/dl-open.c.close Thu May 30 08:58:36 2002
> +++ elf/dl-open.c Thu May 30 14:10:39 2002
> @@ -503,7 +507,7 @@ _dl_open (const char *file, int mode, co
>
> /* Increment open counters for all objects since this
> sometimes has not happened yet. */
> - if (args.map->l_searchlist.r_list[0]->l_opencount == 0)
> + if (args.map->l_opencount == 0)
> for (i = 0; i < args.map->l_searchlist.r_nlist; ++i)
> ++args.map->l_searchlist.r_list[i]->l_opencount;
>
> On Thu, Apr 10, 2003 at 01:49:26PM +0100, Jason Merrill wrote:
> > 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