[PATCH 4/5] bsps: Thread-local storage (TLS) for linkcmds
chrisj at rtems.org
Thu Jan 30 21:55:40 UTC 2014
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.
>> 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
>> 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
We need to document what is supported and what is not supported and if
>> 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.
More information about the devel