On 14/09/2018 18:57, Joel Sherrill wrote:
On Fri, Sep 14, 2018 at 12:57 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> wrote:On 14/09/2018 04:27, Joel Sherrill wrote: > > > On Thu, Sep 13, 2018, 9:25 PM Chris Johns <chr...@rtems.org <mailto:chr...@rtems.org> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote: > > On 14/09/2018 10:13, Joel Sherrill wrote: > > On Thu, Sep 13, 2018, 5:40 PM Chris Johns <chr...@rtems.org <mailto:chr...@rtems.org> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote: > > On 14/09/2018 02:30, Joel Sherrill wrote: > > > On Thu, Sep 13, 2018, 10:34 AM Sebastian Huber > > > <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> > > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>>> > > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> > > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>>>>> > > > wrote: > > > ----- Am 13. Sep 2018 um 14:07 schrieb joel > j...@rtems.org <mailto:j...@rtems.org> <mailto:j...@rtems.org <mailto:j...@rtems.org>> > > <mailto:j...@rtems.org <mailto:j...@rtems.org> <mailto:j...@rtems.org <mailto:j...@rtems.org>>> > > > <mailto:j...@rtems.org <mailto:j...@rtems.org> <mailto:j...@rtems.org <mailto:j...@rtems.org>> > <mailto:j...@rtems.org <mailto:j...@rtems.org> <mailto:j...@rtems.org <mailto:j...@rtems.org>>>>: > > > > > > > On Thu, Sep 13, 2018, 3:28 AM Sebastian Huber < > > > > sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> > > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>>> > > > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> > > <mailto:sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de> > <mailto:sebastian.hu...@embedded-brains.de <mailto: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. > > > > > > > > > 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. > > > > > > > Is this something we could ot would want to control with > newlib via a config > > option? > > > > > > We don't turn on locale for h8, m32c and maybe not epiphany. I > am pretty sure.it <http://sure.it> <http://sure.it> > > <http://sure.it> is an option. And should be a documented RSB > option to turn it > > back on. Should be a size savings for most users. > > We turn on or off as an option? > > > Based on Sebastian's observation, I think off. > > Does this impact wide characters and multibyte? > > We will need to document the impact. I suspect it removes some POSIX > support in a base build. This problem with the C locale support used in strtoul() has absolutely nothing to do with the wide character or iconv() support. Currently it is not possible to disable the C locale support in Newlib. Would such an option be the preferred way instead of a custom strtoul() etc. API and implementation? I think so. It would result in smaller footprint which is desirable for an unlikely to be used feature.I would like to know the impact of only having a single default locale though.
It seems there is already some work in progress in this direction: https://sourceware.org/ml/newlib/2018/msg00889.html -- 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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
