This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Building newlib without -mhard-float
Here's another odd thing I'm seeing. With my current build of the
tools & multilib (using --target=arm-elf and --with-cpu=xscale), if I
write single- and double-precision floating point code like this:
volatile double a = 1.5;
volatile double b = 4.0;
int c = (int) (a * b);
The compiler generates calls to __muldf3() and the like and
everything links and executes fine.
2a8: e3a035ff mov r3, #1069547520 ; 0x3fc00000
2ac: e3a01101 mov r1, #1073741824 ; 0x40000000
2b0: e283370e add r3, r3, #3670016 ; 0x380000
2b4: e3a04000 mov r4, #0 ; 0x0
2b8: e2811601 add r1, r1, #1048576 ; 0x100000
2bc: e3a02000 mov r2, #0 ; 0x0
2c0: e58d3038 str r3, [sp, #56]
2c4: e58d403c str r4, [sp, #60]
2c8: e58d1030 str r1, [sp, #48]
2cc: e58d2034 str r2, [sp, #52]
2d0: e28d0038 add r0, sp, #56 ; 0x38
2d4: e8900003 ldm r0, {r0, r1}
2d8: e28d2030 add r2, sp, #48 ; 0x30
2dc: e892000c ldm r2, {r2, r3}
2e0: ebfffffe bl 0 <__muldf3>
2e4: ebfffffe bl 0 <__fixdfsi>
But, if I call sprintf(), the linker complains about routines like
__muldf3 (and many others) not being found:
/usr/local/arm3/lib/gcc/arm-elf/4.2.1/../../../../arm-elf/lib/libc.a
(lib_a-dtoa.o): In function `_dtoa_r':
/Users/rmann/Desktop/gcc2/newlib-1.15.0/build/arm-elf/newlib/libc/
stdlib/../../../../../newlib/libc/stdlib/dtoa.c:463: undefined
reference to `__muldf3'
Even more interesting, if I leave in my own floating-point code, that
reference in _dtoa_r to __muldf3 is linked fine. If I remove my own
floating-point code, the error comes back. It seems that GCC is
unable to link the floating-point math calls in libc.a on its own,
but me making reference to them in my main() makes it okay.
--
Rick