This is the mail archive of the
mailing list for the GCC project.
Re: RFD: selective linking of floating point support for *printf / *scanf
- From: Joey Ye <joey dot ye dot cc at gmail dot com>
- To: Joern Rennecke <joern dot rennecke at embecosm dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>, Joerg Wunsch <joerg_wunsch at uriah dot heep dot sax dot de>, avr-libc-dev at nongnu dot org, Andrew Burgess <andrew dot burgess at embecosm dot com>, "Thomas Preud'homme" <Thomas dot Preudhomme at arm dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Mon, 18 Aug 2014 18:35:42 +0800
- Subject: Re: RFD: selective linking of floating point support for *printf / *scanf
- Authentication-results: sourceware.org; auth=none
- References: <CAMqJFCpWKXVmmc-YLKf9XO6H8C_YnTEcgzkJAidE21MirJbi-w at mail dot gmail dot com>
Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html,
which is already in newlib mainline. I think it solves the same issue
in a slight different approach.
Does it work for you?
On Thu, Aug 14, 2014 at 4:52 PM, Joern Rennecke
> 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
> 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:
> 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