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

[Fangrui Song <maskray@google.com>]

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...