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

[Joern Rennecke]

On 27 August 2014 08:02, Thomas Preud'homme <address@hidden> wrote:
>> From: Joern Rennecke [mailto:address@hidden
>> Sent: Tuesday, August 26, 2014 6:44 PM
>>
>> Due to the library order defined in the specs, the float-enbled printf
>> definition will
>> be picked up from libprintf_flt.a .
>
> It seems to me that it relies heavily on how symbol resolution works.

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 so.

> If
> I understand correctly all undefined symbols (for instance __int_printf)
> in object files are processed first. Symbols definition are search in the
> order in which libraries are given in the command line (this part seems
> pretty reliable since it's at least documented in ld's manual). When
> doing so, if a symbol definition reference an undefined symbol (like
> __int_printf referencing printf), it is left aside until all undefined
> symbol from object files have been processed. At some point printf
> from object file will be processed and will pull the printf with float
> support since it's the first one encountered. Then the undefined
> reference discovered when pulling symbols from library will be
> processed and since printf with float was already pulled in that's
> the one being used.
>
> Is this behavior the same for all linker? It sounds like a reasonable
> algorithm but I don't know well the variety of linkers out there.

Well, the part of processing libraries in order is pretty much
universal, although
there are options to change that behaviour.  I'd  say you really have
to know what
you are doing when using these options.
Now, to make the __int_printf function entry line up with the printf
implementation,
I'm relying on GNU AS (gas) linker scripts.  That part is
unfortunately not so portable,
so this trick has to be restricted to targets/configurations that use gas,
or another linker (if any) that allows to alphasort the relevant sections.

>> 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.
>
> Right, my bad, no problem indeed. What "general problem" are you
> referring too that is not solved with this patch?

The general problem also includes trying to decide definitely if we
need a/any floating
point enabled implementation(s) in cases with calls of va_list taking functions,
(which. while not always, but usually also take the format as a
variable), and have
no non-va_list calls to decide the matter in favour of needing floating point.
The question if any floating-point indicating actual format string
and/or(*) va_list
arguments reach the v*printf / v*scanf calls is non-trivial and
respects functions
(in the computability theory sense),  hence, this is not computable
according to Rice's theorem.

(*) Any way you language lawyer it, you can only chip away at the set
of programs
you can compute the answer for, but can never do it for the whole set.