Re: Increased RAM usage after upgrade to newlib 4.3.0

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.


___________________________________

Best wishes,
Paul Melnikov