System Internals / glibc - Szabolcs Nagy [arm.com] - 6 July 2018 14:58 UTC

This enables searching shared libraries in atomics/ when the hardware supports LSE atomics of armv8.1 so one can provide optimized variants of libraries in a portable way.

LSE atomics does not affect library abi, the new instructions can interoperate with old ones.

I considered the earlier comments on the patch

https://sourceware.org/ml/libc-alpha/2018-04/msg00400.html https://sourceware.org/ml/libc-alpha/2018-04/msg00625.html

It turns out that the way glibc dynamic linker decides on the search path is not very flexible: it wants to use hwcap bits and associated strings. So some targets reuse hwcap bits for glibc internal purposes to affect the search logic. But hwcap is an interface with the kernel, glibc should not allocate bits in it for its internal logic as that limits future hwcap extensions and confusing to users who expect to see hwcap bits in ifunc resolvers. Instead of rewriting the dynamic linker path logic (which affects all targets) this patch just uses the existing mechanism, however this means that the path name has to be the hwcap name "atomics" and cannot be changed to something more meaningful to users.

It is hard to tell how much performance benefit this can give, in principle armv8.1 atomics can be better optimized in the hardware, so it can make a difference for synchronization heavy code. On some systems such multilib setup may be the only viable way to get optimized libraries used.

- sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add HWCAP_ATOMICS.

397c54c1af aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT
ChangeLog | 5 +++++
sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)

Upstream: sourceware.org

  • Share