new aarch64 test failure in Fedora Rawhide: __getauxval

Kyrylo Tkachov Kyrylo.Tkachov@arm.com
Tue May 12 08:55:17 GMT 2020



> -----Original Message-----
> From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
> Sent: 12 May 2020 09:49
> To: DJ Delorie <dj@redhat.com>
> Cc: libc-alpha@sourceware.org; carlos@redhat.com; Kyrylo Tkachov
> <Kyrylo.Tkachov@arm.com>
> Subject: Re: new aarch64 test failure in Fedora Rawhide: __getauxval
> 
> The 05/11/2020 22:10, DJ Delorie wrote:
> >
> > In the weekly Rawhide sync this week, I saw a new aarch64 failure:
> >
> > =====FAIL: elf/check-localplt.out=====
> > Extra PLT reference: libc.so: __getauxval
> > =====FAIL: elf/check-localplt.test-result=====
> > FAIL: elf/check-localplt
> >
> > This may be related to a recent gcc patch, which showed up in rawhide
> > on the 7th:
> >
> > commit 1266778548e20de82983b6446f3cb685068cfb1e
> > Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
> > Date:   Wed May 6 16:20:38 2020 +0100
> >
> >     [AArch64] Use __getauxval instead of getauxval in LSE detection code in
> libgcc
> >
> >     This version of the fix uses __getauxval instead of getauxval.
> >     The whole thing is guarded simply on __gnu_linux__.
> >     __getauxval was introduced in 2.16 but the aarch64 port was added in
> 2.17 so in practice I expect all aarch64 glibcs to support __getauxval.
> >
> >     Bootstrapped and tested on aarch64-none-linux-gnu.
> >     Also tested on aarch64-none-elf.
> >
> >     2020-05-06  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
> >
> >             * config/aarch64/lse-init.c (init_have_lse_atomics): Use __getauxval
> >             instead of getauxval.
> >             (AT_HWCAP): Define.
> >             (HWCAP_ATOMICS): Define.
> >             Guard detection on __gnu_linux__.
> >
> > I don't see either getauxval or __getauxval in aarch64's
> > localplt.data, so I'm not sure what's supposed to be happening here.
> > Do we (glibc) need to do something to accomodate this recent gcc
> > change?
> 
> hm i don't think we want __getauxval calls in libc to be
> interposable, instead what we want is that the calls
> introduced by libgcc somehow end up as local calls in libc.
> 
> is there a way to make libgcc calls hidden? if not then
> i guess i should add __getauxval to localplt.data.

I think Joseph commented on this at https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545004.html
Thanks,
Kyrill


More information about the Libc-alpha mailing list