Re: printf size requirement

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Dave Korn wrote:
> On 23 April 2007 15:35, Joel Sherrill wrote:
>
>   
> > + wide character support is in both and is about .75K
> >     
>
>   
> > + printf version includes the "mprec" code, references
> >     
>   soft float, etc.
>
>   
> > + both include locale code
> >     
>
>   
> > Even on a bare, minimal target, by the time you flesh
> > out all the missing symbols, how small is "hello world"?
> >
> > And the USD64K question: Can it be smaller?
> >     
>
>   Could try playing with a few of the more advanced configure options:
>
>   

Thanks for the quick reply.  Remember, that RTEMS ships RPMs with a
general purpose RTEMS libc.a which we want to be as functional as possible
while being as small as possible.   So while it is possible for a 
specific RTEMS
user to tailor out something like long long printf support, we have to 
leave it in
for our default configuration.

So the rules of the game are to avoid conditional compilation and let 
link time
solve problems.
>   --enable-newlib-reent-small   enable small reentrant struct support
>   
This looks promising for general RTEMS use since it doesn't sound like it
disables any functionality.  Any ideas how much difference it makes?  It 
looks
pretty substantial.
>   --enable-newlib-io-pos-args enable printf-family positional arg support
>   
I see the code that this disables but can't tell if this is disabling 
something OpenGroup
or POSIX expect to be present.

>   --enable-newlib-io-long-long   enable long long type support in IO functions
> like printf/scanf
>   
Not an option for generic libc building.
>   --enable-newlib-io-long-double   enable long double type support in IO
> functions printf/scanf
>   
Ditto. Not an option for generic libc building.
>   --enable-newlib-mb        enable multibyte support
>   
This looks like a feature which might be worth discussing disabling or 
possibly
adding as a multilib variant.  But it would double the number of 
libc.a's we ship
and with 11 targets and 70 libc.a's already, it doesn't sound appealing.

>   --disable-newlib-atexit-alloc    disable dynamic allocation of atexit
> entries
>   
Interesting trade-off but doesn't this limit you to one atexit() per thread?

Not that it matters.  RTEMS runs atexit() handlers when the "process" 
exits which
is equivalent to the entire RTEMS application shutting down so it might 
not be a big deal.
But still an option that would have to be thought about because of its 
impact on the
general population of applications.

>   --enable-target-optspace  optimize for space
>   
Another possibly useful one to switch but it would take analysis to know 
for sure.
Does anyone have data on the impact of this one on a target like the 
PowerPC,
MIPS, ARM, or SPARC?
>   --disable-newlib-io-float disable printf/scanf family float support
>
>   
Not generally applicable but being able to call iprintf makes me very 
happy. :)

--joel
>     cheers,
>       DaveK
>