new aarch64 test failure in Fedora Rawhide: __getauxval

new aarch64 test failure in Fedora Rawhide: __getauxval

[DJ Delorie via Libc-alpha]

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?

Re: new aarch64 test failure in Fedora Rawhide: __getauxval

[Szabolcs Nagy]

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.

RE: new aarch64 test failure in Fedora Rawhide: __getauxval

[Kyrylo Tkachov]

> -----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