avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] selective linking of floating point support for *prin


From: Joern Rennecke
Subject: Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf
Date: Tue, 26 Aug 2014 11:43:39 +0100

On 26 August 2014 07:48, Thomas Preud'homme <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]