Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Mon, May 18, 2020 at 9:56 PM Andrey Zhizhikin via lists.openembedded.org wrote: > > On Thu, May 14, 2020 at 8:22 PM Khem Raj 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. > -- Regards, Andrey. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138437): https://lists.openembedded.org/g/openembedded-core/message/138437 Mute This Topic: https://lists.openembedded.org/mt/74142400/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 8:22 PM Khem Raj 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 > > > -- Regards, Andrey. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138434): https://lists.openembedded.org/g/openembedded-core/message/138434 Mute This Topic: https://lists.openembedded.org/mt/74142400/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 07:48:28AM -0700, Khem Raj wrote: > On Thu, May 14, 2020 at 7:07 AM Adrian Bunk 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 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 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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 7:07 AM Adrian Bunk 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 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 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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote: > On Thu, May 14, 2020 at 6:16 AM Adrian Bunk 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 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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 6:16 AM Adrian Bunk 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 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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote: > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk 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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
On Thu, May 14, 2020 at 12:38 AM Adrian Bunk 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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc
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/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
