Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value

[Richard Sandiford <rsandifo@redhat.com>]

"Bradley D. LaRonde" <brad@laronde.org> writes:
> I guess that the point of these procedure stubs is to keep
> pointer-to-function values consistent between executables and share
> libraries.  Is that what binutils is trying to accomplish here?

No, it's to enable lazy binding.  The idea is that when the dynamic
loader loads libpthread.so, it doesn't need to resolve malloc()
immediately, it can just leave the GOT entry pointing to the stub.
Then, when the stub is called, it will ask the dynamic linker to
find the true address of malloc() and update the GOT accordingly.
This is supposed to reduce start-up time.

An object should never use stubs if takes the address of the function.
It should only use a stub for some symbol foo if every use of foo is
for a direct call.

If the dynamic loader is choosing libpthread's stub over the real
definition in libc.so, that sounds on the face of it like a dynamic
loader bug.

> But should stubs really be getting involved here?  As Thiemo Seufer pointed
> out to me, readelf shows me that every undefined symbol in every shared
> library in /lib on my x86 debian box has the st_value member for the symbol
> table entry set to zero.

The x86 and MIPS ABIs are very different though.

Richard