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

[Chris Johns]

On 30/01/2014 6:33 pm, Sebastian Huber wrote:
> 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.
>

Great.

>>
>> 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.

We need to document what is supported and what is not supported and if 
possible why.

>
>> 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.
>

I would like this established as a rule for the project.

Chris