> 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. 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. > 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? > > That can be implemented with suitable *newlib*.[ch] files that are > selected in config.gcc, > akin to newlib-stdint.h and glibc-c.c . Absolutely, that was the approach I followed in my own patch. > > 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. Yes my apologize, it was a mistake from me. I'll now do a more thorough testing and report back to you how it works for us. Best regards, Thomas
