This makes sense to me. I tracked also the newlib C locale discussion
before, because it caused some problems for me in some baremetal
applications. I agree with having some light-weight options, and we
might even consider how to expose them later to avoid pulling in
newlib string functions to allow tinier footprints at the loss of
standard-compliance.
On Thu, Sep 13, 2018 at 11:35 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
> ----- Am 13. Sep 2018 um 14:07 schrieb joel j...@rtems.org:
>
>> On Thu, Sep 13, 2018, 3:28 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello,
>>>
>>> I test currently the tqm8xx BSP which worked fine until RTEMS 5. The
>>> problem is that this BSP uses strtoul() to get some system configuration
>>> parameters from the boot loader. The Newlib used by RTEMS 5 has now
>>> support for C locales in strtoul(). The C locale support needs an
>>> executing thread with a valid Newlib reentrancy structure. This is
>>> definitely not the case during bsp_start().
>>>
>>
>> Why do we now longer have a global reentrancy structure to fall back on?
>
> I think having a global reentrancy as a fall back just for the lowest level
> system start without an idle thread is a bit of overkill.
>
> The heavy weight C local support which was recently introduced in Newlib is
> not really the right thing for the embedded systems I know. There were
> several complaints about this on the Newlib mailing list as well. The root
> cause for this is the C standard. So, basically the C standard strtoul() is
> unsuitable for embedded systems. The FreeBSD (sys/kern/strtoul.c) and Linux
> (lib/kstrtox.c) kernel have their own implementations.
>
>>
>> If you disable newlib reentrancy via confdefs.h, what happens?
>
> This configuration option is not really great. It results in
>
> #if defined(RTEMS_NEWLIB)
> struct _reent *__getreent(void)
> {
> #ifdef CONFIGURE_DISABLE_NEWLIB_REENTRANCY
> return _GLOBAL_REENT;
> #else
> return _Thread_Get_executing()->libc_reent;
> #endif
> }
> #endif
>
> Since the configuration object is normally directly presented to the linker,
> we have a reference to _global_impure_ptr which is a heavy weight object. For
> low end targets, we need something better.
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
