Re: Increased RAM usage after upgrade to newlib 4.3.0
"Richard Earnshaw (foss)" <[email protected]> Mon, 2 Feb 2026 11:09:54 +0000
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On 02/02/2026 10:44, Pavel V. Melnikov wrote: > On Thu, 22 Jan 2026 at 13:43, Richard Earnshaw (foss) > <[email protected]> wrote: >> >> On 20/01/2026 10:44, Pavel V. Melnikov wrote: >>> Dear Sebastian and newlib group! >>> >>> While trying to upgrade my ARM toolchain from GCC 9 to 12, I've >>> encountered the same problem that is discussed in this thread, i.e. >>> RAM usage suddenly increased by around 300b without changes in the >>> code and compiler flags. I traced it to an extra __sf symbol in the >>> linker map file. I couldn't find any non-hacky solution online, but >>> found some people encountering it as well, e.g. here: >>> https://stackoverflow.com/questions/78635407 >>> >>> In my project I don't use stdio functions, and __sf objects are pulled >>> if I use `snprintf` function, which, to my understanding, does not >>> need stdio FDs to work. It seems it's used because it's referenced in >>> impure.c and reent implementation. >>> I'm using an ARM MCU with only 4Kb of RAM and would very much like to >>> avoid spending extra 300b on things I don't use. >>> My question is whether there was any development on this since this >>> topic was raised in 2023. Can you suggest a way to drop the stdio fds >>> when not using stdio in newer newlib (4.3+)? Since you mentioned it's >>> a regression, could this be considered for a fix in future versions? >>> >> >> If you write out a linker map during the linking step you should be able to work out the chain of dependencies to the functions you're not expecting. If linking using GCC as the driver just add -Wl,-Map=<mapfile> to your linker options. > > Hello Richard, > > On Thu, 22 Jan 2026 at 13:43, Richard Earnshaw (foss) > <[email protected]> wrote: >> >> If you write out a linker map during the linking step you should be able to work out the chain of dependencies to the functions you're not expecting. If linking using GCC as the driver just add -Wl,-Map=<mapfile> to your linker options. >> > > Thanks for your suggestion. I was able to trace the symbol usage to > _impure_data array, which is used by vsnprintf function (via > _impure_ptr). So, I learned that non-file sprintf is implemented using > file-based printf, which in turn pulls the global reentrancy structure > with the FDs. So it doesn't look like I can get rid of __sf while > still using sprintf function family in current newlib. At the moment I > decided to stay at GCC 10 as it has decently modern c++20 support and > comes with older newlib 4.2 that doesn't have this issue. > Interesting. I don't have time to look into this in detail, but from your description and looking at the changes that went into 4.3, the following is where I'd start looking: commit b0cb9f85ca3626e0e68fd451c3090d253ceb4300 Author: Sebastian Huber <[email protected]> Date: Tue May 17 18:28:52 2022 +0200 Use global stdio streams for all configurations But both Sebastian and Matt Joyce made a number of changes to the printf code that year and this might be caused by any one of them, or perhaps by another change that I haven't spotted. Hopefully, somebody can find some time to get to the bottom of this. R. > > ___________________________________ > > Best wishes, > Paul Melnikov