RE: selective linking of floating point support for *printf / *scanf

["Thomas Preud'homme" <thomas dot preudhomme at arm dot com>]

> From: Joern Rennecke [mailto:joern.rennecke@embecosm.com]
> Sent: Wednesday, August 27, 2014 7:54 PM
> 
> Well, my goal was to have the selection be automatic for most use cases.
> That you can do a manual selection by providing -u / -l arguments to the
> linker is pretty much a given.
> Hmm, instead of needing -u you could make gcc spit out definitions of a
> dummy
> local symbol to the trigger symbol in question (forcing a non-weak
> reference),
> using SET_ASM_OP (assuming it's defined).  But you'd still be left with the
> extra call overhead, increasing code size no matter if float is needed or not.

That's indeed the approach I took in my own patch.

> 
> Yes.  I'll have to adjust the avr hook that it'll leave the v*printf /
> v*scanf functions
> alone - at least by default / for ISO C behaviour - but it'll give me
> an easy way
> to add a switch to tweak the behaviour.
> 
> Or maybe we can use a -f option to select the v*printf / v*scanf default and
> put the a stdio_altname__int_ target hook in targhooks.c, to be shared by all
> configs that want an __int_ prefix.

Are you aware of other C libraries that would benefit from such a default (newlib
wouldn't)?

Right now I'm having trouble to define stdio_altname in newlib-c.c since this would
require it to be a C target hook but such a hook cannot be called from middle end.

Did I mis(understood|s) something?

> 
> FWIW, to safely shift the symbol into the implementation namespace you
> need a prefix that starts with two underbars or one underbar and a
> capital letter.
> Or use some funny non-standard character in the symbol - but that's asking
> for
> more portability issues.
> For references made automatically by gcc, it's a good idea not to impinge on
> the application namespace.

I'll consider about renaming the symbol but we've been using this one for
some time in our toolchain so it might not be possible to change.

> An application might use printf from <stdio.h>, but define its own functions
> iprintf, printf_float and _printf_float.
> Therefore, it's a good idea to put the definition of newlib's iprintf
> in a separate
> file from __int_printf.  Having essentialy the same contents, but
> defining a different
> symbol, and let the linker match them up to the definition.

I'm confused here. Why would we have a __int_printf? Right now we only
have iprintf as an alias to printf, _printf_float being a weakly defined function
 called from printf for the float support.

Best regards,

Thomas