[参考译文] AM2432：在 CCS 中重新编译会每次生成不同的二进制文件

您好、

这有点紧急。 这是最后一个阶段。 您能提出优先事项吗？

谢谢你。

此致、

Kasai

您好、

线程所有者将在 2 月 17 日的一周内停止工作。 如果您在这周内没有收到更新、请 ping 通该线程。

感谢您的耐心。

此致、
Harshith

我理解对两者之间差异的解释 构建工程 和 重新编译工程 。
但是、我观察到即使在使用时也是非确定性的二进制输出 构建工程 这似乎是核心问题。

复制步骤

1. 将 SDK 示例工程导入 CCS

2. 帧 构建工程

3. 保存生成的二进制文件

4. 从工作区中删除工程

5. 再次导入相同的示例工程

6. 帧 构建工程

7. 保存生成的二进制文件

8. 比较两个文件

结果： 尽管二进制是不同的

• 源代码相同

• 构建选项是相同的

• 工具链和 SDK 版本相同

• 重新编译工程 驱动器

问题

从配置管理的角度来看、只要源代码和编译环境相同、二进制文件就应该相同。

• 是否有任何编译器、链接器或 CCS 设置来使构建具有确定性？

附件

我附加了一个 ZIP 文件、其中包含通过两次导入同一个工程并使用进行编译而生成的两个输出 构建工程 、供参考和比较。

e2e.ti.com/.../SDK_5F00_example.zip

尊敬的 Tushar：

感谢您的快速分析。  

哪个优化级别不会导致这种情况？  如果应该咨询编译器专家、能不能告诉我吗？

此致、

Kasai

您好、Kasai、

哪个优化级别不会导致此问题？

我不是专门讨论二进制文件优化、而是讨论构建二进制文件的过程。 我不确定是否有任何标志可停止编译过程优化。

我正在将此线程路由到编译器团队以供进一步评论。

此致、

Tushar

尊敬的 Tushar：

感谢您将此路由到编译器团队。

此致、

Kasai

当我比较来自...的文件时

我附上了一个 ZIP 文件、其中包含通过两次导入同一个项目并使用编译生成的两个输出 构建工程 、供参考和比较。

我在二进制文件或反汇编文件上没有看到任何差异。  我只看到中的差异 .debug_line 部分。  这是 CCS 仅使用的一个信息部分。  它不会影响执行。

这与第一个帖子中报告的内容不匹配...

我比较了两个重建之间的以下输出、但它们都不匹配：

• .hs_fs间隔

• .out间隔

• .bin.out使用转换的文件 tiarmobjcopy

• .out使用生成的反汇编输出 tiarmobjdump -d

请关注拆卸差异。  这意味着链接器映射文件中应该会出现差异。  下面是映射文件中的示例行...

  7010fd58    00000150     discrete_io_device_dog.o (.text.DIO_DEVICE_DOG_addObject)

这表明长度为 0x150 字节时、地址 0x7010fd58 处是段的内容 .text：DIO_DEVICE_DOG_addObject 。  它来自目标文件 DISCRETE_IO_DEVICE_DOG.o 。  再把另一种方法、即函数的代码 DIO_DOG_addObject 加载自定义文件 DISCRETE_IO_DEVICE_DOG.c 位于该地址。  聚焦于长度（第 2）列。  对于这两个构建版本、请比较映射文件。  请忽略地址中的差异。  重点关注长度的差异。  对于一个长度不同的源文件、 请遵循 如何提交编译器测试用例一文中的说明。  但执行两次。  每次构建一次。  请检查并确保这两个构建会创建不同的目标文件。

谢谢。此致、

-乔治

同时、您在我的第一篇帖子中处理了所请求的测试案例...考虑您是否可能受到已知问题 EXT_EP-11620的影响。  要避免此问题、请执行以下操作之一：

• 升级到版本 4.0.x.LTS、其中 x >= 2
• 使用选项  fno-unique-string-section-name

谢谢。此致、

-乔治

根据您之前的答复、我执行了其他测试并观察到以下情况：

1. 创建一个新的系统

   tiarmobjcopy --strip-debug a.out a.bin
   

   .bin即使在使用后、生成的文件也是相同的 重新编译工程 只要项目绝对路径相同。

2. 如果工程绝对路径不同、.bin则生成的文件会有所不同。

3. 但是、添加选项时

   -fno-unique-string-section-names
   

   然后.bin使用生成文件

   tiarmobjcopy --strip-debug
   

   .bin即使工程绝对路径不同、生成的文件也是相同的。

问题

得出以下结论是正确的：

• 如果.bin生成的文件--strip-debug相同、

• 然后可执行行为（目标上的运行时行为）保证是相同的？

换言之、我们是否可以将已去除符号.bin的文件进行比较作为验证执行二进制行为是否没有区别的有效方法？

我们的主要关切是确保有 运行时行为没有差异 （即使与调试相关的部分或元数据有所不同）。

命令...

tiarmobjcopy --strip-debug a.out a.bin

...不创建二进制文件。  它会创建 ELF 二进制可执行文件的副本 A.OUT 、但没有像这样的调试部分 .debug_info 、 .debug_frame 等

要创建二进制文件、必须使用选项 --output-target=binary （或等效的 -O 二进制 )。   有关二进制文件的一般背景信息、请参阅文章 二进制文件简介。   二进制文件绝不包含调试段、符号表或其他类似段。  因此、在使用时 tiarmobjcopy 要创建二进制文件、可使用选项 --条带调试 没有影响。

如果两个二进制文件是相同的,这意味着...

执行二进制行为没有区别？

是的、实际情况是这样。  很多人都是这样想的。

但为了完整起见,我必须描述一个警告。  二进制文件反映了已初始化段的内容、如所示 .text 、 .rodata 等  因为它并不像那样直接反映未初始化段的内容 .bss 和 .stack 、理论上仍然可能是两个二进制文件相同、但在未初始化的段方面有一些差异。  但这只是一种理论。  我从未在实践中看到过这种情况。  例如、假设唯一的区别是的长度 .stack 部分。  在启动代码中造成某种差异。  这会导致中出现差异 .text 部分。  它是二进制文件的一部分。

谢谢。此致、

-乔治

您好、George、

感谢您的答复。

我们可以说当源相同时、二进制文件始终相同吗？ 这是他们想要知道的。

此致、

Kasai

它不仅仅是匹配源代码。  请参阅 此论坛帖子。  忽略有关的详细信息 -- keep_asm 。  不适用于类似的基于 CLANG 的编译器 tiarmclang 编译器 或 c29clang 。

谢谢。此致、

-乔治