[V3,3/3] gcc10: Revert using __getauxval in libgcc

Submitted by Khem Raj on May 11, 2020, 6:28 p.m. | Patch ID: 172460

Details

Message ID 20200511182812.441561-3-raj.khem@gmail.com
State Master Next
Commit 038ddee4860347c063d207ba17d0577228a42462
Headers show

Commit Message

Khem Raj May 11, 2020, 6:28 p.m. 
This was added recently, but it seems be chewing more than what it
should and causes non glibc packages also depend on it.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-10.1.inc        |  1 +
 ...se-__getauxval-instead-of-getauxval-.patch | 47 +++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc-10.1/0038-Revert-AArch64-Use-__getauxval-instead-of-getauxval-.patch

Patch hide | download patch | download mbox 

diff --git a/meta/recipes-devtools/gcc/gcc-10.1.inc b/meta/recipes-devtools/gcc/gcc-10.1.inc
index 4f383900cf..7d0f17cc10 100644
--- a/meta/recipes-devtools/gcc/gcc-10.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-10.1.inc
@@ -65,6 +65,7 @@  SRC_URI = "\
            file://0035-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch \
            file://0036-Enable-CET-in-cross-compiler-if-possible.patch \
            file://0037-libstdc-v3-Include-system_error-for-std-errc.patch \
+           file://0038-Revert-AArch64-Use-__getauxval-instead-of-getauxval-.patch \
 "
 SRC_URI[sha256sum] = "b6898a23844b656f1b68691c5c012036c2e694ac4b53a8918d4712ad876e7ea2"
 
diff --git a/meta/recipes-devtools/gcc/gcc-10.1/0038-Revert-AArch64-Use-__getauxval-instead-of-getauxval-.patch b/meta/recipes-devtools/gcc/gcc-10.1/0038-Revert-AArch64-Use-__getauxval-instead-of-getauxval-.patch
new file mode 100644
index 0000000000..fc9228277a
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-10.1/0038-Revert-AArch64-Use-__getauxval-instead-of-getauxval-.patch
@@ -0,0 +1,47 @@ 
+From 2101fb718935c7cf1cc2ad201bdeb1e635b54b0a Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Mon, 11 May 2020 11:03:41 -0700
+Subject: [PATCH] Revert "[AArch64] Use __getauxval instead of getauxval in LSE
+ detection code in libgcc"
+
+This reverts commit 5a57016dd2758cc63a544f191f77635342397a72.
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ libgcc/config/aarch64/lse-init.c | 17 ++++++++---------
+ 1 file changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/libgcc/config/aarch64/lse-init.c b/libgcc/config/aarch64/lse-init.c
+index 00e9ab8cd1c..74acef25cce 100644
+--- a/libgcc/config/aarch64/lse-init.c
++++ b/libgcc/config/aarch64/lse-init.c
+@@ -29,20 +29,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ _Bool __aarch64_have_lse_atomics
+   __attribute__((visibility("hidden"), nocommon));
+ 
+-/* Gate availability of __getauxval on glibc.  All AArch64-supporting glibc
+-   versions support it.  */
+-#ifdef __gnu_linux__
++/* Disable initialization of __aarch64_have_lse_atomics during bootstrap.  */
++#if !defined(inhibit_libc) && defined(HAVE_SYS_AUXV_H)
++# include <sys/auxv.h>
+ 
+-# define AT_HWCAP	16
+-# define HWCAP_ATOMICS	(1 << 8)
+-
+-unsigned long int __getauxval (unsigned long int);
++/* Disable initialization if the system headers are too old.  */
++# if defined(AT_HWCAP) && defined(HWCAP_ATOMICS)
+ 
+ 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 /* __gnu_linux__  */
++# endif /* HWCAP */
++#endif /* inhibit_libc */

Comments

Adrian Bunk May 14, 2020, 7:38 a.m. 
On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> This was added recently, but it seems be chewing more than what it
> should and causes non glibc packages also depend on it.
>...

Is this only valgrind (there is a upstream bug open for that),
or were there more recipes with a problem?

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138253): https://lists.openembedded.org/g/openembedded-core/message/138253
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Khem Raj May 14, 2020, 12:47 p.m. 
On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > This was added recently, but it seems be chewing more than what it
> > should and causes non glibc packages also depend on it.
> >...
>
> Is this only valgrind (there is a upstream bug open for that),
> or were there more recipes with a problem?


Just valgrind but problem can happen with static linking with no default
libs in general

>
>
> cu
> Adrian
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138258): https://lists.openembedded.org/g/openembedded-core/message/138258
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Adrian Bunk May 14, 2020, 1:16 p.m. 
On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:
> > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > This was added recently, but it seems be chewing more than what it
> > > should and causes non glibc packages also depend on it.
> > >...
> >
> > Is this only valgrind (there is a upstream bug open for that),
> > or were there more recipes with a problem?
> 
> Just valgrind but problem can happen with static linking with no default
> libs in general

No, it cannot.
The relevant part of "no default libs" is not linking with libc.

Linking statically with libgcc and then providing own implementations
of all libc functions used by libgcc instead of linking with libc is
not a common situation.

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138259): https://lists.openembedded.org/g/openembedded-core/message/138259
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Khem Raj May 14, 2020, 1:56 p.m. 
On Thu, May 14, 2020 at 6:16 AM Adrian Bunk <bunk@stusta.de> wrote:

> On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:
> > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > > This was added recently, but it seems be chewing more than what it
> > > > should and causes non glibc packages also depend on it.
> > > >...
> > >
> > > Is this only valgrind (there is a upstream bug open for that),
> > > or were there more recipes with a problem?
> >
> > Just valgrind but problem can happen with static linking with no default
> > libs in general
>
> No, it cannot.
> The relevant part of "no default libs" is not linking with libc.
>
> Linking statically with libgcc and then providing own implementations
> of all libc functions used by libgcc instead of linking with libc is
> not a common situation.


Take a look At what’s going on in valgrind memcheck build if you are
interested perhaps you will find something which is not yet understood


>
> cu
> Adrian
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138263): https://lists.openembedded.org/g/openembedded-core/message/138263
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Adrian Bunk May 14, 2020, 2:07 p.m. 
On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 6:16 AM Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:
> > > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > > > This was added recently, but it seems be chewing more than what it
> > > > > should and causes non glibc packages also depend on it.
> > > > >...
> > > >
> > > > Is this only valgrind (there is a upstream bug open for that),
> > > > or were there more recipes with a problem?
> > >
> > > Just valgrind but problem can happen with static linking with no default
> > > libs in general
> >
> > No, it cannot.
> > The relevant part of "no default libs" is not linking with libc.
> >
> > Linking statically with libgcc and then providing own implementations
> > of all libc functions used by libgcc instead of linking with libc is
> > not a common situation.
> 
> Take a look At what’s going on in valgrind memcheck build if you are
> interested perhaps you will find something which is not yet understood

Memcheck links statically with libgcc, and it does not link with libc.

This is not a general static linking problem,
normal userspace code links with libc (shared or static).

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138264): https://lists.openembedded.org/g/openembedded-core/message/138264
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Khem Raj May 14, 2020, 2:48 p.m. 
On Thu, May 14, 2020 at 7:07 AM Adrian Bunk <bunk@stusta.de> wrote:

> On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> > On Thu, May 14, 2020 at 6:16 AM Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > > > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:
> > > > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > > > > This was added recently, but it seems be chewing more than what
> it
> > > > > > should and causes non glibc packages also depend on it.
> > > > > >...
> > > > >
> > > > > Is this only valgrind (there is a upstream bug open for that),
> > > > > or were there more recipes with a problem?
> > > >
> > > > Just valgrind but problem can happen with static linking with no
> default
> > > > libs in general
> > >
> > > No, it cannot.
> > > The relevant part of "no default libs" is not linking with libc.
> > >
> > > Linking statically with libgcc and then providing own implementations
> > > of all libc functions used by libgcc instead of linking with libc is
> > > not a common situation.
> >
> > Take a look At what’s going on in valgrind memcheck build if you are
> > interested perhaps you will find something which is not yet understood
>
> Memcheck links statically with libgcc, and it does not link with libc.


Ok what happens when you link it with libc


>
> This is not a general static linking problem,
> normal userspace code links with libc (shared or static).
>
> cu
> Adrian
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138269): https://lists.openembedded.org/g/openembedded-core/message/138269
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Adrian Bunk May 14, 2020, 3:18 p.m. 
On Thu, May 14, 2020 at 07:48:28AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 7:07 AM Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> > > On Thu, May 14, 2020 at 6:16 AM Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > > > > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:
> > > > > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > > > > > This was added recently, but it seems be chewing more than what
> > it
> > > > > > > should and causes non glibc packages also depend on it.
> > > > > > >...
> > > > > >
> > > > > > Is this only valgrind (there is a upstream bug open for that),
> > > > > > or were there more recipes with a problem?
> > > > >
> > > > > Just valgrind but problem can happen with static linking with no
> > default
> > > > > libs in general
> > > >
> > > > No, it cannot.
> > > > The relevant part of "no default libs" is not linking with libc.
> > > >
> > > > Linking statically with libgcc and then providing own implementations
> > > > of all libc functions used by libgcc instead of linking with libc is
> > > > not a common situation.
> > >
> > > Take a look At what’s going on in valgrind memcheck build if you are
> > > interested perhaps you will find something which is not yet understood
> >
> > Memcheck links statically with libgcc, and it does not link with libc.
> 
> Ok what happens when you link it with libc
>...

I do not even want to know how that explodes.

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138270): https://lists.openembedded.org/g/openembedded-core/message/138270
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Adrian Bunk May 14, 2020, 3:29 p.m. 
Disabling -moutline-atomics would also workaround this issue.

And I think it would be the right thing to do for Yocto in any case.

-moutline-atomics makes sense for binary distributions that want to 
offer both high performance for heavily threaded code on >= ARMv8.1
and support ARMv8.0 in the same binaries.

I do not see usecases for this in Yocto that would justify 
the small performance penalty from -moutline-atomics.

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138271): https://lists.openembedded.org/g/openembedded-core/message/138271
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Khem Raj May 14, 2020, 5:18 p.m. 
On 5/14/20 8:29 AM, Adrian Bunk wrote:
> Disabling -moutline-atomics would also workaround this issue.
> 

I think this is a good suggestion and I do not like to revert gcc 
patches if we can avoid doing that. I will propose a fix to disable 
outline-atomics for valgrind on aarch64

> And I think it would be the right thing to do for Yocto in any case.
> 
> -moutline-atomics makes sense for binary distributions that want to
> offer both high performance for heavily threaded code on >= ARMv8.1
> and support ARMv8.0 in the same binaries.
> 
> I do not see usecases for this in Yocto that would justify
> the small performance penalty from -moutline-atomics.
> 
> cu
> Adrian
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138278): https://lists.openembedded.org/g/openembedded-core/message/138278
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Adrian Bunk May 14, 2020, 6:19 p.m. 
On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
> On 5/14/20 8:29 AM, Adrian Bunk wrote:
> > Disabling -moutline-atomics would also workaround this issue.
> 
> I think this is a good suggestion and I do not like to revert gcc patches if
> we can avoid doing that. I will propose a fix to disable outline-atomics for
> valgrind on aarch64
>...

Not just for valgrind, globally.

The main effect in Yocto distributions is (slightly) slower and larger code.

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138286): https://lists.openembedded.org/g/openembedded-core/message/138286
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Khem Raj May 14, 2020, 6:22 p.m. 
On 5/14/20 11:19 AM, Adrian Bunk wrote:
> On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
>> On 5/14/20 8:29 AM, Adrian Bunk wrote:
>>> Disabling -moutline-atomics would also workaround this issue.
>>
>> I think this is a good suggestion and I do not like to revert gcc patches if
>> we can avoid doing that. I will propose a fix to disable outline-atomics for
>> valgrind on aarch64
>> ...
> 
> Not just for valgrind, globally.
> 

so far just doing for valgrind is enough. I am not averse to enabling it 
globally but perhaps we need to do some pre-work to decide that, maybe 
some benchmark numbers.

> The main effect in Yocto distributions is (slightly) slower and larger code.
> 
> cu
> Adrian
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138287): https://lists.openembedded.org/g/openembedded-core/message/138287
Mute This Topic: https://lists.openembedded.org/mt/74142400/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Andrey Zhizhikin May 18, 2020, 7:56 p.m. 
On Thu, May 14, 2020 at 8:22 PM Khem Raj <raj.khem@gmail.com> wrote:
>
>
>
> On 5/14/20 11:19 AM, Adrian Bunk wrote:
> > On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
> >> On 5/14/20 8:29 AM, Adrian Bunk wrote:
> >>> Disabling -moutline-atomics would also workaround this issue.
> >>
> >> I think this is a good suggestion and I do not like to revert gcc patches if
> >> we can avoid doing that. I will propose a fix to disable outline-atomics for
> >> valgrind on aarch64
> >> ...
> >
> > Not just for valgrind, globally.
> >
>
> so far just doing for valgrind is enough. I am not averse to enabling it
> globally but perhaps we need to do some pre-work to decide that, maybe
> some benchmark numbers.

FYI: I've just seen this issue on the [optee-os] as well, build fails
with the same "undefined reference to `__getauxval'". Looks like it is
not only about valgrind...

Any chance anyone had the same problem and proposed fix?

>
> > The main effect in Yocto distributions is (slightly) slower and larger code.
> >
> > cu
> > Adrian
> >
>
Andrey Zhizhikin May 18, 2020, 9:20 p.m. 
On Mon, May 18, 2020 at 9:56 PM Andrey Zhizhikin via
lists.openembedded.org <andrey.z=gmail.com@lists.openembedded.org>
wrote:
>
> On Thu, May 14, 2020 at 8:22 PM Khem Raj <raj.khem@gmail.com> wrote:
> >
> >
> >
> > On 5/14/20 11:19 AM, Adrian Bunk wrote:
> > > On Thu, May 14, 2020 at 10:18:53AM -0700, Khem Raj wrote:
> > >> On 5/14/20 8:29 AM, Adrian Bunk wrote:
> > >>> Disabling -moutline-atomics would also workaround this issue.
> > >>
> > >> I think this is a good suggestion and I do not like to revert gcc patches if
> > >> we can avoid doing that. I will propose a fix to disable outline-atomics for
> > >> valgrind on aarch64
> > >> ...
> > >
> > > Not just for valgrind, globally.
> > >
> >
> > so far just doing for valgrind is enough. I am not averse to enabling it
> > globally but perhaps we need to do some pre-work to decide that, maybe
> > some benchmark numbers.
>
> FYI: I've just seen this issue on the [optee-os] as well, build fails
> with the same "undefined reference to `__getauxval'". Looks like it is
> not only about valgrind...
>
> Any chance anyone had the same problem and proposed fix?

Actually, setting [-mno-outline-atomics] seems to help here, as Adrian
suggested.

I'll see if this could be used further as a fix. Sorry for the noise.

>
> >
> > > The main effect in Yocto distributions is (slightly) slower and larger code.
> > >
> > > cu
> > > Adrian
> > >
> >
>
>
>
> --
> Regards,
> Andrey.
>