[Buildroot] Blackfin Buildroot toolchain issue

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Hello Gustavo,

I believe you originally added the support to build a Blackfin
toolchain with the Buildroot internal toolchain backend. Today, I've
added an external Blackfin toolchain built by Buildroot in the
autobuilder, and one build failure occurred with this toolchain, on the
Bellagio package:

  http://autobuild.buildroot.org/results/05f/05fa9cb522514e9e5b9e81893f145aab00abd803/build-end.log

I reproduced the build issue here, and the config.log contains:

configure:3298: checking whether the C++ compiler works
configure:3320: /home/thomas/projets/buildroot/output/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_O
FFSET_BITS=64   -Os  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  conftest.cpp  >&5
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/4.5.4/../../../../bfin-buildr
oot-linux-uclibc/bin/ld: a.out: hidden symbol `___udivdi3' in /home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib
/gcc/bfin-buildroot-linux-uclibc/4.5.4/libgcc.a(_udivdi3.o) is referenced by DSO
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/4.5.4/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

If you have an idea on how to fix this, it would be useful.

Thanks a lot!

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

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Gustavo,

On Sun, 15 Mar 2015 22:17:22 +0100, Thomas Petazzoni wrote:
> Hello Gustavo,
> 
> I believe you originally added the support to build a Blackfin
> toolchain with the Buildroot internal toolchain backend. Today, I've
> added an external Blackfin toolchain built by Buildroot in the
> autobuilder, and one build failure occurred with this toolchain, on the
> Bellagio package:
> 
>   http://autobuild.buildroot.org/results/05f/05fa9cb522514e9e5b9e81893f145aab00abd803/build-end.log

There was also another issue, on alsa-lib:

  http://autobuild.buildroot.org/results/b6c/b6c5dc4c4bfed3e23ebb698bc3b262798fcbedd9/build-end.log

.libs/error.o: In function `_snd_lib_error_default':
error.c:(.text+0xca): undefined reference to `___emutls_get_address'
.libs/error.o: In function `_snd_lib_error_set_local':
error.c:(.text+0x15a): undefined reference to `___emutls_get_address'
error.c:(.text+0x166): undefined reference to `___emutls_get_address'

Thanks,

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

[Buildroot] Blackfin Buildroot toolchain issue

[Gustavo Zacarias]

On 03/15/2015 06:18 PM, Thomas Petazzoni wrote:

> There was also another issue, on alsa-lib:
> 
>   http://autobuild.buildroot.org/results/b6c/b6c5dc4c4bfed3e23ebb698bc3b262798fcbedd9/build-end.log
> 
> .libs/error.o: In function `_snd_lib_error_default':
> error.c:(.text+0xca): undefined reference to `___emutls_get_address'
> .libs/error.o: In function `_snd_lib_error_set_local':
> error.c:(.text+0x15a): undefined reference to `___emutls_get_address'
> error.c:(.text+0x166): undefined reference to `___emutls_get_address'

This seems to be a problem with the internal toolchain since we don't
enable tls for gcc, whereas ADIs toolchain does.
Which may point to alsa-lib requiring toolchain tls support.
Regards.

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 17 Mar 2015 11:20:29 -0300, Gustavo Zacarias wrote:

> This seems to be a problem with the internal toolchain since we don't
> enable tls for gcc, whereas ADIs toolchain does.

I think we should make the TLS option a blind option, and have it
unconditionally enabled, except if the architecture doesn't support it.

> Which may point to alsa-lib requiring toolchain tls support.

Indeed:

#ifndef DOC_HIDDEN
#ifdef HAVE___THREAD
#define TLS_PFX         __thread
#else
#define TLS_PFX         /* NOP */
#endif
#endif

static TLS_PFX snd_local_error_handler_t local_error = NULL;

So when thread support is available, alsa-lib assumes TLS support is there.

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

[Buildroot] Blackfin Buildroot toolchain issue

[Gustavo Zacarias]

On 03/17/2015 11:30 AM, Thomas Petazzoni wrote:

> Dear Gustavo Zacarias,
> 
> On Tue, 17 Mar 2015 11:20:29 -0300, Gustavo Zacarias wrote:
> 
>> This seems to be a problem with the internal toolchain since we don't
>> enable tls for gcc, whereas ADIs toolchain does.
> 
> I think we should make the TLS option a blind option, and have it
> unconditionally enabled, except if the architecture doesn't support it.

There's this as well:
https://bugs.busybox.net/show_bug.cgi?id=7921
Which basically boils down to uclibc NPTL requiring TLS.
I'll check for space savings to see if it makes sense for it to even be
an option.
Regards.

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 17 Mar 2015 12:08:16 -0300, Gustavo Zacarias wrote:

> There's this as well:
> https://bugs.busybox.net/show_bug.cgi?id=7921
> Which basically boils down to uclibc NPTL requiring TLS.
> I'll check for space savings to see if it makes sense for it to even be
> an option.

I think it might make sense to keep it a blind option so that we don't
do --enable-tls on architectures that don't have TLS support at all (if
that even exists).

I have something like that in one of my branches:

commit 2ea50f3887747d6b72d6b133806d8b3ff995fe4a
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Wed Mar 11 23:05:00 2015 +0100

    gcc: make TLS option a blind option
    
    The current BR2_GCC_ENABLE_TLS option can lead users to create a
    non-working configuration: if they choose uClibc with NPTL and disable
    TLS support. This is bug #7921.
    
    Since TLS support is really an internal thing, it doesn't make a lot
    of sense to have a visible option for this. Therefore, this commit
    turns it to a blind option: TLS support is enabled in the compiler if
    glibc, eglibc or uClibc NPTL are used, and is disabled otherwise.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index 1a5281c..120d4d8 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -109,12 +109,9 @@ config BR2_TOOLCHAIN_BUILDROOT_CXX
          your target system.
 
 config BR2_GCC_ENABLE_TLS
-       bool "Enable compiler tls support" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
+       bool
        default y
        depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_EGLIBC || BR2_TOOLCHAIN_BUILDROOT_GLIBC
-       help
-         Enable the compiler to generate code for accessing
-         thread local storage variables
 
 config BR2_GCC_ENABLE_LTO
        bool "Enable compiler link-time-optimization support"


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

[Buildroot] Blackfin Buildroot toolchain issue

[Gustavo Zacarias]

On 03/17/2015 12:13 PM, Thomas Petazzoni wrote:

> Dear Gustavo Zacarias,
> 
> On Tue, 17 Mar 2015 12:08:16 -0300, Gustavo Zacarias wrote:
> 
>> There's this as well:
>> https://bugs.busybox.net/show_bug.cgi?id=7921
>> Which basically boils down to uclibc NPTL requiring TLS.
>> I'll check for space savings to see if it makes sense for it to even be
>> an option.
> 
> I think it might make sense to keep it a blind option so that we don't
> do --enable-tls on architectures that don't have TLS support at all (if
> that even exists).

If blackfin supports it, everyone does ;)

>  config BR2_GCC_ENABLE_TLS
> -       bool "Enable compiler tls support" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
> +       bool
>         default y
>         depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_EGLIBC || BR2_TOOLCHAIN_BUILDROOT_GLIBC
> -       help
> -         Enable the compiler to generate code for accessing
> -         thread local storage variables

Makes sense, the previous conditions were flawed as blackfin showed us,
no nptl but tls was there just fine.
Regards.

[Buildroot] Blackfin Buildroot toolchain issue

[Waldemar Brodkorb]

Hi,
Gustavo Zacarias wrote,

> On 03/17/2015 12:13 PM, Thomas Petazzoni wrote:
> 
> > Dear Gustavo Zacarias,
> > 
> > On Tue, 17 Mar 2015 12:08:16 -0300, Gustavo Zacarias wrote:
> > 
> >> There's this as well:
> >> https://bugs.busybox.net/show_bug.cgi?id=7921
> >> Which basically boils down to uclibc NPTL requiring TLS.
> >> I'll check for space savings to see if it makes sense for it to even be
> >> an option.
> > 
> > I think it might make sense to keep it a blind option so that we don't
> > do --enable-tls on architectures that don't have TLS support at all (if
> > that even exists).
> 
> If blackfin supports it, everyone does ;)

My opinion on this is, that there are systems supporting threads
with uClibc, which do not have TLS support. Linuxthreads.old does
not make use of TLS. When you build for coldfire or ARM noMMU, tls 
is not available and it should be disabled while configuring gcc.

I am wondering why Blackfin enables TLS without any NPTL support.

best regards
 Waldemar

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Dear Waldemar Brodkorb,

On Tue, 17 Mar 2015 22:34:03 +0100, Waldemar Brodkorb wrote:

> My opinion on this is, that there are systems supporting threads
> with uClibc, which do not have TLS support. Linuxthreads.old does
> not make use of TLS. When you build for coldfire or ARM noMMU, tls 
> is not available and it should be disabled while configuring gcc.

Sure, but we don't have to make this an option. The plan is to enable
TLS only when available.

Best regards,

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

[Buildroot] Blackfin Buildroot toolchain issue

[Waldemar Brodkorb]

Hi,
Thomas Petazzoni wrote,

> Dear Waldemar Brodkorb,
> 
> On Tue, 17 Mar 2015 22:34:03 +0100, Waldemar Brodkorb wrote:
> 
> > My opinion on this is, that there are systems supporting threads
> > with uClibc, which do not have TLS support. Linuxthreads.old does
> > not make use of TLS. When you build for coldfire or ARM noMMU, tls 
> > is not available and it should be disabled while configuring gcc.
> 
> Sure, but we don't have to make this an option. The plan is to enable
> TLS only when available.

Yeah, that would be very good.

best regards
 Waldemar

[Buildroot] Blackfin Buildroot toolchain issue

[Gustavo Zacarias]

On 03/15/2015 06:17 PM, Thomas Petazzoni wrote:

> Hello Gustavo,
> 
> I believe you originally added the support to build a Blackfin
> toolchain with the Buildroot internal toolchain backend. Today, I've
> added an external Blackfin toolchain built by Buildroot in the
> autobuilder, and one build failure occurred with this toolchain, on the
> Bellagio package:

Hi.
I'll take a look, but my efforts regarding the blackfin toolchain were a
"best effort" scenario - just getting the toolchain to build where it
didn't before.
I have no hardware to test anything so even if it builds it might not
work correctly at all.
In the mean time i've sent a patch to switch blackfin's default to an
external (ADI) toolchain.
Regards.

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 17 Mar 2015 10:45:33 -0300, Gustavo Zacarias wrote:

> I'll take a look, but my efforts regarding the blackfin toolchain were a
> "best effort" scenario - just getting the toolchain to build where it
> didn't before.
> I have no hardware to test anything so even if it builds it might not
> work correctly at all.

Sure. So we need to decide whether it's worth support Blackfin in the
internal toolchain backend at all.

> In the mean time i've sent a patch to switch blackfin's default to an
> external (ADI) toolchain.

Great. But I've recently added a Buildroot-generated Blackfin external
toolchain in the autobuilder toolchain configurations, so we need to
decide if we want to support that or not.

From my point of view, since Blackfin already requires a very specific
combination of compiler + binutils version, it's a bit of a dead end in
terms of internal toolchain support, so we could just as well get rid
of it entirely.

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

[Buildroot] Blackfin Buildroot toolchain issue

[Gustavo Zacarias]

On 03/17/2015 10:49 AM, Thomas Petazzoni wrote:

> Sure. So we need to decide whether it's worth support Blackfin in the
> internal toolchain backend at all.
> 
>> In the mean time i've sent a patch to switch blackfin's default to an
>> external (ADI) toolchain.
> 
> Great. But I've recently added a Buildroot-generated Blackfin external
> toolchain in the autobuilder toolchain configurations, so we need to
> decide if we want to support that or not.
> 
> From my point of view, since Blackfin already requires a very specific
> combination of compiler + binutils version, it's a bit of a dead end in
> terms of internal toolchain support, so we could just as well get rid
> of it entirely.

Back when i enabled it, the ADI toolchain gcc was pretty old compared to
what we got with this.
But newer gcc versions are broken, and although it may be something
simple to fix, i'm not inclined to dig further.
So it's probably best to just disable it, after all if someone wants to
throw some time into fixing it, it's just a line away from re-enabling
it and doing so.
Regards.

[Buildroot] Blackfin Buildroot toolchain issue

[Thomas Petazzoni]

Hello,

On Tue, 17 Mar 2015 11:40:30 -0300, Gustavo Zacarias wrote:

> Back when i enabled it, the ADI toolchain gcc was pretty old compared to
> what we got with this.
> But newer gcc versions are broken, and although it may be something
> simple to fix, i'm not inclined to dig further.

Yeah, me neither.

> So it's probably best to just disable it, after all if someone wants to
> throw some time into fixing it, it's just a line away from re-enabling
> it and doing so.

Yes, I believe it's the sanest / easiest solution. Can you send a patch
to disable Blackfin in the internal toolchain backend ?

I'll remove the Buildroot generated Blackfin external toolchain from
the autobuilders.

Thanks,

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

[Buildroot] Blackfin Buildroot toolchain issue

[Gustavo Zacarias]

On 03/17/2015 11:43 AM, Thomas Petazzoni wrote:

>> So it's probably best to just disable it, after all if someone wants to
>> throw some time into fixing it, it's just a line away from re-enabling
>> it and doing so.
> 
> Yes, I believe it's the sanest / easiest solution. Can you send a patch
> to disable Blackfin in the internal toolchain backend ?
> 
> I'll remove the Buildroot generated Blackfin external toolchain from
> the autobuilders.

Sent, thanks.
Regards.