On 27 August 2014 11:41, Thomas Preud'homme <thomas.preudho...@arm.com> wrote: >> From: Joern Rennecke [mailto:joern.renne...@embecosm.com] >> Sent: Wednesday, August 27, 2014 6:13 PM >> >> 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. > > Consider the new scheme in newlib when printf calls another function for > handling floating point formats. This other function is weakly defined so > that it's not pulled by default and printf is effectively integer only. You > just > need to link with an extra -u option to pull in the float support.
Well, my goal was to have the selection be automatic for most use cases. That you can do a manual selection by providing -u / -l arguments to the linker is pretty much a given. Hmm, instead of needing -u you could make gcc spit out definitions of a dummy local symbol to the trigger symbol in question (forcing a non-weak reference), using SET_ASM_OP (assuming it's defined). But you'd still be left with the extra call overhead, increasing code size no matter if float is needed or not. >> I'm relying on GNU AS (gas) linker scripts. That part is >> unfortunately not so portable, Oops, of course that should read GNU LD. > Ok. Of course detecting more cases where an integer version of IO functions > would be enough would be nice but I'm already satisfied with the current > scheme. I'm wondering what's happening for v*printf: are they only defined > in the libc_float? It's defined in both. The way i wrote the avr gcc specs / avr-libc makefile rules, this will result in the floating point enabled implementation to be used by default. Which makes the gcc test results so much nicer... > Would you accept a patch that would turn this solution into something also > suitable for newlib? For instance we would need to also include v*printf > and v*scanf functions into builtin as well. Yes. I'll have to adjust the avr hook that it'll leave the v*printf / v*scanf functions alone - at least by default / for ISO C behaviour - but it'll give me an easy way to add a switch to tweak the behaviour. Or maybe we can use a -f option to select the v*printf / v*scanf default and put the a stdio_altname__int_ target hook in targhooks.c, to be shared by all configs that want an __int_ prefix. > A new switch would also be > needed so that compiling newlib doesn't define the _printf_float and > _scanf_float symbols because of calls to v*printf and v*scanf functions. > I need to check if these calls are made in the same file in which case > I could maybe just guard the function call rewriting by a test checking if the > caller is itself a builtin. FWIW, to safely shift the symbol into the implementation namespace you need a prefix that starts with two underbars or one underbar and a capital letter. Or use some funny non-standard character in the symbol - but that's asking for more portability issues. For references made automatically by gcc, it's a good idea not to impinge on the application namespace. An application might use printf from <stdio.h>, but define its own functions iprintf, printf_float and _printf_float. Therefore, it's a good idea to put the definition of newlib's iprintf in a separate file from __int_printf. Having essentialy the same contents, but defining a different symbol, and let the linker match them up to the definition. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
