Expected semantics of versioned symbol resolution

Expected semantics of versioned symbol resolution

[Florian Weimer]

Do versioned symbols bind to a symbol name/version/soname combination, 
or just a name/version combination?

The current ld.so behavior seems far from uniform.  Existing binaries 
reference pthread_mutex_lock, version GLIBC_2.2.5, soname libc.so.6. 
Yet we clearly expect that these are bound to the pthread_mutex_lock in 
libpthread.so.0, not the one in libc.so.6, once libpthread is loaded 
(irrespective of the link order).

However, when I removed the fork symbol from libpthread.so.0, I had 
failures which indicated that ld.so was *exclusively* looking at 
libpthread.so.0 for the binding.  It was not looking at the libc.so.6 
DT_NEEDED dependency of libpthread.so.0 as a fallback.

Is this the expected behavior?

(I think I botched my earlier tests in my discussion about Andreas, when 
we discussed options for replacing the broken IFUNC resolver for 
fork/vfork in libpthread.so.0.)

Thanks,
Florian

Re: Expected semantics of versioned symbol resolution

[Andreas Schwab]

Florian Weimer <fweimer@redhat.com> writes:

> The current ld.so behavior seems far from uniform.  Existing binaries
> reference pthread_mutex_lock, version GLIBC_2.2.5, soname libc.so.6. Yet
> we clearly expect that these are bound to the pthread_mutex_lock in
> libpthread.so.0, not the one in libc.so.6, once libpthread is loaded
> (irrespective of the link order).

Do they?  Note that the functions defined in nptl/forward.c forward the
calls to libpthread once the latter is loaded, but are no-ops otherwise.
The binding doesn't change from what was recorded during linking.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."