sprintf misbehaving with floats

[Richard Earnshaw]

On 02/07/15 18:58, Kline, Matthew wrote:
> Hello all,
> 
> I'm using newlib for some firmware I'm developing on an ARM Cortex-M4
> (a STM32F427ZIT6, FWIW), and I'm running into a bit of trouble.
> 
> printf and family (sprintf, etc.) seem to misbehave when given floating point
> values. The following produces the intended result:
> 
> static char foo[1024];
> sprintf(foo, "%d is an int", 42);
> 
> But the following
> 
> sprintf(foo, "%f is a float", 8675.309f);
> 
> produces garbage similar to
> 
> 00000000: 0000 0320 2e49 3802 08d1 0320 6973 2061  ... .I8.... is a
> 00000010: 2066 6c6f 6174 0000 0000 0000 0000 0000   float..........
> 
> Oddly enough, it seems to return the correct value and write a string of the
> right length, but the characters where the float should go are badly messed up.
> 
> I'm aware that newlib can be built without support for printing and scanning
> floats using --disable-newlib-io-float, but my distro package that provides
> newlib isn't being built with that flag. The package build script can be found
> at https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/arm-none-eabi-newlib
> and is being built with the following flags:
> 
> --disable-newlib-supplied-syscalls \
> --disable-nls \
> --enable-newlib-io-long-long \
> --enable-newlib-register-fini
> 
> I'm currently working on building it myself with debug symbols so I can pick
> things apart more, but in the meantime, does anybody have an idea of what could
> be going on?
> 
> Thanks,
> Matt Kline
> 


This is pretty much a FAQ.  Almost invariably this is because you've
failed to maintain 8-byte stack alignment at function call boundaries as
required by the AAPCS rules.

R.