Kernel-space ctypes.h support?

[Sebastian Huber]

----- Am 13. Sep 2018 um 14:07 schrieb joel joel at rtems.org:

> On Thu, Sep 13, 2018, 3:28 AM Sebastian Huber <
> sebastian.huber at 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.