[参考译文] RM48L952：ThreadX 库(使用 ARM FuSa 编译器工具6.16.2构建)与使用 TI ARM 工具 ti-cfg-arm_20.2.7.LTS 构建的 TI 代码之间的链接时兼容性

尊敬的 Kip：

我会将您的问题转发给 TI 编译器团队。

e2e.ti.com/.../readelf_5F00_a_5F00_threadx_5F00_xder.a.txt 使用使用使用使用"readelf -A "创建的 ARM FuSa 工具将 ThreadX 的 ELF 属性编译为库

为了帮助所有人了解此问题的优先级、我的管理人员授权我披露以下信息：在 FY25中、在成功完成24财政年度的代码测试之前、我的公司计划从德州仪器(TI)购买多达30,000个 Hercules 级处理器。  要完成此工作、需要知道是否有成功的路径将使用 ARM FuSa 编译器工具构建的 ThreadX 链接到使用 TI 20.2.7_LTS 工具构建的映像中。  我询问 ARM 团队他们自己的 FuSa 工具链是否与自己的 ARM AEABI 规格兼容。  他们说是的、因此如果这是真的、那么我没有在一个或两个工具链中正确配置某个东西、或者20.2.7_LTS 链接器遇到了由 ARM FuSa 6.16.2生成的 ELF 问题

此外、如果根据某个经过认证的编译器构建、ThreadX 仅符合功能安全(FS)规范60730。  由于 ThreadX 编译系统从未移植到 TI LTS 系列编译器、因此除了需要付出巨大的努力来移植 ThreadX 本身并实现与60730工具链兼容的重新认证、这本身是非常重要的努力)、没有其他方法可以将这些重要组件添加到编译中。  我们需要为我们的应用以及 ThreadX 提供 TI HALCoGen 和 FS 库代码、因此我们要依靠 LTS 链接器在链接中取得成功。

TI 不会测试与 ARM FuSa 编译器构建的代码的链接。  我不知道有谁做过这件事。

链路失败、根本没有诊断程序？  你确定吗？  链接器会生成任何文件、例如 .out 或 .map 情况？

考虑该实验。  编写一个只有一个源文件的小型程序。  它具有一个从 ThreadX 库中调用一个函数的主函数。  这是一个不运行的仅构建实验。  像使用 TI Arm 编译器那样构建一个源文件。  将其与 ThreadX 库链接在一起。  发生什么情况？

谢谢。此致、

-George.

所有 Arm 属性(例如)如果有用  TAG_ABI_PCS_R9_USE 、在 由 Arm 维护的本规范中进行了说明。

谢谢。此致、

-George.

George、我在看标签时通读了许多 ABI 规范的部分内容。  我认为、在今天结束时、链接的成功将由以下内容来定义

• 修改 ARM FuSa 构建配置选项以尝试找到 TI LTS 链接器能够理解的最少基本子集
• 了解如何配置 LTS 编译器以使用与 ARM FuSa 编译器选项兼容的配置选项。

我仍然希望这能起作用。  例如 ARM DSP 库链接良好、没有问题、因此我们知道至少有一个外部构建的库可以正常工作。

现在、我正在为你写一个我几天前做的关于"简单使用案例"的实验——非常类似于你所建议的。  我需要一段时间才能发布详细信息。  之后、我将运行您认为的确切实验。  我认为这是一个很好的想法,简化一切,看看什么基本的东西是否有效。  我迷失在杂草中——应该在几天前做这件事。

如果 TI LTS 编译器之一的编译器人员能够查看这些标签就会很好。  我知道、有时(甚至现在) TI 编译器团队对标签有很大的了解、因为为了获取 ThreadX 的简单链接(我将在下面介绍)来工作、我必须以各种方式按摩 ARM FuSa 构建、从而消除基于"wchar_t size"和"enum size"以及"VFP Settings"等的错误。  如果库 ThreadX_XDER.A 没有将所有这些设置与 TI LTS 编译器相同、那么在链接时 LTS 链接器绝对值可以准确地详细检测到这一问题、并准确地告诉您它是什么。  因此、似乎有某种意义上说、互操作性是一个目标、至少对于非常简单的链路问题、否则您根本无法使用外部库。

相反、假设用于检测标签的所有 TI 智能仅用于检测 TI LTS 代码中不同的标签、而不是其他供应商代码、并且检测代码只是"碰巧"也适用于 ARM FuSa 生成的 ELF 代码。  然后、我们可能会遇到这样的情况、即使我正确获取了所有 ARM 构建配置、从而构建库时具有与 TI LTS 链接器所寻找的完全匹配的等效标签集、链接仍然会失败。  我想知道是否有 TI 的人可以回答这个非常简单的问题？  它是否永远不会起作用,或者是否有一个很好的机会,它可能只是调整更多的标签.  这是很多工作,我尝试所有这些不同的编译选项,希望达到头奖.

我将为上一个实验开始下一篇文章。  

Feww、当我进行上面列出的"大实验"时、链接器终止时、不会生成*。obj、也不会生成*。map 文件。

TI 注意、使用 ARM 业界通用 ABIv2应该能够成功链接使用不同工具链构建的对象。  在 TI 的编译器手册中：

还有一个您没有考虑的因素：Dwarf 调试信息。  Dwarf 规范非常灵活。  您可以用多种方式来表达相同的意思。  FuSa 工具链可能以符合规范的方式发出 Dwarf、但 TI 链接器仍然处理不当。  这种逃逸测试、因为 TI 工具链绝不会像 FuSa 工具链那样发射 Dwarf。  在失败之前缺乏任何诊断、这使我认为这可能会发生。  

我目前没有什么好建议。  我只是想让你知道我在想什么。

谢谢。此致、

-George.

您是否尝试过...

He Chen 说：

考虑此实验。  编写一个只有一个源文件的小型程序。  它具有一个从 ThreadX 库中调用一个函数的主函数。  这是一个不运行的仅构建实验。  像使用 TI Arm 编译器那样构建一个源文件。  将其与 ThreadX 库链接在一起。  [报价]

如果是、会发生什么情况？

谢谢。此致、

-George.

总结：

有两点。  我做了你建议的实验。  (1)与 FP 标签相关的链接器错误。  (2)我做了自己的实验、成功链接 ThreadX 有限。  这种情况非常好。

详细信息：

(1)您的实验。  链接失败、并出现浮点 Tag_ABI 兼容性问题。  TI 链接器外观似乎损坏了、因为它指出某些 ThreadX 文件具有与浮点相关的标签、这些标签与其他浮点(FP)标签不兼容、但实际上、如果您使用 readelf 从 ThreadX 库中转储 ABI 标签、TI 的编译输出错误中提到的标签实际上并不存在于 ThreadX 库中。  实际上、这些标签在相关 ThreadX 库模块中完全不存在。  但是、这可能是其他问题、并且诊断是虚假的。  

(2)但是,使用单个文件 main()样本应用程序(无 HAL 代码),我(最后)获得了一个成功的(不可用的二进制)链接与 ThreadX 这样的:

• ThreadX： 大端、无浮点、无调试信息、大端字节序
• TI RTS Lib： 由 TI、Thumb、Big Endian、 C：\ti 预构建。 . . \ti-CGT-ARM_20.2.7.LTS\lib\rtsv7R4_T_be_eabi.lib
• 应用程序: single main()函数构建: Thumb、大端字节序、无调试、无浮点。

-------

(3) 我构建了 CCS 不附带的普通库：rtsv7R4_a_le_eabi.lib。  以下链接成功：

• ThreadX： 无浮点、无调试信息、小端字节序
• TI RTS Lib： 由我使用 TI 构建工具构建：rtsv7R4_a_le_eabi.lib
• 应用程序: single main()函数构建:小端字节序,无调试,无浮点。

-------

(4)与框架主程序,成功链接以下与这些属性: ARM 状态,小端字节序,调试,无浮点

• ThreadX
• TI RTS 库
• Application： 单个 main()函数

-------

(5)与框架主程序,成功链接以下与这些属性: ARM 状态,小端字节序,调试,浮点

• ThreadX
• TI RTS 库
• Application： 单个 main()函数

-------

我读到、TI 编译器已经停产、但我很担心我将无法使用 TI 硬件、因为工具链的支持有限。  您能谈谈这个问题吗？  TI 内部是否对 Arm 目标的20.2.7_LTS 有任何支持？