I used these shell commands:
../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")
and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 6694 files FOO.
I then removed trailing white space from benchtests/bench-pthread-locks.c
and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this
diagnostic from Savannah:
remote: *** pre-commit check failed ...
remote: *** error: lines with trailing whitespace found
remote: error: hook declined to update refs/heads/master
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.htmlhttps://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.
This partially reverts
commit f82e9672ad
Author: Siddhesh Poyarekar <siddhesh@sourceware.org>
aarch64: Allow overriding HWCAP_CPUID feature check using HWCAP_MASK
The idea was to make it possible to disable cpuid based ifunc resolution
in glibc by changing the hwcap mask which the user could already control.
However the hwcap mask has an orthogonal role: it specifies additional
library search paths for the dynamic linker. So "cpuid" got added to
the search paths when it was set in the default mask (HWCAP_IMPORTANT),
which is not useful behaviour, the hwcap masking should not be reused
in the cpu features code.
Meanwhile there is a tunable to set the cpu explicitly so it is possible
to disable the cpuid based dispatch without using a hwcap mask:
GLIBC_TUNABLES=glibc.tune.cpu=generic
* sysdeps/unix/sysv/linux/aarch64/cpu-features.c (init_cpu_features):
Use dl_hwcap without masking.
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT):
Remove HWCAP_CPUID.
Remove unused _DL_HWCAP_LAST definition and move _DL_HWCAP_COUNT
where it is needed (dl-procinfo.h always includes dl-procinfo.c).
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h
(_DL_HWCAP_LAST): Remove.
(_DL_HWCAP_COUNT): Move to ...
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.c
(_DL_HWCAP_COUNT): ... here.
1 << 31 is undefined, so replace it with a cleaner check. Also remove
magic numbers in comments.
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h: Remove
mention of magic numbers in comments.
(_dl_procinfo): Fix undefined behavior
Add support for routines in dl-procinfo.h to show string versions of
HWCAP entries when a program is invoked with the LD_SHOW_AUXV
environment variable set and also to aid in path resolution for
ldconfig.
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.c
(_dl_aarch64_cap_flags): New array.
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h
(_dl_hwcap_string, _dl_string_hwcap, _dl_procinfo): Implement
functions.
Now that LD_HWCAP_MASK (or glibc.tune.hwcap_mask) is read early enough
to influence cpu feature check in aarch64, use it to influence
multiarch selection. Setting LD_HWCAP_MASK such that it clears
HWCAP_CPUID will now disable multiarch for the binary.
HWCAP_CPUID is also now set in HWCAP_IMPORTANT so that it is set by
default. With this patch, this feature is only usable with
dyanmically linked binaries because LD_HWCAP_MASK is not read for
static binaries. A future patch fixes that.
* sysdeps/unix/sysv/linux/aarch64/cpu-features.c
(init_cpu_features): Use glibc.tune.hwcap_mask.
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h: New file.
