Memory usage of __global_locale for non-locale functions

Memory usage of __global_locale for non-locale functions

[Prakhar Bahuguna]

Hello,

We've noticed that since a series of patches to add support for POSIX-1.2008
per-thread locales in August 2015, the size of the .data section in binaries
produced by our toolchain has increased significantly due to the
__global_locale struct in lib_a-locale.o. This is linked in when any strto*()
function is called. This is true even for non-locale functions such as
strtoul(). Inspection of the code shows that these have been deliberately
re-architected as simple wrappers around the equivalent strto*_l(), passing in
the global C locale as the locale parameter.

As we wish to minimise code size and particularly RAM usage for microcontroller
targets which do not usually require anything beyond the C locale, would it be
possible to define a configure option that avoids linking in __global_locale,
in a manner that would not require significant engineering effort?
Alternatively, would there be a way to minimise the footprint of the
__global_locale struct for this application?


Thanks,

-- 

Prakhar Bahuguna

Re: Memory usage of __global_locale for non-locale functions

[Hans-Bernhard Bröker]

Am 26.05.2017 um 15:31 schrieb Prakhar Bahuguna:

> We've noticed that since a series of patches to add support for POSIX-1.2008
> per-thread locales in August 2015, the size of the .data section in binaries
> produced by our toolchain has increased significantly due to the
> __global_locale struct in lib_a-locale.o. This is linked in when any strto*()
> function is called. This is true even for non-locale functions such as
> strtoul().

Your classification of stroul() as a non-locale function is wrong.

This general issue has come up before, quite recently:

	https://sourceware.org/ml/newlib/2017/msg00192.html

The answer for you is the same as it was then: a library that does 
support setlocale at all has little chance but to pull in the required 
machinery as soon as any of the localized standard library functions (or 
macros) is referred to by the program.

And no, I don't think there's a configure-time option to disable locale 
altogether.

Re: Memory usage of __global_locale for non-locale functions

[Prakhar Bahuguna]

On 26/05/2017 19:52:10, Hans-Bernhard Bröker wrote:
> Am 26.05.2017 um 15:31 schrieb Prakhar Bahuguna:
> 
> > We've noticed that since a series of patches to add support for POSIX-1.2008
> > per-thread locales in August 2015, the size of the .data section in binaries
> > produced by our toolchain has increased significantly due to the
> > __global_locale struct in lib_a-locale.o. This is linked in when any strto*()
> > function is called. This is true even for non-locale functions such as
> > strtoul().
> 
> Your classification of stroul() as a non-locale function is wrong.
> 
> This general issue has come up before, quite recently:
> 
> 	https://sourceware.org/ml/newlib/2017/msg00192.html
> 
> The answer for you is the same as it was then: a library that does support
> setlocale at all has little chance but to pull in the required machinery as
> soon as any of the localized standard library functions (or macros) is
> referred to by the program.
> 
> And no, I don't think there's a configure-time option to disable locale
> altogether.
> 

Hello,

Thank you for the explanation. In this case, I believe we will have to simply
accept the increase in code size.

-- 

Prakhar Bahuguna