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

["H. J. Lu" <hjl at lucon dot org>]

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