> From: Joern Rennecke [mailto:joern.renne...@embecosm.com] > Sent: Wednesday, August 27, 2014 7:54 PM > > 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.
That's indeed the approach I took in my own patch. > > 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. Are you aware of other C libraries that would benefit from such a default (newlib wouldn't)? Right now I'm having trouble to define stdio_altname in newlib-c.c since this would require it to be a C target hook but such a hook cannot be called from middle end. Did I mis(understood|s) something? > > 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. I'll consider about renaming the symbol but we've been using this one for some time in our toolchain so it might not be possible to change. > 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. I'm confused here. Why would we have a __int_printf? Right now we only have iprintf as an alias to printf, _printf_float being a weakly defined function called from printf for the float support. Best regards, Thomas
