gcc - newlib - floating numbers printf/scanf (configure for targets, cleanup required)

[0xc0170]

There's the if condition for some tagets on the line https://github.com/mbedmicro/mbed/blob/master/tools/toolchains/gcc.py#L287 .

Here's the code snippet:

if target.name in ["LPC1768", "LPC4088", "LPC4088_DM", "LPC4330", "UBLOX_C027", "LPC2368", "ARM_BEETLE_SOC"]:
    self.ld.extend(["-u _printf_float", "-u _scanf_float"])
elif target.name in ["RZ_A1H", "VK_RZ_A1H", "ARCH_MAX", "DISCO_F407VG", "DISCO_F429ZI", "DISCO_F469NI", "NUCLEO_F401RE", "NUCLEO_F410RB", "NUCLEO_F411RE", "NUCLEO_F446RE", "ELMO_F411RE", "MTS_MDOT_F411RE", "MTS_DRAGONFLY_F411RE", "DISCO_F746NG"]:
    self.ld.extend(["-u_printf_float", "-u_scanf_float"])

We should investigate why there's -u_printf_float vs -u _printf_float (different GCC ARM versions?), plus looks at this if/else - either provide a configuration option, or follow the other toolchains. IAR and ARMCC full stdlib provide floating support. uLib does not as I recall (something to check).

[ohagendorf]

For me only the variant without space works. With a space the option seems to be ignored.
The original config was with a space.

The first target in the elif was added with PR #933

[sg-]

@ohagendorf What version of gcc are you using and what OS?

[c1728p9]

Talking with @theotherjimmy and @geky, this could be made portable by breaking the '-u' and
'_printf_float' into seperate args. That probably doesn't matter anymore though since this command is no longer sent on the command line and is instead written to a response file (.link_files.txt).

I pushed up a PR to remove floating point formatting support all together in #2168. Keeping floating point off saves ~15KB. Let me know your thoughts on the PR.

[geky]

@ohagendorf: Thanks for finding the introduction of the issue.

The issue boils down to the fact that gcc correctly expects spaces to be parsed out its argument list. Since we are passing this array directly to popen with shell=False, it is up to us to remove spaces or expect undefined behaviour. Windows doesn't provide a api like python's popen, so the list is just passed into CreateProcess as a big string and is reparsed, hiding the problem.

Either ["-u", "_prinf_float"] or ["-u_printf_float"] should work. @c1728p9 is right that the response files should have unintentionally fixed this, @ohagendorf are you using an exported project?

[ohagendorf]

I'm using exported projects.

I'm not sure, I had this space/no space problem a long time ago, maybe 1 or 2 years. So it's hard to say which versions I used. I'm sure it was Win8.1 but no idea which gcc version.

But I checked it now (Win10 and arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589]) and the problem disappeard. With or without spaces - no differences in code size and printf with float is working.

[ciarmcom]

ARM Internal Ref: IOTMORF-151

[jensstruemper]

I'm using mbed-cli with imported mbed 2 projects, NRF51_DK target and the most recent GCC_ARM 5.3 compiler. Printf with float formatting is not working. I tried manually adding "-WL,-u,_printf_float" flag to gcc.py and alternatively adding the NRF51 target to the if statement mentioned in the issue above. But none of these changes made printf working with float support. Is there any hack availalble to get it in? Especially as it seems you don't want to make it on / off configurable due to code size concerns.

[jensstruemper]

I finally appended ["-Wl,-u,_printf_float"] to the link method of class GCC and it is working as expected. Would be nice to have this on / off configurable as a command line parameter (I think there's an issue open on this already). Code size increase is huge - 27kB! The resulting hex is still smaller than the hex from the online IDE.

[sg-]

Looks to be refactored and unified.