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

[H.J. Lu]

On Thu, Apr 20, 2017 at 1:51 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.

That is true.  My patch only applies to the external dynamic linker.


-- 
H.J.