Kernel-space ctypes.h support?

[Joel Sherrill]

On Thu, Sep 13, 2018, 10:34 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> ----- 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.
>

FWIW the FACE Technical Standard does not include wide characters in ANY
profile as of Edition 3.0. None of the RTOS vendors knew of any avionics
users. It wasn't viewed as a necessary feature. We could consider disabling
it by default.

>
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180913/d90ed207/attachment-0002.html>