[PATCH 4/5] bsps: Thread-local storage (TLS) for linkcmds

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Jan 30 07:33:20 UTC 2014

On 2014-01-29 22:18, Chris Johns wrote:
> On 30/01/2014 1:24 am, Sebastian Huber wrote:
>> On 2014-01-29 15:11, Gedare Bloom wrote:
>>> This one should be verified (compile) for all BSPs..
>> The BSPs compile and link (except the V850, here I get a linker error
>> about incompatible multilibs).
>> The new tests sptls01 and sptls02 don't work on some targets due to
>> incomplete tool chains and/or a missing TLS implementation.
> Sure the BSPs compile but do all BSPs compile ?

The sample programs of all BSPs link.  If you don't use TLS in your 
application, then everything works as usual.

The sptls01 and sptls02 tests don't work on unsupported architectures to 
highlight the problem.

> What is the use case for this with RTEMS ?

The use case is to use current C and C++ standards.

> Is there any user documentation about the supported architectures and its use
> in RTEMS ?

Its not used inside of RTEMS.  It enables a C/C++ language feature.

> My concern is having a feature like this but not every architecture or BSP
> supporting it therefore creating non-portable RTEMS applications.

I have no budget to enable this for every BSP and architecture.  The basic 
problem is that some architectures lack a maintainer and/or active users.

> How do we
> police this not being used in RTEMS and only tested on supported BSPs ? For
> example using TLS to fix the shell's environment task variables for use with SMP.

I do not intend to use TLS inside of RTEMS.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list