> -----Original Message----- > From: Joseph Myers <[email protected]> > Sent: 05 May 2020 22:30 > To: Kyrylo Tkachov <[email protected]> > Cc: Szabolcs Nagy <[email protected]>; Florian Weimer > <[email protected]>; [email protected] > Subject: RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE > detection code in libgcc > > On Tue, 5 May 2020, Kyrylo Tkachov wrote: > > > This version of the fix uses __getauxval instead of getauxval. > > The whole thing is guarded simply on __GLIBC__ >= 2. > > __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. > > Testing __GLIBC__ doesn't work because that's only defined in headers and > the point of duplicating definitions here is to avoid libgcc and thus libc > contents depending on whether headers were available when libgcc was > built. However, given your point that the AArch64 glibc port postdates > the addition of __getauxval to glibc, you can test __gnu_linux__ instead, > as a macro GCC predefines only when configured to use glibc on the target, > and don't need a version test after all.
Right, thanks for the pointer. 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. Checked that the lse-init.o binary contains the __getauxval call for aarch64-none-linux-gnu and is empty for aarch64-none-elf (a newlib target). Is this okay for trunk and the GCC 10 branch? Thanks, Kyrill 2020-05-06 Kyrylo Tkachov <[email protected]> * 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__. > > -- > Joseph S. Myers > [email protected]
ool-glibc.patch
Description: ool-glibc.patch
