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

[H.J. Lu]

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.

We have been using this scheme on i386 to place i686/SSE2 optimized
libraries under sse2/i686 directories.   My patch extends it to x86-64.

-- 
H.J.