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.