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

["H. J. Lu" <hjl at lucon dot 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