[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Romain Naour]

Cairo package fail to build when BR2_TOOLCHAIN_HAS_LIBATOMIC is set and
BR2_TOOLCHAIN_HAS_THREADS_NPTL is not set:
m68k-buildroot-uclinux-uclibc/bin/ld.real: cannot find -latomic

Fixes:
[arm]
http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671
[m68k]
http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 toolchain/toolchain-common.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/toolchain/toolchain-common.in b/toolchain/toolchain-common.in
index 5611b5b..42fee61 100644
--- a/toolchain/toolchain-common.in
+++ b/toolchain/toolchain-common.in
@@ -407,7 +407,7 @@ config BR2_TOOLCHAIN_HAS_SYNC_8
 config BR2_TOOLCHAIN_HAS_LIBATOMIC
 	bool
 	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 && \
-		BR2_TOOLCHAIN_HAS_THREADS
+		BR2_TOOLCHAIN_HAS_THREADS_NPTL
 
 # __atomic intrinsics are available:
 # - with gcc 4.8, either through built-ins or libatomic, on all
-- 
2.5.5

[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Thomas Petazzoni]

Hello,

On Tue,  2 Aug 2016 19:25:55 +0200, Romain Naour wrote:
> Cairo package fail to build when BR2_TOOLCHAIN_HAS_LIBATOMIC is set and
> BR2_TOOLCHAIN_HAS_THREADS_NPTL is not set:
> m68k-buildroot-uclinux-uclibc/bin/ld.real: cannot find -latomic
> 
> Fixes:
> [arm]
> http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671
> [m68k]
> http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Do you have some evidence to explain this NPTL dependency? Indeed,
looking at libatomic/configure.ac in the gcc sources, I only see a test
on thread support, done by testing if pthread_create() is available.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Thomas Petazzoni]

Hello,

On Tue,  2 Aug 2016 19:25:55 +0200, Romain Naour wrote:

>  	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 && \
> -		BR2_TOOLCHAIN_HAS_THREADS
> +		BR2_TOOLCHAIN_HAS_THREADS_NPTL

So, I had a closer look. The crux of the matter is in
libatomic/configure.tgt. There you can see that if a platform uses the
"linux" OS part of the target tuple, libatomic will be generated.
However, if "uclinux" is used, libatomic will not be generated.

So it's not about having NPTL or not, it's about using BR2_BINFMT_FLAT
or not.

Example: the Microblaze architecture does not support NPTL, but
libatomic is generated:

br-microblaze-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... yes

However, on ARM Cortex-M4, and m68k noMMU, we see:

br-arm-cortex-m4-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... no
br-m68k-5208-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... no

Note that it's also not about noMMU vs. MMU, because a noMMU platform
can use FDPIC, in which case the OS part of the tuple would be "linux".

I've therefore updated your patch with this, and applied.

However, it is worth mentioning that changing the gcc code would be
pretty simple: it's about adding *-uclinux-* in
libatomic/configure.tgt. Indeed, libatomic provides a generic posix
implementation, which simply relies on pthread mutex locks to emulate
atomicity. This works on all platforms, as long as thread support is
available, including BR2_BINFMT_FLAT platforms.

People interested in testing this are encouraged to submit patches :-)

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Waldemar Brodkorb]

Hi Thomas,
Thomas Petazzoni wrote,

> Hello,
> 
> On Tue,  2 Aug 2016 19:25:55 +0200, Romain Naour wrote:
> 
> >  	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 && \
> > -		BR2_TOOLCHAIN_HAS_THREADS
> > +		BR2_TOOLCHAIN_HAS_THREADS_NPTL
> 
> So, I had a closer look. The crux of the matter is in
> libatomic/configure.tgt. There you can see that if a platform uses the
> "linux" OS part of the target tuple, libatomic will be generated.
> However, if "uclinux" is used, libatomic will not be generated.
> 
> So it's not about having NPTL or not, it's about using BR2_BINFMT_FLAT
> or not.
> 
> Example: the Microblaze architecture does not support NPTL, but
> libatomic is generated:

This is not completely correct. Musl and GNU Libc support NPTL/TLS
for microblaze. uClibc-ng as of 1.0.17 does not. I am working ?n
syncing GNU libc support for microblaze NPTL/TLS into uClibc-ng,
but have found some issues running the testsuite. (only sjlj
exception handling in upstream gcc, but pthread_cancel requires
DWARF exception handling to work, no real runtime testing in GNU
libc, no active maintainer.)
 
> br-microblaze-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... yes
> 
> However, on ARM Cortex-M4, and m68k noMMU, we see:
> 
> br-arm-cortex-m4-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... no
> br-m68k-5208-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... no
> 
> Note that it's also not about noMMU vs. MMU, because a noMMU platform
> can use FDPIC, in which case the OS part of the tuple would be "linux".
> 
> I've therefore updated your patch with this, and applied.
> 
> However, it is worth mentioning that changing the gcc code would be
> pretty simple: it's about adding *-uclinux-* in
> libatomic/configure.tgt. Indeed, libatomic provides a generic posix
> implementation, which simply relies on pthread mutex locks to emulate
> atomicity. This works on all platforms, as long as thread support is
> available, including BR2_BINFMT_FLAT platforms.
> 
> People interested in testing this are encouraged to submit patches :-)

Hmm. I always disable libatomic for uClibc-ng Linuxthreads and have
to enable it for NPTL/TLS. Isn't libatomic required for NPTL/TLS to
work? Are you sure Linuxthreads can be used for libatomic?
For m68k-noMMU we need to disable it, as it doesn't compile.
https://git.busybox.net/buildroot/tree/package/gcc/6.1.0/891-fix-m68k-uclinux.patch

best regards
 Waldemar

[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Thomas Petazzoni]

Hello,

On Wed, 3 Aug 2016 07:43:09 +0200, Waldemar Brodkorb wrote:

> > Example: the Microblaze architecture does not support NPTL, but
> > libatomic is generated:  
> 
> This is not completely correct. Musl and GNU Libc support NPTL/TLS
> for microblaze. uClibc-ng as of 1.0.17 does not. I am working ?n
> syncing GNU libc support for microblaze NPTL/TLS into uClibc-ng,
> but have found some issues running the testsuite. (only sjlj
> exception handling in upstream gcc, but pthread_cancel requires
> DWARF exception handling to work, no real runtime testing in GNU
> libc, no active maintainer.)

Right, sorry. I should have said "Our uClibc-based Microblaze
toolchain". It does not have NPTL support, but still libatomic is
generated.

> Hmm. I always disable libatomic for uClibc-ng Linuxthreads and have
> to enable it for NPTL/TLS. Isn't libatomic required for NPTL/TLS to
> work?

I don't think it's related. libatomic is needed to provide the
__atomic_*() built-ins when there are not provided directly by the
architecture support. (See my previous work on __sync and __atomic
builtins).

> Are you sure Linuxthreads can be used for libatomic?
> For m68k-noMMU we need to disable it, as it doesn't compile.
> https://git.busybox.net/buildroot/tree/package/gcc/6.1.0/891-fix-m68k-uclinux.patch

The build failure at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
is *NOT* about libatomic, it's about building
libgcc/config/m68k/linux-atomic.c, which is a completely different
thing.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [RFC] toolchain: libatomic needs NTPL threads support

[Romain Naour]

Hi Thomas,

Le 02/08/2016 ? 23:45, Thomas Petazzoni a ?crit :
> Hello,
> 
> On Tue,  2 Aug 2016 19:25:55 +0200, Romain Naour wrote:
> 
>>  	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 && \
>> -		BR2_TOOLCHAIN_HAS_THREADS
>> +		BR2_TOOLCHAIN_HAS_THREADS_NPTL
> 
> So, I had a closer look. The crux of the matter is in
> libatomic/configure.tgt. There you can see that if a platform uses the
> "linux" OS part of the target tuple, libatomic will be generated.
> However, if "uclinux" is used, libatomic will not be generated.
> 
> So it's not about having NPTL or not, it's about using BR2_BINFMT_FLAT
> or not.

I wasn't sure about this fix, I just observed that
BR2_TOOLCHAIN_HAS_THREADS_NPTL was not set for the two toolchain below. At least
it was a starting point for further investigations (thanks).

> 
> Example: the Microblaze architecture does not support NPTL, but
> libatomic is generated:
> 
> br-microblaze-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... yes

Where I can find the log generated from toochains build ?

> 
> However, on ARM Cortex-M4, and m68k noMMU, we see:
> 
> br-arm-cortex-m4-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... no
> br-m68k-5208-full-2016.05-1162-g94c7298-build.log:checking for libatomic support... no
> 
> Note that it's also not about noMMU vs. MMU, because a noMMU platform
> can use FDPIC, in which case the OS part of the tuple would be "linux".
> 
> I've therefore updated your patch with this, and applied.

Thanks for reworking this patch :)

Best regards,
Romain

> 
> However, it is worth mentioning that changing the gcc code would be
> pretty simple: it's about adding *-uclinux-* in
> libatomic/configure.tgt. Indeed, libatomic provides a generic posix
> implementation, which simply relies on pthread mutex locks to emulate
> atomicity. This works on all platforms, as long as thread support is
> available, including BR2_BINFMT_FLAT platforms.
> 
> People interested in testing this are encouraged to submit patches :-)
> 
> Thanks!
> 
> Thomas
>