Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf

[Joern Rennecke]

On 27 August 2014 11:41, Thomas Preud'homme <address@hidden> wrote:
>> From: Joern Rennecke [mailto:address@hidden
>> Sent: Wednesday, August 27, 2014 6:13 PM
>>
>> I don't see how it can be any other way.  We want to be able to compile
>> translation units individually, and then let the linker sort out if we need 
>> the
>> floating point enabled implementation(s), and skip the integer-only ones if
>> so.
>
> Consider the new scheme in newlib when printf calls another function for
> handling floating point formats. This other function is weakly defined so
> that it's not pulled by default and printf is effectively integer only. You 
> just
> need to link with an extra -u option to pull in the float support.

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.

>> I'm relying on GNU AS (gas) linker scripts.  That part is
>> unfortunately not so portable,

Oops, of course that should read GNU LD.

> Ok. Of course detecting more cases where an integer version of IO functions
> would be enough would be nice but I'm already satisfied with the current
> scheme. I'm wondering what's happening for v*printf: are they only defined
> in the libc_float?

It's defined in both.  The way i wrote the avr gcc specs / avr-libc
makefile rules,
this will result in the floating point enabled implementation to be
used by default.
Which makes the gcc test results so much nicer...

> Would you accept a patch that would turn this solution into something also
> suitable for newlib? For instance we would need to also include v*printf
> and v*scanf functions into builtin as well.

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.

> A new switch would also be
> needed so that compiling newlib doesn't define the _printf_float and
> _scanf_float symbols because of calls to v*printf and v*scanf functions.
> I need to check if these calls are made in the same file in which case
> I could maybe just guard the function call rewriting by a test checking if the
> caller is itself a builtin.

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.
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.