This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib 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: Tue, 26 Aug 2014 11:43:39 +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>
On 26 August 2014 07:48, Thomas Preud'homme <thomas.preudhomme@arm.com> wrote:
> What happens in the case that a program contains both some printf and
> __int_printf call?
Due to the library order defined in the specs, the float-enbled printf
definition will
be picked up from libprintf_flt.a .
> 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".
That testcase is not valid. You'd to use one of the v*printf functions.
Solving the general problem for these is not computable; for specific cases, it
would be possible, but at the cost of varying degrees of complexity.
So I let this for manual selection: it's not handled with the
calls.stdio_altname
hook, and you have to use a special link line to use the integer-only
implementations.
Well, if desired, a spec change could give an option to do that.
Another extension possibility in this area is to have the library also
provide forwarder
stubs for __int_v*printf in libc, so you could use the latter function
whenever you deem
fit, and the linker will sort out which implementation you get.
> 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.
That can be implemented with suitable *newlib*.[ch] files that are
selected in config.gcc,
akin to newlib-stdint.h and glibc-c.c .
> 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.
Well, all the *printf functions are variadic, and as stated above,
your example is invalid.
The wildcard are va_list taking functions. You first have to decide
what you want to
happen with these by default, and what kind of non-default behaviour
you'd like to be
able to select, and how; than we can talk about if this neeeds any
extra infrastructure
to implement.