Optimizing for size

J. Johnston jjohnstn@redhat.com
Tue Sep 2 22:44:00 GMT 2003

Vincent Rubiolo wrote:
> Hello to you newlib experts,
> I am currently investigating on means to reduce the code size of our 
> project that I ported from ADS 1.2 to GNU toolchain with newlib.
> The perl scripts I use to report sizes of the different parts show that 
> the runtime lib could be one area of such improvements.
> I would like to have your feedback concerning the following points :
> 1. The build of newlib with optimisations for size has no incidence of 
> the library size archive (libc.a) at all. The memory usage (we have two 
> memory zones, RAM and FLASH) is -192 bytes in FLASH and -12 bytes in RAM 
> (retaken over by padding) between the two versions of the library. Can I 
> expect more from the size-optimised version of newlib of are these 
> typical memory improvements?

I assume you are referring to the --enable-target-optspace configuration option.
There are only a few functions that do anything special for this, namely
the generic string functions.  The rest of the library is compiled with
-Os and what optimization occurs is in the compiler's control.

Michael has already informed you about using the iprintf family of functions.
You can optionally configure --disable-newlib-io-float which disables float
support for printf/scanf automatically.  Another thing you can do is to use
the _REENT_SMALL flag.  Smaller platforms set the flag _REENT_SMALL
in libc/include/sys/config.h.  This reduces the initial size of the reentrant struct
at the expense of having to allocate things as needed.  There is currently no configuration
option for this, but I could add one if you are interested.  If you don't care about multibyte support,
you can try --disable-newlib-mb, however, this will only be effective on a platform that
defaults multibyte support.

> 2. Since enabling -fdata-sections and -ffunction-sections flags of gcc 
> along with --gc-sections really improved the size of the binary, I was 
> thinking about tweaking newlib to build in such a way. After having dug 
> into the source, I see that this can be done via C-defines for the 
> mallocr to contain only one function each time. Is there any other less 
> painful way of doing this (such as -fdata-sections and 
> -ffunction-sections)?

Many functions are already broken up to contain either one function per file or interdependent
functions.  Some functions are grouped together because they share complex static helper
routines (e.g. ldtoc.a or dtoa.c).  If the compiler options listed above work on your platform,
you should give them a try.

> Thank you for your consideration.
> Regards,
> Vincent

More information about the Newlib mailing list