This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CODECOMPOSER:无法构建可再现图像

Guru**** 1825110 points
Other Parts Discussed in Thread: SYSCONFIG, MSPM0G3507
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1420263/codecomposer-unable-to-build-reproduceable-images

器件型号:CODECOMPOSER
主题中讨论的其他器件:SysConfigMSPM0G3507

工具与软件:

在某些项目中、在不同的工作区构建源代码时、我会得到不同的 Intel hex 文件输出映像。  您能告诉我要更改什么来纠正此问题吗?  以下是我重现的步骤:

1) 1)将 Repo 下载到我的 PC 上的新文件夹 A。

2) 2)将文件夹 A 复制到 PC 上的文件夹 B、以创建两个相同的文件夹图像。

3)创建文件夹 A 和 B 的 MD5 CRC 以确认文件夹是相同的。

4) 4)启动 CCS 并创建新工作区 A、然后启动第二次 CCS 迭代并创建新的工作区 B

5) 5)将文件夹 A 中的工程加载到工作区中、然后将文件夹 B 中的工程加载到工作区 B 中

6) 6)在工作区 A 中编译项目、然后在工作区 B 中编译项目

运行这些步骤后、我看到映射文件和十六进制目标文件不匹配。  

Windows 11 Enterprise 64位

CCS 12.80.00012

MSPM0 SDK 2.2.0.05

SysConfig 1.21.0

目标器件是 MSPM0G3507

地图和十六进制文件可根据要求提供。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Bryan:

    您能否提供您正在使用的2个项目? 我们可以尝试在最后重现它 理论上、如果两个工程中都有相同的文件、并且两个工程都使用相同的编译选项、则应生成相同的输出文件。

    谢谢!

    Ricky

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    受影响的地址处有哪些符号?

    您是否有可在每次编译时嵌入 Eclipse 变量的源代码? 例如日期戳、时间戳、PC ID 等

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我的雇主与 TI 签订了 NDA、所以我可以将项目发送给您。   您能否向我提供 您的 电子邮件或 FTP 链接?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我可以从映射文件中辨别出的唯一一点是 rodata 中的某些条目在两个编译版本之间的排列方式不同。

    我们不使用 __TIME__和__DATE__宏。   我们的编译包括 FreeRTOS、但我也看不到该源代码中对这些宏的引用。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Ricky、您能给我提供 您的 电子邮件或 FTP 链接吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    为了缩小调查范围、我想查看每个项目的地图文件。  请将其放入一个 zip 文件中、并 将其附加到您的下一篇文章中。

    谢谢。此致、

    -George.

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的、谢谢 George。  我通过私人消息将它们发送给您。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、George:
    您在私下聊天中建议 将构建选项-fno-unique-string-section-names 添加到工程(位于 Properties->Build->Arm Compiler->Advanced Options->Runtime Model Options 中) 、可解决此问题:

    "添加构建选项-fno-unique-string-section-names。 这会导致.rodata 段名末尾没有随机数 这样可以避免此问题的完整解释有点长。 我想确保它能解决您的问题、然后再解释它。"

    该 问题已解决。 您能否提供解释以结束本次讨论?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您能否提供结束本次讨论的解释?

    请考虑这些小示例源文件。

    /* f1.c */
    char *string1 = "1234";

    /* f2.c */
    char *string2 = "4567";

    这些命令用于构建文件、然后显示的目标文件信息 .rodata 这些字符串常量的段 1234. 4567 .

    C:\examples>tiarmclang -c f1.c f2.c
    
    C:\examples>tiarmobjdump --section-headers f1.o f2.o | findstr rodata
      3 .rodata.str1.46742538633553554961 00000005 00000000 DATA
      3 .rodata.str1.107989333500472712171 00000005 00000000 DATA

    请注意如何 .rodata 段名以自动生成的较长数字结尾。  影响该数字的输入之一是目录到源文件的完整路径。  因此,在你的构建比较中,这是情况下...

    将文件夹 A 复制到 PC 上的文件夹 B、创建两个相同的文件夹映像。

    这些自动生成的数字是不同的。

    部分中) 链接器命令文件中的指令可能具有类似...的条目

        .rodata > FLASH

    这会告诉链接器创建一个名为的输出段 .rodata .  它由所有开始的输入部分组成 .rodata .  其中包括 .rodata 输入部分与上面看到的类似。  该规范对输入段不施加任何顺序。  在这种情况下、链接器按大小(从大到小)排序。  与上面的输入段一样、相同大小的输入段会怎么样?  这种类型必须是稳定的,所以必须有一些断线器。  第一个断线器是输入段名称。  当输入段名称不同时、它们按段名称的字母顺序排列。  由于 .rodata 文件夹 A 编译中的输入节具有与文件夹 B 编译中相同的输入节不同的名称、这种断连开关会导致这些输入节的顺序不同 .rodata 输入段。  这样就会产生您在比较时看到的差异 .rodata 中的输出段。  该差异会在整个可执行文件中传播。  引用这些字符串的位置会因其不同的地址而有所不同。  注意如何通过执行代码能够检测到这种差异。    

    谢谢。此致、

    -George.

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    fno-unique-string-section-names 选项究竟如何防止按输入段名称对源文件进行排序?

    项目从 Gitlab 分出到每个开发人员的 PC 上、路径因 PC 而异。 我们使用 CCS Eclipse 编译器已有12个月左右的时间、而且以前没有观察到构建不匹配的情况。 编译器是否始终使用此排序方法来选择文件的链接顺序? 如果是、您是否认为我们最近观察到此事件是偶然的、并且基于我们最近对一个或多个源文件所做的更改? 或者、CCS 12.8中是否不采用按输入部分名称排序?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    链接器中的排序行为永远不会改变。   

    为防止按输入节名称对源文件排序、使用-fno-unique-string-section-names 选项到底做了什么?

    这些命令使用与我上一篇文章相同的源文件。  请注意的用法  -fno-unique-string-section-names .   

    C:\examples>tiarmclang -c -fno-unique-string-section-names f1.c f2.c
    
    C:\examples>tiarmobjdump --section-headers f1.o f2.o | findstr rodata
      3 .rodata.str1.1    00000005 00000000 DATA
      3 .rodata.str1.1    00000005 00000000 DATA

    现在、所有输入节名称都是相同的。  为了保持分类稳定、使用了第二个接线断路器。  第二个断线器是链接器遇到提供输入段的目标文件的顺序。  在这种情况下、由于构建命令是相同的、这意味着链接器以相同的顺序看到目标文件、因此输入节按相同的顺序排序。

    当您更改 CCS 的版本时、可能会同时更改编译器的版本。   在输入段名称的末尾添加一个较长的自动生成数字、其开头为 tiarmclang 编译器版本3.2.0.LTS。  您可能将3.2.0.LTS 以下的编译器版本更改为高于3.2.0.LTS 的编译器版本。

    谢谢。此致、

    -George.