On 27 August 2014 08:02, Thomas Preud'homme <thomas.preudho...@arm.com> wrote: >> From: Joern Rennecke [mailto:joern.renne...@embecosm.com] >> 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. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
