RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov



> -Original Message-
> From: Joseph Myers 
> Sent: 06 May 2020 15:46
> To: Richard Biener 
> Cc: Kyrylo Tkachov ; Florian Weimer
> ; Szabolcs Nagy ; gcc-
> patc...@gcc.gnu.org; Jakub Jelinek 
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> On Wed, 6 May 2020, Richard Biener wrote:
> 
> > > Here is the updated patch for the record.
> > > Jakub, richi, is this ok for the GCC 10 branch?
> >
> > I'll defer to Joseph who is release manager as well.
> 
> This version is OK with me.

Thank you Joseph,
I've committed this version to trunk and the gcc-10 branch.
Kyrill

> 
> --
> Joseph S. Myers
> jos...@codesourcery.com


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Joseph Myers
On Wed, 6 May 2020, Richard Biener wrote:

> > Here is the updated patch for the record.
> > Jakub, richi, is this ok for the GCC 10 branch?
> 
> I'll defer to Joseph who is release manager as well.

This version is OK with me.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Szabolcs Nagy
The 05/06/2020 11:39, Kyrylo Tkachov wrote:
> > -Original Message-
> > From: Florian Weimer 
> > Sent: 06 May 2020 11:28
> >
> > Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> > all.  musl doesn't have __getauxval IIRC, so it would break the build
> > there.
> 
> I don't think it does (at least not with a git grep for it in the musl code).
> GCC doesn't define it for musl targets either. I see it defined for uclinux 
> for arm, not aarch64 though.

__gnu_linux__ is not defined on musl.

it would be better if there was a mechanism to
introduce namespace clean abi symbols across libc
implementations that a compiler can use, instead
of tying it to the glibc version, but currently
there is no such mechanism and only glibc has this
particular symbol, so the patch looks ok to me.


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Richard Biener via Gcc-patches
On Wed, May 6, 2020 at 1:56 PM Kyrylo Tkachov  wrote:
>
>
>
> > -Original Message-
> > From: Kyrylo Tkachov
> > Sent: 06 May 2020 11:40
> > To: Florian Weimer 
> > Cc: Joseph Myers ; Szabolcs Nagy
> > ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> > ; Richard Biener 
> > Subject: RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > detection code in libgcc
> >
> >
> >
> > > -Original Message-
> > > From: Florian Weimer 
> > > Sent: 06 May 2020 11:28
> > > To: Kyrylo Tkachov 
> > > Cc: Joseph Myers ; Szabolcs Nagy
> > > ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> > > ; Richard Biener 
> > > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > > detection code in libgcc
> > >
> > > * Kyrylo Tkachov:
> > >
> > > > diff --git a/libgcc/config/aarch64/lse-init.c 
> > > > b/libgcc/config/aarch64/lse-
> > init.c
> > > > index 74acef25cce..57236610468 100644
> > > > --- a/libgcc/config/aarch64/lse-init.c
> > > > +++ b/libgcc/config/aarch64/lse-init.c
> > > > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME
> > > respectively.  If not, see
> > > >  _Bool __aarch64_have_lse_atomics
> > > >__attribute__((visibility("hidden"), nocommon));
> > > >
> > > > -/* Disable initialization of __aarch64_have_lse_atomics during 
> > > > bootstrap.
> > > */
> > > > -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> > > > -# include 
> > > > +/* Gate availability of __getauxval on glibc.  All AArch64-supporting 
> > > > glibc
> > > > +   versions support it.  */
> > > > +#ifdef __gnu_linux__
> > > >
> > > > -/* Disable initialization if the system headers are too old.  */
> > > > -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> > > > +# define AT_HWCAP16
> > > > +# define HWCAP_ATOMICS   (1 << 8)
> > > > +
> > > > +unsigned long __getauxval (unsigned long);
> > > >
> > > >  static void __attribute__((constructor))
> > > >  init_have_lse_atomics (void)
> > > >  {
> > > > -  unsigned long hwcap = getauxval (AT_HWCAP);
> > > > +  unsigned long hwcap = __getauxval (AT_HWCAP);
> > > >__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> > > >  }
> > > >
> > > > -# endif /* HWCAP */
> > > > -#endif /* inhibit_libc */
> > > > +#endif /* __gnu_linux__  */
> > >
> > > GNU style is unsigned long int.
> >
> > Thanks, I'll fix that.
>
> Here is the updated patch for the record.
> Jakub, richi, is this ok for the GCC 10 branch?

I'll defer to Joseph who is release manager as well.

Thanks,
Richard.

> Thanks,
> Kyrill
>
> >
> > >
> > > Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> > > all.  musl doesn't have __getauxval IIRC, so it would break the build
> > > there.
> >
> > I don't think it does (at least not with a git grep for it in the musl 
> > code).
> > GCC doesn't define it for musl targets either. I see it defined for uclinux 
> > for
> > arm, not aarch64 though.
> >
> > Thanks,
> > Kyrill
> >
> > >
> > > (This is not a review of the patch. 8-)
> > >
> > > Thanks,
> > > Florian
>


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov


> -Original Message-
> From: Kyrylo Tkachov
> Sent: 06 May 2020 11:40
> To: Florian Weimer 
> Cc: Joseph Myers ; Szabolcs Nagy
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> ; Richard Biener 
> Subject: RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> 
> 
> > -Original Message-
> > From: Florian Weimer 
> > Sent: 06 May 2020 11:28
> > To: Kyrylo Tkachov 
> > Cc: Joseph Myers ; Szabolcs Nagy
> > ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> > ; Richard Biener 
> > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > detection code in libgcc
> >
> > * Kyrylo Tkachov:
> >
> > > diff --git a/libgcc/config/aarch64/lse-init.c b/libgcc/config/aarch64/lse-
> init.c
> > > index 74acef25cce..57236610468 100644
> > > --- a/libgcc/config/aarch64/lse-init.c
> > > +++ b/libgcc/config/aarch64/lse-init.c
> > > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME
> > respectively.  If not, see
> > >  _Bool __aarch64_have_lse_atomics
> > >__attribute__((visibility("hidden"), nocommon));
> > >
> > > -/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.
> > */
> > > -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> > > -# include 
> > > +/* Gate availability of __getauxval on glibc.  All AArch64-supporting 
> > > glibc
> > > +   versions support it.  */
> > > +#ifdef __gnu_linux__
> > >
> > > -/* Disable initialization if the system headers are too old.  */
> > > -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> > > +# define AT_HWCAP16
> > > +# define HWCAP_ATOMICS   (1 << 8)
> > > +
> > > +unsigned long __getauxval (unsigned long);
> > >
> > >  static void __attribute__((constructor))
> > >  init_have_lse_atomics (void)
> > >  {
> > > -  unsigned long hwcap = getauxval (AT_HWCAP);
> > > +  unsigned long hwcap = __getauxval (AT_HWCAP);
> > >__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> > >  }
> > >
> > > -# endif /* HWCAP */
> > > -#endif /* inhibit_libc */
> > > +#endif /* __gnu_linux__  */
> >
> > GNU style is unsigned long int.
> 
> Thanks, I'll fix that.

Here is the updated patch for the record.
Jakub, richi, is this ok for the GCC 10 branch? 
Thanks,
Kyrill

> 
> >
> > Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> > all.  musl doesn't have __getauxval IIRC, so it would break the build
> > there.
> 
> I don't think it does (at least not with a git grep for it in the musl code).
> GCC doesn't define it for musl targets either. I see it defined for uclinux 
> for
> arm, not aarch64 though.
> 
> Thanks,
> Kyrill
> 
> >
> > (This is not a review of the patch. 8-)
> >
> > Thanks,
> > Florian



ool-glibc.patch
Description: ool-glibc.patch


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov



> -Original Message-
> From: Florian Weimer 
> Sent: 06 May 2020 11:28
> To: Kyrylo Tkachov 
> Cc: Joseph Myers ; Szabolcs Nagy
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
> ; Richard Biener 
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> * Kyrylo Tkachov:
> 
> > diff --git a/libgcc/config/aarch64/lse-init.c 
> > b/libgcc/config/aarch64/lse-init.c
> > index 74acef25cce..57236610468 100644
> > --- a/libgcc/config/aarch64/lse-init.c
> > +++ b/libgcc/config/aarch64/lse-init.c
> > @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively.  If not, see
> >  _Bool __aarch64_have_lse_atomics
> >__attribute__((visibility("hidden"), nocommon));
> >
> > -/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.
> */
> > -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> > -# include 
> > +/* Gate availability of __getauxval on glibc.  All AArch64-supporting glibc
> > +   versions support it.  */
> > +#ifdef __gnu_linux__
> >
> > -/* Disable initialization if the system headers are too old.  */
> > -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> > +# define AT_HWCAP  16
> > +# define HWCAP_ATOMICS (1 << 8)
> > +
> > +unsigned long __getauxval (unsigned long);
> >
> >  static void __attribute__((constructor))
> >  init_have_lse_atomics (void)
> >  {
> > -  unsigned long hwcap = getauxval (AT_HWCAP);
> > +  unsigned long hwcap = __getauxval (AT_HWCAP);
> >__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
> >  }
> >
> > -# endif /* HWCAP */
> > -#endif /* inhibit_libc */
> > +#endif /* __gnu_linux__  */
> 
> GNU style is unsigned long int.

Thanks, I'll fix that.

> 
> Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
> all.  musl doesn't have __getauxval IIRC, so it would break the build
> there.

I don't think it does (at least not with a git grep for it in the musl code).
GCC doesn't define it for musl targets either. I see it defined for uclinux for 
arm, not aarch64 though.

Thanks,
Kyrill

> 
> (This is not a review of the patch. 8-)
> 
> Thanks,
> Florian



Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Florian Weimer via Gcc-patches
* Kyrylo Tkachov:

> diff --git a/libgcc/config/aarch64/lse-init.c 
> b/libgcc/config/aarch64/lse-init.c
> index 74acef25cce..57236610468 100644
> --- a/libgcc/config/aarch64/lse-init.c
> +++ b/libgcc/config/aarch64/lse-init.c
> @@ -29,19 +29,20 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  _Bool __aarch64_have_lse_atomics
>__attribute__((visibility("hidden"), nocommon));
>  
> -/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.  */
> -#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
> -# include 
> +/* Gate availability of __getauxval on glibc.  All AArch64-supporting glibc
> +   versions support it.  */
> +#ifdef __gnu_linux__
>  
> -/* Disable initialization if the system headers are too old.  */
> -# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
> +# define AT_HWCAP16
> +# define HWCAP_ATOMICS   (1 << 8)
> +
> +unsigned long __getauxval (unsigned long);
>  
>  static void __attribute__((constructor))
>  init_have_lse_atomics (void)
>  {
> -  unsigned long hwcap = getauxval (AT_HWCAP);
> +  unsigned long hwcap = __getauxval (AT_HWCAP);
>__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
>  }
>  
> -# endif /* HWCAP */
> -#endif /* inhibit_libc */
> +#endif /* __gnu_linux__  */

GNU style is unsigned long int.

Is __gnu_linux__ defined with musl?  It's not really GNU/Linux, after
all.  musl doesn't have __getauxval IIRC, so it would break the build
there.

(This is not a review of the patch. 8-)

Thanks,
Florian



RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-06 Thread Kyrylo Tkachov


> -Original Message-
> From: Joseph Myers 
> Sent: 05 May 2020 22:30
> To: Kyrylo Tkachov 
> Cc: Szabolcs Nagy ; Florian Weimer
> ; gcc-patches@gcc.gnu.org
> 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  

* 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
> jos...@codesourcery.com


ool-glibc.patch
Description: ool-glibc.patch


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-05 Thread Joseph Myers
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.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-05 Thread Joseph Myers
On Tue, 5 May 2020, Szabolcs Nagy wrote:

> > A design principle is that glibc built with libgcc configured without 
> > glibc headers but with --with-glibc-version should produce an identical 
> > stripped binary to the glibc resulting from a longer alternating sequence 
> > of GCC and glibc builds.  So it is not correct for any libgcc 
> > functionality that would end up being linked into glibc binaries to depend 
> > on glibc headers or libraries being available when libgcc is configured.
> > 
> > Thus, this libgcc code should not actually be conditional on 
> > !inhibit_libc, without a fallback when configured using 
> > --with-glibc-version to specify a glibc version with __getauxval, because 
> > that would mean the modern process for bootstrapping a cross glibc build 
> > produces a glibc binary that quietly differs from one produced by a longer 
> > alternating sequence of builds (missing this constructor).
> 
> i.e. libgcc needs to replicate definitions from sys/auxv.h?

Yes.  (This doesn't arise for unwind code, which has rather larger blocks 
of code disabled for inhibit_libc, because that doesn't get statically 
linked into libc.so so it's not a problem for that code to be missing 
from the bootstrap libgcc.)

-- 
Joseph S. Myers
jos...@codesourcery.com


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-05 Thread Kyrylo Tkachov


> -Original Message-
> From: Joseph Myers 
> Sent: 04 May 2020 21:03
> To: Szabolcs Nagy 
> Cc: Kyrylo Tkachov ; Florian Weimer
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> On Mon, 4 May 2020, Szabolcs Nagy wrote:
> 
> > i think __getauxval needs to be declared where it is used.
> 
> Yes.
> 
> > and libgcc should do a link test in configure becasuse a
> > libc may provide sys/auxv.h but not have __getauxval e.g.
> > musl libc does not export __getauxval, only getauxval.
> 
> libgcc can't do link tests, since it's built before libc.  It can use the
> glibc version number ($glibc_version_major and $glibc_version_minor)
> already computed in libgcc/configure.ac, which uses --with-glibc-version
> or target headers if available and otherwise defaults to 0.0.
> 
> A design principle is that glibc built with libgcc configured without
> glibc headers but with --with-glibc-version should produce an identical
> stripped binary to the glibc resulting from a longer alternating sequence
> of GCC and glibc builds.  So it is not correct for any libgcc
> functionality that would end up being linked into glibc binaries to depend
> on glibc headers or libraries being available when libgcc is configured.
> 
> Thus, this libgcc code should not actually be conditional on
> !inhibit_libc, without a fallback when configured using
> --with-glibc-version to specify a glibc version with __getauxval, because
> that would mean the modern process for bootstrapping a cross glibc build
> produces a glibc binary that quietly differs from one produced by a longer
> alternating sequence of builds (missing this constructor).

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.

Bootstrapped and tested on aarch64-none-linux-gnu.
Also tested on aarch64-none-elf and ran the glibc testsuite.

Thanks,
Kyrill

2020-05-05  Kyrylo Tkachov  

* config/aarch64/lse-init.c (init_have_lse_atomics): Use __getauxval
instead of getauxval.
(AT_HWCAP): Define.
(HWCAP_ATOMICS): Define.
Guard detection on __GLIBC__ >= 2.

> 
> --
> Joseph S. Myers
> jos...@codesourcery.com


ool-glibc.patch
Description: ool-glibc.patch


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-05 Thread Szabolcs Nagy
The 05/04/2020 20:02, Joseph Myers wrote:
> On Mon, 4 May 2020, Szabolcs Nagy wrote:
> > i think __getauxval needs to be declared where it is used.
> 
> Yes.
> 
> > and libgcc should do a link test in configure becasuse a
> > libc may provide sys/auxv.h but not have __getauxval e.g.
> > musl libc does not export __getauxval, only getauxval.
> 
> libgcc can't do link tests, since it's built before libc.  It can use the 
> glibc version number ($glibc_version_major and $glibc_version_minor) 
> already computed in libgcc/configure.ac, which uses --with-glibc-version 
> or target headers if available and otherwise defaults to 0.0.
> 
> A design principle is that glibc built with libgcc configured without 
> glibc headers but with --with-glibc-version should produce an identical 
> stripped binary to the glibc resulting from a longer alternating sequence 
> of GCC and glibc builds.  So it is not correct for any libgcc 
> functionality that would end up being linked into glibc binaries to depend 
> on glibc headers or libraries being available when libgcc is configured.
> 
> Thus, this libgcc code should not actually be conditional on 
> !inhibit_libc, without a fallback when configured using 
> --with-glibc-version to specify a glibc version with __getauxval, because 
> that would mean the modern process for bootstrapping a cross glibc build 
> produces a glibc binary that quietly differs from one produced by a longer 
> alternating sequence of builds (missing this constructor).

i.e. libgcc needs to replicate definitions from sys/auxv.h?
like

_Bool flag = 0;

#if GLIBC_VERSION_OK
# define AT_HWCAP ...
# define HWCAP_ATOMICS ...
unsigned long __getauxval (unsigned long);

__attribute__ ((constructor)) static void
init ()
{
  flag = (__getauxval(AT_HWCAP) & HWCAP_ATOMICS) != 0;
}
#endif


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-04 Thread Joseph Myers
On Mon, 4 May 2020, Szabolcs Nagy wrote:

> i think __getauxval needs to be declared where it is used.

Yes.

> and libgcc should do a link test in configure becasuse a
> libc may provide sys/auxv.h but not have __getauxval e.g.
> musl libc does not export __getauxval, only getauxval.

libgcc can't do link tests, since it's built before libc.  It can use the 
glibc version number ($glibc_version_major and $glibc_version_minor) 
already computed in libgcc/configure.ac, which uses --with-glibc-version 
or target headers if available and otherwise defaults to 0.0.

A design principle is that glibc built with libgcc configured without 
glibc headers but with --with-glibc-version should produce an identical 
stripped binary to the glibc resulting from a longer alternating sequence 
of GCC and glibc builds.  So it is not correct for any libgcc 
functionality that would end up being linked into glibc binaries to depend 
on glibc headers or libraries being available when libgcc is configured.

Thus, this libgcc code should not actually be conditional on 
!inhibit_libc, without a fallback when configured using 
--with-glibc-version to specify a glibc version with __getauxval, because 
that would mean the modern process for bootstrapping a cross glibc build 
produces a glibc binary that quietly differs from one produced by a longer 
alternating sequence of builds (missing this constructor).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-04 Thread Szabolcs Nagy
The 05/04/2020 11:34, Kyrylo Tkachov wrote:
> > -Original Message-
> > From: Florian Weimer 
> > Sent: 04 May 2020 11:40
> > To: Kyrylo Tkachov 
> > Cc: gcc-patches@gcc.gnu.org; Joseph Myers 
> > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> > detection code in libgcc
> > 
> > * Kyrylo Tkachov:
> > 
> > > This patch fixes https://gcc.gnu.org/pipermail/gcc-patches/2020-
> > May/545004.html by using __getauxval in the libgcc code.
> > > Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
> > > From what I could gather from my glibc testing the elf/check-localplt test
> > passes.
> > >
> > > Joseph, Florian, does this fix look like what you had in mind?
> > > If I commit it to trunk and the branches will glibc be fine with it?
> > 
> > Doesn't this cause an implicit function declaration warning?
> 
> I don't get such a warning during bootstrap.

i think __getauxval needs to be declared where it is used.

and libgcc should do a link test in configure becasuse a
libc may provide sys/auxv.h but not have __getauxval e.g.
musl libc does not export __getauxval, only getauxval.


RE: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-04 Thread Kyrylo Tkachov



> -Original Message-
> From: Florian Weimer 
> Sent: 04 May 2020 11:40
> To: Kyrylo Tkachov 
> Cc: gcc-patches@gcc.gnu.org; Joseph Myers 
> Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE
> detection code in libgcc
> 
> * Kyrylo Tkachov:
> 
> > This patch fixes https://gcc.gnu.org/pipermail/gcc-patches/2020-
> May/545004.html by using __getauxval in the libgcc code.
> > Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
> > From what I could gather from my glibc testing the elf/check-localplt test
> passes.
> >
> > Joseph, Florian, does this fix look like what you had in mind?
> > If I commit it to trunk and the branches will glibc be fine with it?
> 
> Doesn't this cause an implicit function declaration warning?

I don't get such a warning during bootstrap.
Thanks,
Kyrill

> 
> Thanks,
> Florian



Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-04 Thread Florian Weimer via Gcc-patches
* Kyrylo Tkachov:

> This patch fixes 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545004.html by using 
> __getauxval in the libgcc code.
> Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
> From what I could gather from my glibc testing the elf/check-localplt test 
> passes.
>
> Joseph, Florian, does this fix look like what you had in mind?
> If I commit it to trunk and the branches will glibc be fine with it?

Doesn't this cause an implicit function declaration warning?

Thanks,
Florian



[PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

2020-05-04 Thread Kyrylo Tkachov
Hi all,

This patch fixes https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545004.html 
by using __getauxval in the libgcc code.
Bootstrap and testing on aarch64-none-linux-gnu shows no problem.
>From what I could gather from my glibc testing the elf/check-localplt test 
>passes.

Joseph, Florian, does this fix look like what you had in mind?
If I commit it to trunk and the branches will glibc be fine with it?

Thanks,
Kyrill

2020-05-04  Kyrylo Tkachov  

* config/aarch64/lse-init.c (init_have_lse_atomics): Use __getauxval
instead of getauxval.


ool-auxval.patch
Description: ool-auxval.patch