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

[Joern Rennecke <joern dot rennecke at embecosm dot com>]

For embedded targets with small memories and static linking, the size of
functions like *printf and their dependencies is painful, particularily for
targets that need software floating point.

avr-libc has long had a printf / scanf implementation that by default does not
include floating point support.  There's a library that can be liked to provide
the floating-point enabled functions, but the required functions have
to be pulled
in manually with -Wl,-u if they are otherwise only referenced from libc, lest
these symbols got resolved with the integer-only implementations from
libc itself.
All in all, a rather unsatisfying state of affairs when trying to run the
gcc regression test suite.

Newlib also has an integer-only printf implementation, but in this case,
the default is the other way round - you have to use functions with nonstandard
names to use the integer-only implementations.  And a half-hearted approach to
use this can easily end up with linking in both the integer-only version and the
floating-point enabled one, resulting in increased executable size instead of
a saving.

I think we can do better with integrated compiler/linker support.
Trying to do a perfect job i of course impossible because of Rice's theorem,
but it doesn't have to be perfect to be useful.
Just looking statically at each *printf statement, we can look at the format
strings and/or the passed arguments.
Floating point arguments are easier to check for by the compiler than parsing
the format string.  There is already code that parses the format strings for the
purpose of warnings, but it would be a somewhat intrusive change to add this
functionality there, and the information is not available where a variable
format is used anyway.
In a standards-conformant application, floating point formats can only be used
with floating point arguments, so checking for the latter seems most effective.

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

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.

Now Joerg Wunsch suggested we might want to facto out more pieces, like the
long long support.  This quickly leads to a combinatorial explosion.
If we want to support a more modular *printf / *scanf, than maybe a different
approach is warranted.
Say, if we could give a symbol and section attribute and/or pragma to individual
case labels of a switch, and put the different pieces into separate object
files (maybe with a bit of objcopy massaging).
The symbols references to trigger the inclusion of the case objects could be
generated by the gcc backend by processing suitably annotated function calls.
E.g. we might put something into CALL_FUNCTION_USAGE, or play with
TARGET_ENCODE_SECTION_INFO.