* Joseph Myers: > I think this change is what introduced a glibc testsuite regression in the > localplt test. > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html > > Contents of elf/check-localplt.out: > > Extra PLT reference: libc.so: getauxval > > A reference to getauxval from libgcc is also a namespace violation, since > that name is in the user's namespace and to users may define it with their > own semantics. glibc deliberately provides __getauxval at a public symbol > version for use in libgcc. (But once libgcc is using __getauxval, glibc > will probably still need updating to allow a local PLT reference to > __getauxval from libc.so, as libgcc code that gets statically linked into > libc.so can't use glibc's internal hidden symbol conventions because it > also gets used outside of libc.so.)
I think you are are right. From libgcc/config/aarch64/lse-init.c: static void __attribute__((constructor)) init_have_lse_atomics (void) { unsigned long hwcap = getauxval (AT_HWCAP); __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0; } I should have seen this as the original patches went in, sorry. The question, of course, is if we expect people to call __getauxval, why do we not declare it in the header file? And with sufficient compiler support, redirect callers to that alias? The same question applies to __secure_getenv, where we actually moved in the other direction! This never had made sense to me, and it still does not. Thanks, Florian