[RFC] Adding TLS selection choice to metadata

[RFC] Adding TLS selection choice to metadata

[Khem Raj]

Hi

Enabling TLS support on uclibc/glibc is not sound enough in out build. Reason is we depend upon
various autotools tests to find out if the software combination we chose can support it or not
and these tests are not doing the correct think many times.

TLS is a libc feature from software POV. Implementation also depends upon hardware if there is
some special support available. 

Right now we have TLS support enabled by default in toolchain which works ok for newer glibc which have
TLS support in both Linuxthreads as well as nptl but it does not work so well with uclibc
and I think same will be case with klibc.

We need to disable it in the cross compiler while building the compiler so the TLS tests in 
subsequent applications which only tests for __thread acceptence dont assume that TLS support
is available in the system. 

I thought of putting it in metadata like TARGET_FPU and which can then be set from various other 
conf files.

A cheap workaround is that we could assume that TLS is only supported for glibc and disable it
for other libc variants but then NPTL is coming (whenever it comes) in uclibc so some architectures
in uclibc will support NPTL and some wont. Therefore defining it in metadata will give us the 
fine granularity to set it.

Ideas ?

Thanks

-Khem

Re: [RFC] Adding TLS selection choice to metadata

[Tom Rini]

On Tue, Jul 28, 2009 at 12:22:02AM -0700, Khem Raj wrote:

> I thought of putting it in metadata like TARGET_FPU and which can then be set from various other 
> conf files.
> 
> A cheap workaround is that we could assume that TLS is only supported for glibc and disable it
> for other libc variants but then NPTL is coming (whenever it comes) in uclibc so some architectures
> in uclibc will support NPTL and some wont. Therefore defining it in metadata will give us the 
> fine granularity to set it.

For the sake of other libcs, I like TARGET_TLS or whatever it's called.

-- 
Tom Rini

Re: [RFC] Adding TLS selection choice to metadata

[Holger Hans Peter Freyther]

On Tuesday 28 July 2009 09:22:02 Khem Raj wrote:
> Hi
>
> Enabling TLS support on uclibc/glibc is not sound enough in out build.
> Reason is we depend upon various autotools tests to find out if the
> software combination we chose can support it or not and these tests are not
> doing the correct think many times.

Have you seen the patch I sent? The title was 
[oe] [PATCH] gcc: Pass --enable-tls=no on uclibc builds...


z.

Re: [RFC] Adding TLS selection choice to metadata

[Holger Hans Peter Freyther]

On Wednesday 29 July 2009 09:02:39 Khem Raj wrote:
> On Tue, Jul 28, 2009 at 9:14 PM, Holger Hans Peter
>
> Freyther<holger+oe@freyther.de> wrote:
> > On Tuesday 28 July 2009 09:22:02 Khem Raj wrote:
> >> Hi
> >>
> >> Enabling TLS support on uclibc/glibc is not sound enough in out build.
> >> Reason is we depend upon various autotools tests to find out if the
> >> software combination we chose can support it or not and these tests are
> >> not doing the correct think many times.
> >
> > Have you seen the patch I sent? The title was
> > [oe] [PATCH] gcc: Pass --enable-tls=no on uclibc builds...
>
> I did however nptl/uclibc builds we need TLS support to be enabled
> and there is no way to differentiate the triplets for a NPTL uclibc
> toolchain from non NPTL toolchain. In future not all arches will get
> NPTL support
> on uclibc at once so we wil have few arches where NPTL will be there and
> that will require TLS whereas others will use Linux Threads and will
> have to disable TLS.

To cite my patch:

+# The tls/ntpl support in uclibc is work in progress. For the current
+# targets we should build gcc with --enable-tls=no. In the future we
+# might want to enable TLS for certain architectures and uclibc versions
+# so this is why this method exists.
+def get_gcc_uclibc_tls_setting(bb, d):
+    return "--enable-tls=no"


we are basically talking about the same thing? e.g. with the proposed 
TARGET_TLS you would add a if to the above and return "". right?

z.

Re: [RFC] Adding TLS selection choice to metadata

[Khem Raj]

On Tue, Jul 28, 2009 at 9:14 PM, Holger Hans Peter
Freyther<holger+oe@freyther.de> wrote:
> On Tuesday 28 July 2009 09:22:02 Khem Raj wrote:
>> Hi
>>
>> Enabling TLS support on uclibc/glibc is not sound enough in out build.
>> Reason is we depend upon various autotools tests to find out if the
>> software combination we chose can support it or not and these tests are not
>> doing the correct think many times.
>
> Have you seen the patch I sent? The title was
> [oe] [PATCH] gcc: Pass --enable-tls=no on uclibc builds...

I did however nptl/uclibc builds we need TLS support to be enabled
and there is no way to differentiate the triplets for a NPTL uclibc
toolchain from non NPTL toolchain. In future not all arches will get
NPTL support
on uclibc at once so we wil have few arches where NPTL will be there and
that will require TLS whereas others will use Linux Threads and will
have to disable TLS.

Thanks

-Khem

>
>
> z.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] Adding TLS selection choice to metadata

[Phil Blundell]

On Wed, 2009-07-29 at 00:02 -0700, Khem Raj wrote:
> I did however nptl/uclibc builds we need TLS support to be enabled
> and there is no way to differentiate the triplets for a NPTL uclibc
> toolchain from non NPTL toolchain. In future not all arches will get
> NPTL support
> on uclibc at once so we wil have few arches where NPTL will be there and
> that will require TLS whereas others will use Linux Threads and will
> have to disable TLS.

Is it so hard to add the missing tls bits to uclibc's linuxthreads?
That sounds like the best way to solve that problem.

p.

Re: [RFC] Adding TLS selection choice to metadata

[Khem Raj]

On Tue, Jul 28, 2009 at 11:00 PM, Holger Hans Peter
Freyther<holger+oe@freyther.de> wrote:
> On Wednesday 29 July 2009 09:02:39 Khem Raj wrote:
>> On Tue, Jul 28, 2009 at 9:14 PM, Holger Hans Peter
>>
>> Freyther<holger+oe@freyther.de> wrote:
>> > On Tuesday 28 July 2009 09:22:02 Khem Raj wrote:
>> >> Hi
>> >>
>> >> Enabling TLS support on uclibc/glibc is not sound enough in out build.
>> >> Reason is we depend upon various autotools tests to find out if the
>> >> software combination we chose can support it or not and these tests are
>> >> not doing the correct think many times.
>> >
>> > Have you seen the patch I sent? The title was
>> > [oe] [PATCH] gcc: Pass --enable-tls=no on uclibc builds...
>>
>> I did however nptl/uclibc builds we need TLS support to be enabled
>> and there is no way to differentiate the triplets for a NPTL uclibc
>> toolchain from non NPTL toolchain. In future not all arches will get
>> NPTL support
>> on uclibc at once so we wil have few arches where NPTL will be there and
>> that will require TLS whereas others will use Linux Threads and will
>> have to disable TLS.
>
> To cite my patch:
>
> +# The tls/ntpl support in uclibc is work in progress. For the current
> +# targets we should build gcc with --enable-tls=no. In the future we
> +# might want to enable TLS for certain architectures and uclibc versions
> +# so this is why this method exists.
> +def get_gcc_uclibc_tls_setting(bb, d):
> +    return "--enable-tls=no"
>
>

I was thinking of a case when say nptl is supported on mips
but someone still wants to build with linuxthreads. In your patch you
rely upon the target triplet to decide where to enable it and where
not to. a toolchain with nptl/uclibc or
lt/uclibc has same target triplet. So even for nptl
like uclibc_nptl.bb recipe we will have enable-tls=no
which wont be the correct thing.

> we are basically talking about the same thing? e.g. with the proposed
> TARGET_TLS you would add a if to the above and return "". right?
>
> z.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] Adding TLS selection choice to metadata

[Khem Raj]

On Wed, Jul 29, 2009 at 12:29 AM, Phil Blundell<pb@reciva.com> wrote:
> On Wed, 2009-07-29 at 00:02 -0700, Khem Raj wrote:
>> I did however nptl/uclibc builds we need TLS support to be enabled
>> and there is no way to differentiate the triplets for a NPTL uclibc
>> toolchain from non NPTL toolchain. In future not all arches will get
>> NPTL support
>> on uclibc at once so we wil have few arches where NPTL will be there and
>> that will require TLS whereas others will use Linux Threads and will
>> have to disable TLS.
>
> Is it so hard to add the missing tls bits to uclibc's linuxthreads?
> That sounds like the best way to solve that problem.
>

there were discussions around that but not enough interest


> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] Adding TLS selection choice to metadata

[Holger Freyther]

On Wednesday 29 July 2009 19:55:38 Khem Raj wrote:

> > To cite my patch:
> >
> > +# The tls/ntpl support in uclibc is work in progress. For the current
> > +# targets we should build gcc with --enable-tls=no. In the future we
> > +# might want to enable TLS for certain architectures and uclibc versions
> > +# so this is why this method exists.
> > +def get_gcc_uclibc_tls_setting(bb, d):
> > +    return "--enable-tls=no"
>
> I was thinking of a case when say nptl is supported on mips
> but someone still wants to build with linuxthreads. In your patch you
> rely upon the target triplet to decide where to enable it and where
> not to. 

In my patch I solely rely on the power of a turing complete language called 
python. In this python method you can place a:

      if bb.data.getVar("TARGET_TLS", d, True)
           return ""

and be done, in analogue to the FPU setting (hence it is right below the FPU 
code). do you agree?

z.

Re: [RFC] Adding TLS selection choice to metadata

[Khem Raj]

On (30/07/09 09:35), Holger Freyther wrote:
> On Wednesday 29 July 2009 19:55:38 Khem Raj wrote:
> 
> > > To cite my patch:
> > >
> > > +# The tls/ntpl support in uclibc is work in progress. For the current
> > > +# targets we should build gcc with --enable-tls=no. In the future we
> > > +# might want to enable TLS for certain architectures and uclibc versions
> > > +# so this is why this method exists.
> > > +def get_gcc_uclibc_tls_setting(bb, d):
> > > +    return "--enable-tls=no"
> >
> > I was thinking of a case when say nptl is supported on mips
> > but someone still wants to build with linuxthreads. In your patch you
> > rely upon the target triplet to decide where to enable it and where
> > not to. 
> 
> In my patch I solely rely on the power of a turing complete language called 
> python. In this python method you can place a:
> 
>       if bb.data.getVar("TARGET_TLS", d, True)
>            return ""
> 
> and be done, in analogue to the FPU setting (hence it is right below the FPU 
> code). do you agree?

yes that will be ok. 

> 
> z.
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel