This is the mail archive of the
mailing list for the newlib project.
RE: selective linking of floating point support for *printf / *scanf
- From: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- To: "'Joern Rennecke'" <joern dot rennecke at embecosm dot com>
- Cc: "GCC" <gcc at gcc dot gnu dot org>, "Joerg Wunsch" <joerg_wunsch at uriah dot heep dot sax dot de>, <avr-libc-dev at nongnu dot org>, "Andrew Burgess" <andrew dot burgess at embecosm dot com>, <newlib at sourceware dot org>
- Date: Fri, 29 Aug 2014 14:04:25 +0800
- Subject: RE: selective linking of floating point support for *printf / *scanf
- Authentication-results: sourceware.org; auth=none
- References: <CAMqJFCpWKXVmmc-YLKf9XO6H8C_YnTEcgzkJAidE21MirJbi-w at mail dot gmail dot com> <001401cfc0f9$bdc5cbc0$39516340$ at arm dot com> <CAMqJFCrEOgavwvW25vO=S-+0TZ_xOnDa0Ex-Ff4XG329K5WE9g at mail dot gmail dot com> <001901cfc1c4$d0678630$71369290$ at arm dot com> <CAMqJFCoFC8sVRQB3+v4dzSVc5LLs9cycjm621FmM34gGHRWFng at mail dot gmail dot com> <000001cfc1e3$7f1a22f0$7d4e68d0$ at arm dot com> <CAMqJFCo1EA8TLVsv=r7gW-udiH6pqBKVuQUvHeGcFDqrnMo_EQ at mail dot gmail dot com> <000101cfc281$3a3008f0$ae901ad0$ at arm dot com> <CAMqJFCrrj1_VHmz7G-VgDpLNGjsTtdjPLqbCRY1oVxeO-BESHw at mail dot gmail dot com>
> From: Joern Rennecke [mailto:firstname.lastname@example.org]
> Sent: Thursday, August 28, 2014 9:48 PM
> > 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.
> Hmm, yes, this is not exactly C specific. Although printf / scanf are
> part of the C
> library, other languages may use the C runtime library.
> Likewise, builtin functions are not considered exclusive to C.
> So it should be a general target hook, in a target-, but not
> language-specific file.
Ok, it still feels to me this should not be target specific but since there is
no other way I'll keep it this way and create a utility function that do the
detection about whether float support is needed so as to factorize this
part between all targets.
> So are you saying you are stuck with printf_float?
It's not printf_float but _printf_float. I was told double underscore is only
necessary with old toolchain as they might add a leading underscore. So
_printf_float should not pose any kind of problem. It's been reviewed by
many people, including newlib maintainers and we had this symbol for
quite some time in our own toolchain without anybody raising any concern
> But at least for iprintf and friends, the only requirement is that
> newlib provides
> a definition. There is no need for gcc to use these symbols to implement
> ISO C
> *printf functions.
> The user writing including stdio.h, using iprintf, and not defining is
> one thing; in this
> case, the expectation is that the definition comes from newlib.
> However, when the user uses printf, (s)he is still entitles to define a
> iprintf and is entitled to expect that these don't interfere with each other;
> hence, gcc should not emit calls to iprintf when it sees a call to printf;
> using a name in the implementation namespace solves this issue.
> However, defining this in the same file as iprintf is not safe, as then you'd
> pull in the iprintf definition as well. Even if it's a weak alias,
> what if the user
> defined a weak iprintf?
Ah yes, good point. Well I can do without function renaming then, we just
need to define _printf_float. That's enough to pull in float support.
About the extra call instruction this creates, we believe it's not a problem
in practice as printf is not such a sensitive function that one instruction
makes a difference for performance or size.
Then maybe we need to think at a better name for the hook as for newlib
we will not change the function name but just define a global symbol.