This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
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>