[PATCH] [BZ #21391] x86: Set dl_platform and dl_hwcap from CPU features

[Florian Weimer]

On 04/19/2017 09:31 PM, H.J. Lu wrote:
> On Wed, Apr 19, 2017 at 12:02 PM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 04/19/2017 08:35 PM, H.J. Lu wrote:
>>>
>>> dl_platform and dl_hwcap are set from AT_PLATFORM and AT_HWCAP very
>>> early during startup.  They are used by dynamic linker to determine
>>> platform and build an array of hardware capability names, which are
>>> added to search path when loading shared object.  dl_platform and
>>> dl_hwcap are unused on x86-64.  On i386, i386, i486, i586 and i686
>>> platforms were supported and only SSE2 capability was used.
>>
>>
>> I don't know where you want to take this, so it's hard to tell if this is
>> going to cause problems eventually.  GLRO is default-initialized in a nested
>> libc (after dlmopen or static dlopen).
>>
> 
> dl_platform and dl_hwcap are used to search for additional directories when
> loading a shared object:
> 
>       15453: find library=libx.so [0]; searching
>       15453: search path=./tls/x86_64:./tls:./x86_64:. (RPATH from file ./m)
>       15453:  trying file=./tls/x86_64/libx.so
>       15453:  trying file=./tls/libx.so
>       15453:  trying file=./x86_64/libx.so
>       15453:  trying file=./libx.so
>       15453:
> 
> My change updates them inside dynamic linker before they are used
> by dynamic linker.  On Haswell class machines, I got
> 
>       19268: find library=libx.so [0]; searching
>       19268: search path=./tls/haswell:./tls:./haswell:. (RPATH from file ./m)
>       19268:  trying file=./tls/haswell/libx.so
>       19268:  trying file=./tls/libx.so
>       19268:  trying file=./haswell/libx.so
> 
> When loading libx.so, it prefers the one in the "haswell" subdirectory.
> One can place shared libraries optimized for Haswell class processors
> under the "haswell" subdirectory.  They will be used on Haswell class
> processors.  It has no impact on static dlopen nor nested libc.

Okay, but only because the external dynamic linker is used, which has a 
fully set up GLRO object.  The default-initialized GLRO object in the 
inner libc is not used in this case.

Thanks,
Florian