CCS/AM3358: printf unable to format long long (%ll...)

Maciej,

If you load the program from CCSv6 (GCC 4.8.4) in CCSv9 does it print correctly?  I am trying to understand if this is an issue with CCS handling of the printf or if it is an issue in the GCC runtime.

Regards,

John

Hello John, thanks for the reply.

Loading the program from 6 into 9 does work properly when using the same SYS/BIOS and XDCtools versions as in 6. i.e. 6.42.3.35 and 3.31.0.24_core respectively, and the same compiler version (GNU 4.8.4).

Newer versions of SYS/BIOS, XDCtools, and GCC fail to build the project entirely, with errors claiming that the AM3385 doesn't support timers.

Using GCC 7.2.1 with the old versions of S/B and XDCtools causes some undefined references to `__locale_ctype_ptr'

Using GCC 7.2.1 and XDC 3.51.3.28_core with the old S/B produces a compatibility error.

Using GCC 7.2.1 and S/B 6.76.1.12 with the old XDC causes:

XDC runtime error: ti.sysbios.BIOS: incompatible assignment to kernelHeapSection : ".kernel_heap"

Maciej Romanski said:

Loading the program from 6 into 9 does work properly when using the same SYS/BIOS and XDCtools versions as in 6. i.e. 6.42.3.35 and 3.31.0.24_core respectively, and the same compiler version (GNU 4.8.4).

If printf works in this case then the issue seems to be specific to the newer GCC.  I was actually thinking you could just load the program that was already built with CCSv6 but using v9 with the same components used in CCSv6 also accomplishes the same objective.

So nothing broke in CCS.  There could be an issue with the newer GCC or the way CCS handles printf with the newer GCC.

I am going to have to try a few things out on my end.

John

Could it be CCSv9 linking against newlib-nano by default, instead of newlib?

Ok this is what I observe.  I am using CCSv9.1.0 on Windows with a BeagleBone White.  I created a new project with the project wizard and chose the hello world template and just change the printf statement to match yours printf("this is a number %llu <---", -1);

When I build I get a warning from GCC (both 4.8.4 and 7.2.1) 

format '%llu' expects argument of type 'long long unsigned int', but argument 2 has type 'int' [-Wformat=]

When building with 4.8.4 and then running I get

[CortxA8] This is a number 9223372711164641280 <---

When building with 7.2.1 and then running I get

[CortxA8] This is a number 9223372711164641282 <---

If I change the printf to take a variable that is an actual long long

long long var = 12345678901234567890;

printf("This is a number %llu <---\n", var);

I get the expected output for both compilers:

[CortxA8] This is a number 12345678901234567890 <---

Regards,

John

Yes, the -1 will throw up a warning, since it's being interpreted as an unsigned value. I just used -1 as a more convenient way to get 2^64 - 1.

It's somewhat strange that you get 9223372711164641280 though, since that would imply that the -1 is being interpreted as a long long int (%lld), and not a long long unsigned (%llu).

But for the sake of correctness, I tried this as well:

char a[] = "this is a number %llu <---";
long long num = 0xFFFFFFFFFFFFFFFF;
sprintf(b, a, num);

However, b still outputs

this is a number lu <---

Alright, so it definitely seems to be a newlib-nano issue. Not with the library itself, but with CCS linking to it instead of plain nanolib.

I confirmed this by replacing libc_nano.a and libg_nano.a in:

C:\ti\bios_6_76_01_12\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\lib\hard

with libc.a and libg.a respectively. I also had to add the following at line 187 of

C:\ti\bios_6_76_01_12\packages\ti\sysbios\rts\gnu\ReentSupport.c

const struct __sFILE_fake __sf_fake_stdin =
    {_NULL, 0, 0, 0, 0, {_NULL, 0}, 0, _NULL};
const struct __sFILE_fake __sf_fake_stdout =
    {_NULL, 0, 0, 0, 0, {_NULL, 0}, 0, _NULL};
const struct __sFILE_fake __sf_fake_stderr =
    {_NULL, 0, 0, 0, 0, {_NULL, 0}, 0, _NULL};

(copied from https://github.com/eblot/newlib/blob/master/newlib/libc/stdio/findfp.c#L29)

This resulted in %llu formatting properly, however, it alsoseems to have the effect of crashing the program on calls to vsnprintf.

We may have to loop in someone from the product line or RTOS team.  For me I was running a bare metal application.  In that case the libraries were controlled directly in the project settings.

These captures are from a different machine, just showing where the settings are.  If nosys is specified as a library I think that will cause problems.  Similarly --specs=nano.specs would be an issue under miscellaneous.

Regards,

John

It seems like both nosys and nano.specs are to some degree needed for the program to build.

No nosys produces a lot of undefined references to things like _open, _kill, _getpid.

No nano.specs causes the program to crash in the same case as in my last post, so perhaps some extra option or something is needed to get it work with full newlib.

Take a look at this write-up: http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#Enabling_Semi-Hosting_for_Cortex-A_GNU_targets

Todd

Thank you, Todd, but following those instructions made no difference, unfortunately.

Hi Maciej,

Can you export a simple CCS project that shows this? Instead of bouncing back and forth, it would be easier to try and reproduce your issue here.

Todd

Sure. Here's a minimum working example that demonstrates the issue.

The actual project archive is minimal-ll.zip within mwe.zip

The utils directory contains the platform description used, and should be placed in the workspace directory.

It might not be possible for you to build or debug code aimed at the "ADK" platform though. I don't have any others to try with at the moment, but hopefully the issue will be reproducible on another platform as well if necessary (in which case, you won't need the utils directory).

mwe.zip

Mariej,

I just ran your example (I took the app.cfg and main.c and placed it into GCC project). In ROV, I see the System_printf strings in Tools->ROV as expected

Note: the following in the .cfg means that System_printf output is placed into an internal buffer that can be read by ROV.

What exactly is your problem?

Todd

The problem I am having is with formatting long long integers.

If you stick a breakpoint somewhere after line 33 in main.c, and look up the value of `a` in the memory browser, you should see that instead of "18446...", the string value is just "lu".

Alternatively, replace

sprintf(a, "%llu", 0xFFFFFFFFFFFFFFFFULL);

with

System_printf("%llu\n", 0xFFFFFFFFFFFFFFFFULL);

and you should see the following

I notice that there is the following line in System__internal.h

typedef xdc_UInt32      xdc_runtime_System_UNum;

But that apparently only affects Systen_printf, according to the docstring. So perhaps there is something similar for standard printf.

Maciej,

Thanks. System_printf does not support long long. Here is a description of what formats are supported: http://rtsc.eclipse.org/cdoc-tip/xdc/runtime/System.html#printf.

Todd

Thank you, but I think you might have missed the point. I'm not trying to use System_printf - I just used it as an example in my previous post. I'm trying to use printf/sprintf from the standard C library. I was able to specify "%llu" just fine with CCS6, but in CCS9, it just gets replaced with "lu".

Ok. I'll move this to the compiler team. Which compiler versions are you using in CCS6 and CCS9?

[edit] from first post GNU 4.8.4 in CCS6 and GNU 7.2.1 in CCS9

Going back to your first post, I notice an error in the source code.

Maciej Romanski said:

printf("this is a number %llu <---", -1);

That constant -1 has the type int.  But printf expects type long long.  So, change it to ...

   printf("this is a number %llu <---", -1LL);

I don't have a system to try this on, so I cannot be certain this fixes the problem.  But I think it is worth a try.

Thanks and regards,

-George

Thank you, George, but if you scroll up a bit, you'll see that I already tried something to that effect (0xFFFFFFFFFFFFFFFFULL)

Kind regards,

Maciej

No worries, Todd.

So am I right in thinking that between the two versions I'm using, TI decided to switch from newlib to newlib-nano? Or is it a change that was made in newlib-nano itself? Would it be possible for me to build a custom version of newlib-nano that would work with SYS/BIOS?

I am able to work around the issue, but it's not really ideal (having a function specialised to converting a llu to a string). I'm not sure I'd be happy to say that the issue is resolved, but I don't really know what the exact definition of "resolved" is on these forums. Basically, it's not a showstopper, but the issue is still there.

Maciej,

We moved to newlib-nano for the size savings. We made some customizations to it also and ship that rebuild library. Unfortunately we don't include those source changes in the SYS/BIOS product.

Todd

P.S. I understand your "resolved" comment. I'd like to see a couple more options. Basically it means that it's either truly resolved (and everyone is happy) or that TI does not think there is anything else to discuss (e.g. "sorry that feature in not currently planned" or the poster does not reply so we mark it as resolved). 

Todd

I see, but unless I am mistaken, newlib-nano is licensed under GPL-2.0, in which case the source and changes made by TI should be available somewhere, right? Though in that case, every program linked to newlib-nano would have to be GPL-based as well, and both newlib and newlib-nano are a bit of a mess with licensing, so I'm not sure.

Ah, thank you! Got it to build a nano library with the standard IO formatting.

Great! Thanks for letting us know also.