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.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Reply via email to