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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
