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.

[参考译文] TMS320F280036-Q1:Unix 和 Windows 环境下的 CCS 编译结果为何不同?

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1400182/tms320f280036-q1-why-is-there-a-difference-in-ccs-compilation-results-between-unix-and-windows-environments

Thread 中讨论的其他器件:C2000WARE

工具与软件:

问题描述:

为什么.map在 Linux 与 Windows 环境中编译时、使用相同 CCS V12.6生成的文件的内容存在差异?

区别主要在于const段的长度和顺序。 请参见下图。

左侧是 Linux 下的映射、右侧是窗口下的映射

背景信息:

为了便于调试、我们的项目是在 Windows 环境中使用 CCS V12.6进行开发和调试的。 相应的 .c & .h 文件和项目文件(,).ccsproject .cproject .project将上载到服务器的 Git 存储库。 软件测试部门使用 Linux 服务器上安装的 CCS V12.6统一编译和链接这些文件、然后发布 .out  .hex 文件。

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

    e2e.ti.com/.../compare-map.zipin这个 zip、一个是由 windows 编译的映射文件、另一个是由 linux 编译的  

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

    我建议您关注一个问题: 为什么是 .const:.string 部分的第一句话 ecapdriver.obj 另一个尺寸?  Linux 0x99、Windows 0x89。  首先比较预处理器列表文件。  要了解什么是预处理器列表文件、 请搜索 C28x 编译器手册 中标题为 生成原始列表文件的子章节。  使用 CCS 文件特定选项功能 启用 ——gen_preprocessor_listing 只适用于 ecapdriver.c .  然后在 Linux 和 Windows 上构建。  将两者进行比较 .rl 子目录。  我相信你会发现一个不同的地方。  解释这种差异可能会让您找到根本原因。

    谢谢。此致、

    -George.

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

    感谢您的及时回复。

    我比较了在两种环境下编译的 RL 文件、差异主要来自__error__(文件所在的路径)的输入参数、如下所示

    示例: 执行 { if (! (HRCAP_isBaseValid (base))) { _ERROR__("C:/ti/c2000/C2000Ware_5_01_00_00/driverlib/f28003x/driverlib/hrcap.h、 154); }  while ((_Bool) 0);

    我的理解是、当断言存在异常时、它会调用 error 函数、该函数需要文件名(包括路径)和行数作为输入参数。
    两种环境之间的 driverlib 地址目录存在差异。
    这种差异是否有风险?

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

    对此进行分析 置为有效 宏与宏类似 置为有效 标准头文件中读取 .  但事实并非如此。  这意味着您可以对其进行更改。  现在、它使用编译器预定义的预处理器符号 __文件___ .   我建议您更换 __文件___ 处理一个类似的东西。  但是、由于您可以控制它、因此您可以使它在 Windows 和 Linux 中的工作方式相同。

    谢谢。此致、

    -George.

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

    感谢您的及时回复。

    我从 IDE 配置中删除了调试宏、以便程序不再调用关联的断言宏。 然后比较二者之间的差异。

    映射文件的主体已经是相同的(激励我)、

    但是、为 OTA 生成的.hex 文件(由 IDE 的 C2000 Hex Utility 生成)具有3个字节的差异(分布在两个不同的区域)。

    这是否有风险?

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

    我不知道差异是否有风险。  但我有一个建议,如何找到差异的原因。

    对于这两个编译,反汇编最终可执行文件与类似的命令...

    Fullscreen
    1
    % dis2000 --all executable_file.out > disassembly_file.txt
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    反汇编器  dis2000 位于同一位置 \bin 加载目录作为编译器 cl2000 .  比较每个构建中的反汇编代码。  请在差异地址之前检查标签。  这会显示与该地址关联的函数(如果是代码)或数据变量(如果是数据)的名称。  搜索源代码、查找包含该函数或变量的 C 文件。  然后、对该 C 文件重复预处理器列表文件比较。   

    谢谢。此致、

    -George.

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

    原因已找到、感谢您的支持!