Re: [PATCH] nptl: Remove vfork IFUNC-based forwarder from libpthread [BZ #20188]

[Florian Weimer <fweimer at redhat dot com>]

* Zack Weinberg:

> On Fri, Jun 28, 2019 at 11:00 AM Florian Weimer <fweimer@redhat.com> wrote:
>> 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.
>
> Can you explain why it is necessary to preserve the GLIBC_2.1.2 symbol
> version in libpthread, even though no normal symbols use that version
> anymore?  (I assume this is about the special symbol defining the
> version itself -- "A GLIBC_2.1.2@@GLIBC_2.1.2" in nm output?)

Three reasons:

The dynamic linker performs a version coverage check for all Verneed
records at load time.  This allows detection of potentially missing
symbols even when lazy binding is used.  If we drop the GLIBC_2.1.2
symbol when it was there before, old binaries will fail to load.

Our Versions file processing logic drops empty version clauses from the
generated version script (but the preprocessor macros are still
generated).

If BFD ld sees a version script which has empty versions, very strange
things happen.  It generates a shared object with Verdef records with
VER_FLG_WEAK.  Linking against such objects causing BFD ld to produce
objects with Vernaux records with VER_FLG_WEAK flag.  This I recall from
investigating this bug:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=24718>

I didn't fully explore the consequences of that.  It's definitely not a
well-tested area of the linker and loader, so I decided to side-step the
issue.

> Otherwise LGTM.

Thanks!

Florian