* 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
