Strange printf() behavior on custom devkitARM target

[dogtopus]

Not sure if this is the right place to ask this, but I don't know any better place to ask so here we go.

So I was working on a devkitARM-based homebrew toolchain for a series of pocket translators made by a certain company. So far I got the console and some syscalls working (including malloc(), in which I have to hijack the newlib _malloc_r() series functions and redirect them to the OS native implementations with an extra object file and some spec file fiddling). I also have 2 models of the machines for testing. One is based on an unknown ARM7TDMI SoC and the other is based on the famous NXP i.MX233 which uses ARM926EJ-S.

One thing I noticed though is that when I use devkitARM's printf("%f\n", ...) to print a double float it prints a completely wrong number on the ARM9 model, while the exact same binary (compiled with -mcpu=arm7tdmi for compatibility BTW) works on the ARM7 model. Further investigation with the %a format shows that the printf() thinks the lower and upper words are swapped, while the bytes of the number are exactly the same across 2 systems and are both correct. Doing basic floating point operations on the number seem to yield correct results byte-wise as well.

Also as a test, I ported the (very short) C source to almost all officially supported targets that also use ARM{v4T,v5TE} (i.e. GBA and NDS) and both of them produce the correct result.

Honestly I don't really know what could be wrong. It's pretty obvious that printf() is acting up somehow but I didn't touch that part and all actual console printing should be redirected to the console devop as strings. IIRC the floating point emulation is provided by libgcc and should be OS-independent and somewhat machine-independent (as in should work on both ARM7 and ARM9) thus shouldn't cause any problems. Did I miss some obvious newlib/libgcc quirks that could cause this behavior?

[WinterMute]

Can you show me the test code you're using and the compile flags for each processor flavour? I have a couple of ideas but I need a bit more info & being able to build some code to look at output more directly would be helpful.

I'd also be interested in knowing what the devices are specifically - feel free to email (link in profile) me directly if it's currently secret.

[dogtopus]

I actually found the issue and it was really platform-specific (i.e. devkitARM was doing everything right).

The target device isn't running my code bare-metal (it has some in-house RTOS on it) and the executable loader was not exactly AAPCS compliant. Specifically, the stack pointer was misaligned to 32-bit instead of 64-bit. This caused the parameter passed afterwards to all misalign, thus the weird corruption I was seeing. Since the bug is in the loader, I can't fix it completely. So I ended up added a bit of ARM assembly code to the crt0 that checks if the current SP is 64-bit aligned and push a dummy 32-bit word to the stack if it wasn't. On exit I also check if I fix the stack before and unfix it if needed.