smaller ramsize for newlib-nano builds

[Corinna Vinschen]

On Feb  2 07:04, Sebastian Huber wrote:
> On 01/02/18 20:42, Orlando Arias wrote:
> > On 02/01/2018 07:57 AM, Corinna Vinschen wrote:
> > > On Jan 31 17:50, Jaap de Wolff wrote:
> > > > I am working with embedded systems with have very limited ram resources.
> > > > 
> > > > As known current version of the newlib-nano build uses 364 bytes of ram for
> > > > __global_locale
> > > > 
> > > This build option should be available via a configure option, ideally.
> > > Also, the change itself basically changes __global_locale to read only,
> > > so I wonder if the name of the option shouldn't reflect that, kind of
> > > like
> > > 
> > >    ./configure --enable-readonly-locale
> > > 
> > > or
> > > 
> > >    ./configure --enable-const-locale
> > > 
> > > > I realize that MB_CAPABLE must be off for this modification, but are there
> > > > other implications?
> > > I don't think so, but a potential patch submission should make sure that
> > > under normal circumstances no write access occurs with this option.
> > Greetings,
> > 
> > For a while I have been contemplating making a patch set that provides
> > an option to utilize only the C locale, removing all locale stuff from
> > newlib at build time. Moving the __global_locale to ROM may be a good
> > temporary solution, however, it will not work well for resource limited
> > devices. For example, the MSP430F2013 provides only 2 kB of ROM and the
> > MSP430F2003 has only 1 kB. This is about 1/6 and 1/3 of the total
> > program capacity of the device, respectively ( further exacerbating the
> > problem is that these particular devices only provide 128 B of RAM).
> > 
> > Unfortunately, I do not have much time to actually work on this
> > proposal, but I am willing to give it a shot if I can find some
> > documentation on how current locale stuff is implemented in newlib
> > (other than ``the code is the documentation''). Any pointers on this
> > would be greatly appreciated.
> 
> A long term solution (I am not sure if it is feasible in Newlib) would be to
> use C11 thread-local storage instead of the custom thread-local storage via
> the struct _reent. With C11 thread-local storage the linker would do all the
> dirty work.

This wouldn't work with Cygwin which has its own thread-local
implementation.  I'm also not quite sure how this helps here.
The problem is not to create new thread-local locales but the
existence of the global structs  __global_locale and _C_locale.

What we need is somebody tracking the way how __global_locale and
_C_locale are referenced.  This will mainly occur via the inline
accessor functions in newlib/libc/locale/setlocale.h.  The locale
pointer in the reent struct is NULL by default.  It should be possible
to tweak setlocale.h so that it doesn't even try to access these
structs on very small targets.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20180202/d3c2ecc9/attachment.sig>