This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Memory usage of __global_locale for non-locale functions
- From: Prakhar Bahuguna <prakhar dot bahuguna at arm dot com>
- To: Hans-Bernhard Bröker <HBBroeker at t-online dot de>
- Cc: <newlib at sourceware dot org>, <nd at arm dot com>
- Date: Tue, 30 May 2017 09:17:33 +0100
- Subject: Re: Memory usage of __global_locale for non-locale functions
- Authentication-results: sourceware.org; auth=none
- Authentication-results: t-online.de; dkim=none (message not signed) header.d=none;t-online.de; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <20170526133112.mh6nbz2bvn6t2fp5@e107464-lin.cambridge.arm.com> <bf3a89d1-bc7e-7c75-729a-617b0dc401fb@t-online.de>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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