This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Versioning mess proved!!!


> Cc: Franz.Sirl-kernel@lauterbach.com, philb@gnu.org, howarth@fuse.net,
>         libc-alpha@sourceware.cygnus.com, aj@suse.de
> Reply-To: drepper@cygnus.com (Ulrich Drepper)
> From: Ulrich Drepper <drepper@redhat.com>
> Date: 02 Oct 2000 13:49:50 -0700
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef)
> 
> Geoff Keating <geoffk@cygnus.com> writes:
> 
> > The test must be done when the data reference is resolved.  If the
> > data reference would be resolved to a PLT entry, and the data
> > reference is weak, then it must be checked that there is a real
> > definition somewhere as well as the PLT entry.  I think this will be
> > easy to fit into the current do-lookup logic without any significant
> > performance impact.
> 
> But this will impact programs which expect lazy relocation.  Imagine a
> program running dlopen() with RTLD_GLOBAL to satisfy such a undefined
> reference.

I don't think it's allowed to "expect" lazy relocation, especially not
of data references.  ld.so can always decide that it needs to relocate
something early.

> I'm not really sure whether we should try to work on these things.
> Clearly the compatibility issue on PPC must be resolved but the weak
> handling should perhaps not be touched.  To solve the PPC issue we
> have to get rid of the PLT entry.  There should be only the data
> relocation.  And this is where the x86 is different since here we
> don't have a PLT entry.  Can we add some magic perhaps with a no-op
> asm to trick gcc into believing that the function pointer might be
> modified?

As a workaround just to get 2.2 out, this might be OK.  In the long
term, though, this should be fixed properly as user programs might
need to do this too.

> Programs have the opportunity to use
> 
> 	dlsym (RTLD_DEFAULT, "foo")
> 
> to test for the availability of symbol "foo".  The current weak
> handling hasn't provoked any complains but upsetting the status quo
> might do just that.

Won't this just do the same thing as the reloc?  I expect it would
return the address of the PLT entry if the program has one.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]