smaller ramsize for newlib-nano builds

[Corinna Vinschen]

On Feb  8 12:05, Sebastian Huber wrote:
> On 02/02/18 11:23, Corinna Vinschen wrote:
> > 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.
> 
> I would replace
> 
> struct _reent
> {
>   int _errno;            /* local copy of errno */
> 
>   /* FILE is a big struct and may change over time.  To try to achieve
> binary
>      compatibility with future versions, put stdin,stdout,stderr here.
>      These are pointers into member __sf defined below.  */
>   __FILE *_stdin, *_stdout, *_stderr;
> [...]
> 
> with something like this:
> 
> thread_local int _errno;
> thread_local __FILE *_stdin;
> thread_local __FILE *_stdout;
> thread_local __FILE *_stderr;
> 
> So, if you only use errno, then you don't get the rest of struct _reent.

Any such change should only affect REENT_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/20180208/8d2549c2/attachment.sig>