mirror of
git://sourceware.org/git/glibc.git
synced 2025-02-17 13:00:43 +08:00
397c54c1af
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. |
||
|---|---|---|
| .. | ||
| aarch64 | ||
| alpha | ||
| arm | ||
| generic | ||
| gnu | ||
| hppa | ||
| htl | ||
| hurd | ||
| i386 | ||
| ia64 | ||
| ieee754 | ||
| init_array | ||
| m68k | ||
| mach | ||
| microblaze | ||
| mips | ||
| nios2 | ||
| nptl | ||
| posix | ||
| powerpc | ||
| pthread | ||
| riscv | ||
| s390 | ||
| sh | ||
| sparc | ||
| unix | ||
| wordsize-32 | ||
| wordsize-64 | ||
| x86 | ||
| x86_64 | ||