smaller ramsize for newlib-nano builds

[Sebastian Huber]

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.

-- 
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.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.