This is the mail archive of the
mailing list for the GCC project.
Re: selective linking of floating point support for *printf / *scanf
- From: Joern Rennecke <joern dot rennecke at embecosm dot com>
- To: "Thomas Preud'homme" <thomas dot preudhomme at arm 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>, newlib at sourceware dot org
- Date: Wed, 27 Aug 2014 12:54:01 +0100
- Subject: Re: 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> <001401cfc0f9$bdc5cbc0$39516340$ at arm dot com> <CAMqJFCrEOgavwvW25vO=S-+0TZ_xOnDa0Ex-Ff4XG329K5WE9g at mail dot gmail dot com> <001901cfc1c4$d0678630$71369290$ at arm dot com> <CAMqJFCoFC8sVRQB3+v4dzSVc5LLs9cycjm621FmM34gGHRWFng at mail dot gmail dot com> <000001cfc1e3$7f1a22f0$7d4e68d0$ at arm dot com>
On 27 August 2014 11:41, Thomas Preud'homme <firstname.lastname@example.org> wrote:
>> From: Joern Rennecke [mailto:email@example.com]
>> 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
> 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
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 /
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
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.