I have a data-conversion function in our ARM9 code which uses varargs. I've been using an arm-elf yagarto distribution from a couple of years ago, with no problems. Recently, we upgraded to the arm-eabi-none yagarto package from the yagarto site, and I'm finding that we now have problems with floating point values. What I eventually discovered is that doubles are being forced to 8-byte boundaries, and the existing varargs floating-point handler didn't expect to find gaps in the args.
I can manually check the pointer and force it up to an eight-byte boundary (in fact, I did that, and that fixed the issue entirely), but I'd like to know why this has suddenly started happening.
Is there a compiler switch that specifies data alignment on the stack, or in function calls, or something like that?? And why would it be defaulting to 8-byte boundaries on a 32-bit (4-byte) architecture??
I would appreciate any advice or insights that anyone could provide on these issues.
The code is simple:
.....
float floatValue = 10.0;
int intValue = 10;
char buffer[32];
...
snprintf (buffer, 32, "%g", floatValue); /* Here we are getting junk value bcz of 8-byte*/
snprintf (buffer, 32, "%lld", intValue); /* Here we are getting junk value bcz of 8-byte */
....
The version of GCC we were using is 4.7.1
Compiling options:
Toolchain compiling options:
`mabi=aapcs-linux
`mcpu=arm7tdmi/mcpu=arm946e-s`
`mfloat-abi=softfp`
Application compiler option:
`-mfloat-abi=softfp`
`-mfpu=vfp`
`-mstructure-size-boundary=8`
`-fomit-frame-pointer`
`-fshort-wchar`
`-fno-short-enums`