[参考译文] CCS/AM3358：printf 无法格式化 long long (%LL...)

Maciej、

如果您在 CCSv9中从 CCSv6 (GCC 4.4.8)加载程序、它是否能正确打印？  我正在尝试了解这是 CCS 处理 printf 的问题还是 GCC 运行时的问题。

此致、

John

John、您好、感谢您的回复。

使用与6中相同的 SYS/BIOS 和 XDCtools 版本时、将程序从6加载到9可以正常工作。 即分别为6.42.3.35和3.31.0.24_core 以及相同的编译器版本(GNU 4.4.8)。

较新版本的 SYS/BIOS、XDCtools 和 GCC 无法完全编译工程、错误声称 AM3385不支持计时器。

将` 7.2.1与旧版本的 S/B 和 XDCtools 一起使用会导致对 Δ__locale_ctype_ptr 的一些未定义引用

将 GCC 7.2.1和 XDC 3.51.3.28_core 与旧 S/B 一起使用会产生兼容性错误。

将 GCC 7.2.1和 S/B 6.76.1.12与旧 XDC 一起使用会导致：

XDC 运行时错误：TI.SysBIOS.BIOS:不兼容的对 kernelHeapSection 的分配：".kernel_heap" 

[引用 user="Maciej Romanski">当使用与6相同的 SYS/BIOS 和 XDCtools 版本时，将程序从6加载到9可以正常工作。 即分别为6.42.3.35和3.31.0.24_core 以及相同的编译器版本(GNU 4.4.8)。[/引用]

如果 printf 在这种情况下正常工作、则问题似乎是较新的 GCC 所特有的。  实际上、我想您只需加载已使用 CCSv6构建的程序、但使用具有 CCSv6中使用的相同组件的 v9也可以实现相同的目标。

因此 CCS 中没有任何损坏。  更新的 GCC 或 CCS 使用更新的 GCC 处理 printf 的方式可能会出现问题。

我必须在最后尝试几件事

John

默认情况下、CCSv9会与 newlib-nano 而不是 newlib 进行链接吗？

好的、这是我观察到的情况。  我在 Windows 上使用的是带 BeagleBone White 的 CCSv9.1.0。  我使用项目向导创建了一个新项目、并选择了 hello world 模板、只需更改 printf 语句即可匹配您的项目  printf("this is a number %llu <---", -1);

当我构建时、我从 GCC 收到警告(4.8.4和7.2.1)  

格式'%llu'需要类型为'long long unsigned int'的参数、但参数2的类型为'int'[-Wformat=]

在使用4.8.4进行构建、然后运行时、我会得到

[CortxA8]这是一个数字923372711164641280 <--

在使用7.2.1进行构建、然后运行时、我会得到

[CortxA8]这是一个数字923372711164641282 <--

如果我将 printf 更改为采用一个实际 long long 变量

长整型 var = 12345678901234567890；

printf ("这是一个数字%llu <---\n"、var)；

我获得两个编译器的预期输出：

[CortxA8]这是一个号码12345678901234567890 <--

此致、

John

是的、-1将发出警告、因为它被解释为无符号值。 我刚才使用-1作为获得2^64 - 1的更方便的方法。

不过、获得9223372711164641280会有点奇怪、因为这意味着-1被解释为 long long int (%LLD)、而不是 long long unsigned (%llu)。

但为了正确起见、我也尝试了以下方法：

char a[]="这是一个数字%llu <--"；
long long num = 0xFFFFFFFF；
sprintf (b、a、num)； 

但是、b 仍然输出

这是一个数字 Lu <-- 

好的、因此它肯定是一个 newlib-nano 问题。 不是与库本身相关、而是与 CCS 链接、而是与普通的纳自由主义相连接。

我在以下位置替换了 libc_nano。a 和 libg_nano。a 来确认这一点：

C：\ti\BIOS_6_76_01_12\packages/GNU\Targets\arm\libs\install-native\arm-none-eabi\lib\hard

分别使用 libc.a 和 libg.a。 我还必须在的第187行添加以下内容

C：\ti\BIOS_6_76_01_12\packages/ti\SysBIOS\rts\GNU\ReentSupport.c

const struct __sFile_fake_sf_sf_fake_stdin =
｛_NULL、0、0、0、0、0、 ｛_NULL、0｝、0、_NULL｝；
const struct __sFile_fake_sfake_sf_stdout =
｛_NULL、0、0、0、0、0、 ｛_NULL、0｝、0、_NULL｝；
const struct __sFile_fake_sfake_sf_stderr =
｛_NULL、0、0、0、0、0、 ｛_NULL、0｝、0、_NULL｝； 

(从 https://github.com/eblot/newlib/blob/master/newlib/libc/stdio/findfp.c#L29复制)

这导致%llu 格式正确，但是，它的作用是使程序在调用 vsnprintf 时崩溃。

我们可能必须与产品线或 RTOS 团队的人员联系。  对于我来说、我运行的是裸机应用程序。  在这种情况下、直接在工程设置中控制库。

这些捕获来自不同的机器、只是显示了设置的位置。  如果 nosys 被指定为库、我认为这会导致问题。  同样、--specs=nan.specs 也是杂项项下的问题。

此致、

John

似乎 nosys 和 nan.specs 在某种程度上都是构建程序所必需的。

no nosys 会生成大量未定义的引用、例如_open、_kill、_getpid。

没有 nano 规范会导致程序在我上一篇帖子中的相同情况下崩溃、因此可能需要一些额外的选项或其他一些东西来使其使用完整的 newlib。

请看一下这篇文章： http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#Enabling_Semi-Hosting_for_Cortex-A_GNU_targets

Todd

谢谢、Todd、但遗憾的是、按照这些说明操作没有任何影响。

您好、Maciej、

您能否导出显示此内容的简单 CCS 项目？ 在这里、尝试重现您的问题比反复反弹更容易。

Todd

当然。 下面是一个演示该问题的最低工作示例。

实际的项目归档文件是 mwe.zip 内的 minimal-ll.zip

utils 目录包含使用的平台说明、应放置在工作区目录中。

不过、您可能无法构建或调试针对"ADK"平台的代码。 目前我没有其他人可以尝试、但希望该问题也可以在其他平台上重现(在这种情况下、您不需要 utils 目录)。

e2e.ti.com/.../mwe.zip

Mariej、

我刚刚运行了您的示例(我使用了 app.cfg 和 main.c 并将其放入 GCC 项目中)。 在 ROV 中、我看到 Tools->ROV 中的 System_printf 字符串符合预期

注：.cfg 中的以下内容意味着 System_printf 输出被放置在可由 ROV 读取的内部缓冲区中。

您的问题到底是什么？

Todd

我遇到的问题是格式化 long long 整数。

如果在 main.c 中的第33行之后的某个位置粘贴断点、并在内存浏览器中查找`a`的值、则应该看到字符串值不是"18446..."、而是"lu"。

或者、更换

sprintf (a、"%llu"、0xFFFFFFFFFFFFFFFFFFFFFFULL)； 

使用

System_printf ("%llu\n"、0xFFFFFFFFFFFFFFFFFFFFFFULL)； 

您应该看到以下内容

我注意到 System__internal.h 中有以下行

typedef XDC_UINT32 XDC_RAUNITY_System_Unum； 

但根据文档字符串、这显然只影响 SYSTen_printf。 因此、对于标准 printf、可能有类似的东西。

Maciej、

谢谢。 System_printf 不支持 long long。 以下是对支持的格式的说明： http://rtsc.eclipse.org/cdoc-tip/xdc/runtime/System.html#printf。

Todd

谢谢、但我想您可能错过了这一点。 我不想使用 System_printf -我只是在上一篇文章中将其用作示例。 我正在尝试使用标准 C 库中的 printf/sprintf。 我可以使用 CCS6指定"%llu"、但在 CCS9中、它只是被"lu"取代。

好的。 我要将其移至编译器团队。 您在 CCS6和 CCS9中使用哪些编译器版本？

[编辑]自 CCS6中的第一个发布 GNU 4.8.4和 CCS9中的 GNU 7.2.1

回到您的第一篇帖子、我注意到源代码中存在错误。

[引用 user="Maciej Romanski"] printf ("这是一个数字%llu <--"，-1)；

常量-1的类型为 int。  但 printf 预计类型为 long long。  所以，把它更改为...

printf ("这是一个数字%llu <--"、-1LL)；

我没有一个系统可以尝试此操作、因此我无法确定这可以解决此问题。  但我认为值得一试。

谢谢、此致、

乔治

谢谢你，乔治，但是如果你向上滚动一点，你会看到我已经尝试了一些这样的东西(0xFFFFFFFFFFFFFFFFULL)

此致、

Maciej

不用担心、Todd。

那么、我认为在我使用的两个版本之间、TI 决定从 newlib 切换到 newlib-nano、这是正确的吗？ 还是在 newlib-nano 中进行的更改？ 我是否可以构建可与 SYS/BIOS 配合使用的 newlib-nano 自定义版本？

我能够解决这个问题、但这并不是真正的理想(具有专门将 lu 转换为字符串的函数)。 我不确定我是否愿意说问题已经解决、但我不知道这些论坛上"已解决"的确切定义是什么。 基本上、它不是一个障碍、但问题仍然存在。

Maciej、

我们迁移到了 newlib-nano 以节省尺寸。 我们还对其进行了一些自定义、并交付该重建库。 遗憾的是、我们在 SYS/BIOS 产品中不包含这些源更改。

Todd

P.S. 我理解您的"已解决"评论。 我想再看几个选项。 基本而言、这意味着它要么是真正解决问题(每个人都很高兴)、要么 TI 认为没有其他需要讨论的内容(例如"抱歉、该功能目前未计划"或海报未回复、因此我们将其标记为已解决)。  

Todd

我看到了、但除非我错了、否则 newlib-nano 根据 GPL-2.0获得许可、在这种情况下、TI 所做的源代码和更改应该在某个地方提供、对吧？ 尽管在这种情况下、每个链接到 newlib-nano 的程序也必须是基于 GPL 的、而 newlib 和 newlib-nano 在许可方面都有点混乱、因此我不确定。

啊、谢谢！ 让它使用标准 IO 格式构建一个微型库。

很棒！ 也感谢您的介绍。