Re: [PATCH] dlsym: Make RTLD_NEXT prefer default version definition [#BZ #14932]

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 27/05/2022 18:03, Fangrui Song via Libc-alpha wrote:
> On 2022-05-27, Florian Weimer wrote:
>> * Fangrui Song:
>>
>>> I suspect the code (from 199x) has a hidden assumption that for a stem
>>> symbol (say foo), the .dynsym entries (say foo@v1, foo@v2, foo@@v3) are
>>> ordered by the version node indices (in .gnu.version_d).
>>
>> Right, the code clearly has this assumption.  There has to be some
>> ordering because we don't want to do a topological sort to find the
>> lowest and highest versions.
>>
>>> If so:
>>>
>>> * (flags & DL_LOOKUP_RETURN_NEWEST) == 0 => the symbol with
>>>     verstab[symidx]==2 will skip the check and be returned
>>> * (flags & DL_LOOKUP_RETURN_NEWEST) != 0 => only the default version
>>>   symbol gets assigned in `*versioned_sym = sym`
>>>
>>> Unfortunately, this assumption hold for none of GNU ld, gold, and
>>> ld.lld (seems unrelated to --hash-style=):
>>>
>>> ```
>>> % ld.bfd @response.txt && readelf -W --dyn-syms nextmod3.so | grep foo@
>>>      5: 0000000000001100     6 FUNC    GLOBAL DEFAULT   13 foo@v1
>>>      8: 0000000000001120     6 FUNC    GLOBAL DEFAULT   13 foo@@v3
>>>      9: 0000000000001110     6 FUNC    GLOBAL DEFAULT   13 foo@v2
>>> % gold @response.txt && readelf -W --dyn-syms nextmod3.so | grep foo@
>>>      7: 00000000000007c0     6 FUNC    GLOBAL DEFAULT   14 foo@@v3
>>>      9: 00000000000007a0     6 FUNC    GLOBAL DEFAULT   14 foo@v1
>>>     10: 00000000000007b0     6 FUNC    GLOBAL DEFAULT   14 foo@v2
>>> % ld.lld @response.txt && readelf -W --dyn-syms nextmod3.so | grep foo@
>>>      7: 0000000000001740     6 FUNC    GLOBAL DEFAULT   13 foo@@v3
>>>      8: 0000000000001720     6 FUNC    GLOBAL DEFAULT   13 foo@v1
>>>      9: 0000000000001730     6 FUNC    GLOBAL DEFAULT   13 foo@v2
>>
>> The order of symbols in the symbol table is not what counts here, it's
>> the order in the list for the hash bucket.
>>
>> I'm not sure if it's possible to dump this with readelf.  I'm writing a
>> custom dumper for this.
>>
>> Thanks,
>> Florian
>>
> llvm-readelf --gnu-hash-table can dump the chain array (`Values:`), with
> the size equal to the number of defined symbols.  The odd numbers
> indicate the end of a chain.
> 
> I believe the .gnu.hash lookup order is in increasing symbol index (in
> all of musl, glibc, FreeBSD rtld).
> So the glibc (flags & DL_LOOKUP_RETURN_NEWEST) == 0 code path (for
> relocations) is wrong...


My understanding is (flags & DL_LOOKUP_RETURN_NEWEST) == 0 is only used for
dlvsym and I think we never documented properly hwo dlvsym (handle, symbol, "")
should behave.  Currently it is different than dlsym (handle, symbol) (it will
return the a versioned symbol), while with your patch it will be similar to dlsym.