Re: Building with float support

[Jeff Johnston <jjohnstn at redhat dot com>]

Rick Mann wrote:
> On Jan 5, 2009, at 11:26:36, Jeff Johnston wrote:
>
> > Rick Mann wrote:
> > > Is there anything to read about building newlib with floating-point 
> > > support (particularly in snprintf()).
> > >
> > > I did this:
> > >
> > > ./configure --target=arm-elf --prefix=/usr/local/arm-elf-float
> > >
> > > and modified the resulting Makefile to include these lines:
> > >
> > > CFLAGS_FOR_TARGET = -DFLOATING_POINT -g -O2
> > > CXXFLAGS_FOR_TARGET = -DFLOATING_POINT -g -O2
> > >
> > > Then I did "make install" and placed the results from arm-elf-float 
> > > into my existing arm-elf-gcc/newlib installation. After recompiling 
> > > my project, I'm still getting behavior that indicates there's no 
> > > floating point support (garbage printed for %f printf).
> > >
> > > Did I miss a setting or do something wrong?
> >
> > Floating point I/O support is on by default.  You can configure to 
> > turn it off but this is not being done for arm (or any other platform 
> > at this time).
> >
> > One thing to check is whether you have forgotten to include stdio.h 
> > in your test case.  The compiler will default the prototype for 
> > printf and get floating-point arguments wrong.  If that is not the 
> > case, you might want to check that the newlib floating-point 
> > conversion routines are working in this particular instance by 
> > calling dtoa (<stdio.h>) .  If you look in 
> > libc/include/machine/ieeefp.h, you will see that arm has a few 
> > variants with regards to floating-point format so make sure that the 
> > flags are being set correctly according to how the float argument is 
> > passed.
>
> If it's on by default, how does one turn it off? I ask, just to 
> understand newlib a bit better.

--disable-newlib-io-float (on configuration command)
> The other thing I don't understand is why the compiler would get 
> floating-point arguments wrong without seeing a declaration for 
> printf(). I mean, isn't it going to just look like (char* f, ...)?
You are assuming the compiler intrinsically has to know what printf is 
(i.e. that it has a vararg list and that the first argument is a 
character pointer).  What if you wrote your own printf routine and 
weren't using stdio.h?  Should it know every library routine in 
existence and add new information every time a new function is added?
Some compilers do some optimizations with printf so they do know about 
it, but you should never count on it.  You should always include the 
appropriate header file.
> In any case, all this points to me not properly replacing my existing 
> newlib properly. Any suggestions on how to find exactly where the 
> build is finding newlib? I'm pretty sure that's the one in the 
> compiler's directory, but I've built the arm toolchain many times, so 
> maybe it's getting confused.
It is usually recommended to link newlib/libgloss as sibling directories 
of gcc and build in one directory.  You want gcc to use the newlib 
header files when building libgcc and it makes linking easy when you 
compile/link via gcc with regards to multilibs.  The multlib mechanism 
builds multiple libraries for each permutation as defined by the 
compiler (gcc --print-multi-lib).  The libraries are placed in 
appropriate subdirectories and when you do a compile/link via gcc, the 
options are used to map to the appropriate subdirectory.  For example, 
if you specify -mlittle-endian, you want gcc to find a newlib built 
little-endian.

-- Jeff J.
> Thanks!