All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: [RFC] Adding TLS selection choice to metadata
Date: Tue, 28 Jul 2009 00:22:02 -0700	[thread overview]
Message-ID: <20090728072202.GA5422@gmail.com> (raw)

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





             reply	other threads:[~2009-07-28  7:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-28  7:22 Khem Raj [this message]
2009-07-28 20:14 ` [RFC] Adding TLS selection choice to metadata Tom Rini
2009-07-29  4:14 ` Holger Hans Peter Freyther
2009-07-29  7:02   ` Khem Raj
2009-07-29  6:00     ` Holger Hans Peter Freyther
2009-07-29 17:55       ` Khem Raj
2009-07-30  7:35         ` Holger Freyther
2009-07-30 18:25           ` Khem Raj
2009-07-29  7:29     ` Phil Blundell
2009-07-29 17:56       ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090728072202.GA5422@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.