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

[Thomas Preud'homme]

> From: Joern Rennecke [mailto:joern.rennecke@embecosm.com]
> Sent: Thursday, August 14, 2014 4:52 PM
> 
> So my idea is to make the compile emit special calls when there are no
> floating
> point arguments.  A library that provides the floating point enabled
> *printf/*scanf
> precedes libc in link order.
> Libc contains the integer-only implementations of *scanf/*printf, in two
> parts:
> entry points with the special function name, which in the same object file
> also contain a reference to the ordinary function name, and another object
> file
> with the ordinary symbol and the integer-only implementation.
> Thus, if any application translation unit has pulled in a floating-point enabled
> implementation, this is the one that'll be used.  Otherwise, the integer-only
> one will be used.
> Use of special sections and alphasorting of these in the linker script
> ensures that the integer-only entry points appear in the right place at
> the start of the chosen implementation.
> If vfprintf is used

What happens in the case that a program contains both some printf and
__int_printf call?

If the undefined printf is resolved first then everything is fine but if it's the
other way around and __int_printf is resolved first the printf implementation
that will be pulled will not have float support and all the call that needs float
support will fail. Did I miss something?

> 
> I've implemented this for AVR with these commits:
> https://github.com/embecosm/avr-
> gcc/commit/3b3bfe33fe29b6d29d8fb96e5d57ee025adf7af0
> https://github.com/embecosm/avr-
> libc/commit/c55eba74838635613c8b80d86a85ed605a79d337
> https://github.com/embecosm/avr-binutils-
> gdb/commit/72b3a1ea3659577198838a7149c6882a079da403
> 
> Although it could use some more testing, and thought how to best
> introduce the change as to avoid getting broken toolchains when
> components
> are out-of-sync.

I didn't do extensive yet but it seems you miss the case of variadic functions.
Consider the example in attachment: two calls to __int_printf will be
generated yet my_printf could be called with the format string "%f\n".

As to the patch it seems to me the macro should be per library, not per backend.
Else two backend supporting newlib would need to write the same code twice.

I'll also try to think how to support the new scheme for printf with float in newlib.
As I said it relies on printf calling _printf_float that is a weak symbol. Previous
scheme could pull 2 implementations of printf and consume more size. The
problem is that compiling newlib with automatic selection would detect some case
where float might be needed (variadic functions) and define _printf_float
accordingly.

Best regards,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto-float-io-failure_1.c
Type: application/octet-stream
Size: 427 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20140826/84243847/attachment.obj>