Re: Incorrect IFUNC use in libpthread for fork, vfork wrapper [BZ #19861]

[Richard Henderson <rth at redhat dot com>]

On 03/30/2016 12:10 PM, Szabolcs Nagy wrote:
> if the relocations of libpthread.so are processed later
> than the relocations of libdofork.so then this can crash.
> 
> i'm not sure about the ordering requirements of
> relocations of modules..

Ah, this is a very interesting case.

I went back and looked at the PR more closely and my first reaction was that
libdofork.so was being built incorrectly:

  gcc -shared -Wl,-z,now -o libdofork.so dofork.o

Note that there's no dependency of libdofork.so on libpthread.so.  The proper
existence of such dependencies is the only way that ld.so has in order to
process the libraries in the proper order.  You'll find that the crash goes
away if we do provide this dependency:

  gcc -shared -Wl,-z,now -o libdofork.so dofork.o -lpthread

Now, ordinarily I would have continued to advise that you link with

  -Wl,--error-unresolved-symbols

so that these cases are caught at link time.

HOWEVER!  That will not help here.

In fact, libdofork.so *is* being built correctly, and properly binds to
fork@GLIBC_2.2.5, as present in the libc.so library.

Except that at runtime, we bind to the symbol of the same version as present in
libpthread.so.

We made a mistake when removing the fork and vfork symbols from libpthread.
While we did demote the symbol version in libpthread from default to
compatibility, we should have bumped the symbol version in libc at the same
time.  This would have prevented the symbol in libpthread from being considered
for new binaries, forcing the symbol to be resolved from libc.

Come to think of it, we had the same situation of the same symbol version being
provided by two libraries prior to removing fork from libpthread too, so when
providing compatibility symbols we must be mindful of that -- proper
dependencies on libpthread may well not exist.

Which means that using IFUNC to implement the compatibility symbols isn't an
option, as demonstrated by this PR.

So, while we can provide a generic fallback via a simple wrapper for fork, this
situation must be resolved on a per-port basis for vfork.  Either provide a
stub that performs a tail-call, or simply include the full code for vfork
within libpthread.


r~