[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] selective linking of floating point support for *prin

From: Joern Rennecke
Subject: Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf
Date: Thu, 28 Aug 2014 14:18:23 +0100

On 28 August 2014 06:30, Thomas Preud'homme <address@hidden>

>  >
> > 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

No.  I haven't been looking for it, either.

> (newlib
> wouldn't)?

Well, to avoid namespace pollution, you need a different name used by the
than iprintf - see below.

> 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.

> > 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.

So are you saying you are stuck with printf_float?

But at least for iprintf and friends, the only requirement is that newlib
a definition.  There is no need for gcc to use these symbols to implement
*printf functions.

> > 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.

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
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
pull in the iprintf definition as well.  Even if it's a weak alias, what if
the user
defined a weak iprintf?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]