newlib-nano: Printf formatting does not work properly for some numeric types

[miri64]

Possibly other boards are effected, too. Compare the following program

#include <stdio.h>
#include <inttypes.h>

int main(void)
{
    uint64_t test = 0xabcdef0123456789;

    printf("%llx\n", test);
    printf("%lx\n", test);
    printf("%" PRIx64 "\n", test);

    return 0;
}

on iot-lab_M3

2014-10-28 13:15:00,163 - INFO # kernel_init(): This is RIOT! (Version: 2014.05-1144-gd91ec-beutlin-od)
2014-10-28 13:15:00,165 - INFO # kernel_init(): jumping into first task...
2014-10-28 13:15:00,166 - INFO # lx
2014-10-28 13:15:00,166 - INFO # a
2014-10-28 13:15:00,166 - INFO # lx

on native

kernel_init(): This is RIOT! (Version: 2014.05-1145-ga2223-beutlin-od)
kernel_init(): jumping into first task...
abcdef0123456789
23456789
abcdef0123456789

and on msba2

2014-10-28 13:15:00,163 - INFO # kernel_init(): This is RIOT! (Version: 2014.05-1144-gd91ec-beutlin-od)
2014-10-28 13:15:00,165 - INFO # kernel_init(): jumping into first task...
2014-10-28 13:15:00,166 - INFO # abcdef0123456789
2014-10-28 13:15:00,166 - INFO # 23456789
2014-10-28 13:15:00,166 - INFO # abcdef0123456789

[miri64]

For msba2 and iot-lab_M3 I used the same toolchain (ARM Embedded with gcc 4.8.4 20140725), btw.

[Kijewski]

Please try printf("%Lx\n", test); and printf("%" PRIx64 "\n", test);

[miri64]

2014-10-28 13:51:09,132 - INFO # 1
2014-10-28 13:51:09,132 - INFO # lx

respectively

[thomaseichinger]

This is a result of newlib-nano. When omitting

export LINKFLAGS += -specs=nano.specs -lc -lnosys

in boards/iot-lab_M3/Makfile.include results should be correct.
For the record, printing floating point numbers doesn't work neither.
Could you verify this for me?

[OlegHahm]

I only get the right result when setting -O0

[thomaseichinger]

With arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147] and -Os without nano.specs I get

2014-10-28 15:16:00,505 - INFO # abcdef0123456789
2014-10-28 15:16:00,505 - INFO # a
2014-10-28 15:16:00,505 - INFO # abcdef0123456789

The second printf throws a warning

main.c:31:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'uint64_t' [-Wformat=]
     printf("%lx\n", test);
     ^

[miri64]

Get the same result with the same configuration as @thomaseichinger has. The second printf was just a fall-back case, since %llx wasn't functioning. So everything is fine.
Should I close this as a memo for future references?

[OlegHahm]

Hm, there's certainly an issue with some formatters and printf in combination with a certain toolchain, platform, and optimization flags.

[thomaseichinger]

@OlegHahm could you tell us your toolchain version and platform? I'd add a section to iot-lab_M3's wiki page.

[thomaseichinger]

As this issue is related to newlib-nano close this as Memo? @OlegHahm @authmillenon

[OlegHahm]

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140526 (release) [ARM/embedded-4_8-branch revision 211358] in default configuration gives:

2014-11-24 19:12:46,271 - INFO # kernel_init(): This is RIOT! (Version: e5a3-tbilisi)
2014-11-24 19:12:46,272 - INFO # kernel_init(): jumping into first task...
2014-11-24 19:12:46,273 - INFO # lx
2014-11-24 19:12:46,273 - INFO # a
2014-11-24 19:12:46,273 - INFO # lx

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140526 (release) [ARM/embedded-4_8-branch revision 211358] w/o nano.specs gives:

2014-11-24 19:06:42,607 - INFO # kernel_init(): This is RIOT! (Version: e5a3-tbilisi)
2014-11-24 19:06:42,607 - INFO # kernel_init(): jumping into first task...
2014-11-24 19:06:42,607 - INFO # lx
2014-11-24 19:06:42,608 - INFO # a
2014-11-24 19:06:42,608 - INFO # lx

arm-none-eabi-gcc (Arch Repository) 4.9.2 (also w/o nano.specs) gives:

2014-11-24 19:03:54,716 - INFO # kernel_init(): This is RIOT! (Version: e5a3-tbilisi)
2014-11-24 19:03:54,717 - INFO # kernel_init(): jumping into first task...
2014-11-24 19:03:54,717 - INFO # 2345678900000001
2014-11-24 19:03:54,717 - INFO # a
2014-11-24 19:03:54,718 - INFO # 234567890000000a

[DipSwitch]

This problem is probably caused by the stack alignment. Cortex-M stacks MUST be 8 byte aligned I see in the implementation of thread.c you are only aligning to the processor register size.

[OlegHahm]

This should be fixed since #2976 in https://github.com/RIOT-OS/RIOT/blob/master/cpu/cortexm_common/thread_arch.c

[DipSwitch]

Yeah I just saw it in the thread_arch, I've seen this before when the stack was misaligned, my bad.

[OlegHahm]

No problem.

[PeterKietzmann]

But the described bug in this issue is still present?

[OlegHahm]

Long time I haven't checked.

[PeterKietzmann]

Possible job for @A-Paul ? Or are you already busy with work?

[DipSwitch]

Bug is still present. Checked today, to see if the stack alignment was correct and it was.

[OlegHahm]

Wondering if there is anything we can do about this. Seems more like Newlib-nano issue.

[cladmi]

This could definitely go into a documentation, its common that I write something like printf("size: %zu\n", size_t_variable); And it works for some platforms but not all as newlib-nano does not have all supports. I think its usually solved by casting to (unsigned int) but I don't think I have seen a place where this is summarized.

[kYc0o]

Can't we instead enforce the usage of fmt and portable printf descriptors?

it works for some platforms but not all as newlib-nano does not have all supports

Is this really per platform or per architecture? It's hard for me to think that such a printf() works in a samr21-xpro but not in a iotlab-m3...

[kaspar030]

I think its usually solved by casting to (unsigned int) but I don't think I have seen a place where this is summarized.

That doesn't help. The problem is that depending on compile time configuration of newlib, it might or might not support "%z".

Is this really per platform or per architecture? It's hard for me to think that such a printf() works in a samr21-xpro but not in a iotlab-m3...

It totally depends on how the C library was compiled.

[kYc0o]

So what do we do here? It seems that is also a won't fix...

[cladmi]

I added some reference in the coding conventions:

https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions#-wformat

Feel free to add more informations and rephrase.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[fjmolinas]

This should not have been closed, its still an issue, the thing happens with PRIu8 BTW

[maribu]

I see the following approaches to move forward:

1. Document that printf with newlib_nano is not fully working
2. Add a printf_int_extra module (or so), similar to printf_float, which would force a standard C lib / C lib variant with support for all integer format specifiers
3. Implement a custom printf() for newlib. (Which likely would be both smaller and better)
4. Close this issue, sneak away, and hope nobody notices.

[OlegHahm]

I'm wondering if we could even implement a compile-time warning when using newlib_nano and printf.