Hi all, > -----Original Message----- > From: Florian Weimer <fwei...@redhat.com> > Sent: 04 May 2020 09:35 > To: Joseph Myers <jos...@codesourcery.com> > Cc: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; Andrew Pinski > <pins...@gmail.com>; gcc-patches@gcc.gnu.org; nmeye...@amzn.com > Subject: Re: Should ARMv8-A generic tuning default to -moutline-atomics > > * 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 Joseph for reporting this, I'm testing a patch to replace getauxval with __getauxval. So far it passed GCC bootstrap and testing (I haven't tried the glibc tests yet). Is that the desirable fix at this point in GCC? Thanks, Kyrill > > Thanks, > Florian
