This is a continuation of bug 19861, which reported essentially the same issue for fork instead of vfork. vfork is more difficult to fix because of the tail call requirement (otherwise the return address on the stack in the caller can be clobbered by the vfork subprocess).
It currently does not work due to bug 24757.
The master branch has been updated by Florian Weimer <email@example.com>:
Author: Florian Weimer <firstname.lastname@example.org>
Date: Tue Jul 2 15:12:20 2019 +0200
nptl: Remove vfork IFUNC-based forwarder from libpthread [BZ #20188]
With commit f0b2132b35248c1f4a80f62a2c38cddcc802aa8c ("ld.so:
Support moving versioned symbols between sonames [BZ #24741]"), the
dynamic linker will find the definition of vfork in libc and binds
a vfork reference to that symbol, even if the soname in the version
reference says that the symbol should be located in libpthread.
As a result, the forwarder (whether it's IFUNC-based or a duplicate
of the libc implementation) is no longer necessary.
On older architectures, a placeholder symbol is required, to make sure
that the GLIBC_2.1.2 symbol version does not go away, or is turned in
to a weak symbol definition by the link editor. (The symbol version
needs to preserved so that the symbol coverage check in
elf/dl-version.c does not fail for old binaries.)
mips32 is an outlier: It defined __vfork@@GLIBC_2.2, but the
baseline is GLIBC_2.0. Since there are other @@GLIBC_2.2 symbols,
the placeholder symbol is not needed there.
Fixed in 2.30.