This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: selective linking of floating point support for *printf / *scanf


> From: Joern Rennecke [mailto:joern.rennecke@embecosm.com]
> 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
about it.

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

Right.

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

Best regards,

Thomas



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]