Strange printf() behavior on custom devkitARM target

support for the ARM toolchain
Post Reply
Posts: 1
Joined: Sun Nov 07, 2021 4:10 am

Strange printf() behavior on custom devkitARM target

Post by dogtopus » Sun Nov 07, 2021 5:34 am

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?

Site Admin
Posts: 1537
Joined: Tue Aug 09, 2005 3:21 am
Location: UK

Re: Strange printf() behavior on custom devkitARM target

Post by WinterMute » Thu Jan 06, 2022 3:34 am

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.
Help keep devkitPro toolchains free, Donate today

Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests