Re: Are the pthread "compatibility" copies of symbols in libc still necessary?

[Carlos O'Donell <carlos at redhat dot com>]

On 03/16/2018 09:42 AM, Florian Weimer wrote:
> On 03/16/2018 04:35 PM, Carlos O'Donell wrote:
>> On 03/16/2018 08:41 AM, Florian Weimer wrote:
>>> On 03/16/2018 03:30 PM, Zack Weinberg wrote:
>>>> A number of source files that properly belong to libc.so are also
>>>> compiled as part of libpthread, with a note that this is for
>>>> "compatibility for old binaries".  The exact set varies based on
>>>> architecture, but includes basic things like read, write, and fork - I
>>>> _think_ there was a difference in semantics in the distant past,
>>>> having something to do with thread cancellation.
>>>
>>> They are still needed because versioned symbols also embed a DSO name, and the dynamic linker checks that if it has not been interposed.
>>>
>>> I think it's this code in elf/dl-lookup.c:
>>>
>>>        if (__glibc_unlikely (res < 0) && skip_map == NULL)
>>>      {
>>>        /* Oh, oh.  The file named in the relocation entry does not
>>>           contain the needed symbol.  This code is never reached
>>>           for unversioned lookups.  */
>>>        assert (version != NULL);
>>>        const char *reference_name = undef_map ? undef_map->l_name : "";
>>>        struct dl_exception exception;
>>>        /* XXX We cannot translate the message.  */
>>>        _dl_exception_create_format
>>>          (&exception, DSO_FILENAME (reference_name),
>>>           "symbol %s version %s not defined in file %s"
>>>           " with link time reference%s",
>>>           undef_name, version->name, version->filename,
>>>           res == -2 ? " (no version symbols)" : "");
>>>        _dl_signal_cexception (0, &exception, N_("relocation error"));
>>>        _dl_exception_free (&exception);
>>>        *ref = NULL;
>>>        return 0;
>>>      }
>>>
>>> This is required by the GNU symbol versioning spec, but I don't know why.
>>
>> The specification says the data must be recorded, but it doesn't say what you
>> have to *do* with the data?
> 
> It does:
> 
> “
> A fatal error shall be triggered when no matching definition can be
> found in the object whose name is the one referenced by the vn_name
> element in the Elfxx_Verneed entry.
> ”

I don't know what drove this requirement.

>From a first-principles perspective is doesn't seem to derive from any
foundational aspect of the linkage model.

Can you rationalize the requirement yourself?

Am I missing something?

>>> Even new binaries use these symbols:
>>>
>>> $ LD_DEBUG=bindings systemctl |& grep binding.*system.*libpthread.*[^_]fork
>>>       11905:    binding file /usr/lib/systemd/libsystemd-shared-234.so [0] to /lib64/libpthread.so.0 [0]: normal symbol `fork' [GLIBC_2.2.5]
>>>       11905:    binding file systemctl [0] to /lib64/libpthread.so.0 [0]: normal symbol `fork' [GLIBC_2.2.5]
>>>
>>> This may be a linker bug because at least fork is a compat symbol.
> 
>> Is it a dynamic loader bug that the compat symbol was selected?
> 
> No, I don't think the dynamic linker has to make this distinction, at
> least not if the soname matches the one in the version.

I think the problem is that the two checks are orthogonal.

You have one check to find the versioned symbol based on lookup scopes.

You have another check to determine if a DSO with the appropriate symbol and version exists.

Both of these are true in the fork case.

>> My conclusion is this:
>>
>> * We can remove fork@GLIBC_2.2.5 from libpthread.so, the shared object doesn't
>>    encode it as being needed and won't cause a failure per the rules that
>>    require the referenced shared object to have the versioned symbol that was
>>    bound at static link time.
> 
> I already tried a while bug and failed because the system does not
> boot anymore after that, due to the check mentioned above.  I don't
> think the code has changed since then.

Do you know what failed? I should try this.

Cheers,
Carlos.