On 1/30/2014 3:55 PM, Chris Johns wrote: > 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. I think the issue is GCC. There was a discussion on their list this week about this. >>> 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. That's a good idea.
FYI we need to find a way to enforce the standards we have and increase the checks. Chromium uses clang/llvm for some of this but I don't know the details. > Chris > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
