TI E2E™ 设计支持论坛将于 5 月 30 日至 6 月 1 日进行维护。如果您在此期间需要技术支持,请联系 TI 的客户支持中心寻求帮助。

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.

[参考译文] 在同一环境中使用2台 PC 构建项目、但有区别。

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

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1221219/build-project-using-2-pcs-in-the-same-environment-but-there-is-a-difference

"Thread:SysConfig"、"SysBIOS"中讨论的其他器件

尊敬的专家:

我的客户遇到了一个奇怪的现象。

[问题]
您能否告诉我、以下问题现象是否有任何解决方案?

[问题]
项目是使用两台 PC 在同一环境中构建的、但编写项目后的行为有所不同。
区别仅在于 PC 的 OS 版本。

[详情]

  •  PC 的操作系统版本存在差异(PC1=Windows10pro 22H2、PC2=Windows10pro 21H2)
  • CCS 无差异:10.1.1.00004
  • 编译器:TI v20.2.1LTS 中无差异
  • 编译器和链接器设置之间没有差异(标志集摘要)。
  • 源代码无差异
  • 从 PC1导出 OK 项目,将其导入 PC2,然后生成,结果为 NG。
    导出 PC2的 NG 项目,将其导入 PC1并生成,结果正常。
  • 在使用"代码生成工具 XML 处理实用程序"并输入.out 文件后、文件存在差异。
    .map 文件存在差异。
    在.text 和.cinit 区域中、"hole --[fill = 0]"增加了8个字节。
    此外、.text 区域中每个.obj 的顺序也不同。

此致、
还可以

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

    您好!

    编写项目后行为有所不同。
    [quote userid="402494" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1221219/build-project-using-2-pcs-in-the-same-environment-but-there-is-a-difference 从 PC1导出 OK 项目、将其导入 PC2并生成该项目、结果为 NG。
    导出 PC2的 NG 项目,将其导入 PC1并生成,结果为 OK。

    行为或结果有何区别? 程序是否未在目标上按预期运行? 请说明。

    谢谢

    小标题  

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

    您好、ki、

    感谢您的答复。

    行为或结果的具体区别是什么? 程序是否未在目标上按预期运行? 请说明。

    我们不确定具体差异有多大、并且尚未能够通过"Disassembly"、"Step execution"等功能确认详细信息
    程序在 PC2上构建时在目标上的运行方式与预期不符。

    此致、
    还可以

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

    这些 SDK 中的可能差异如何? 例如,两台计算机上的 c\:ti\c2000\*内容是否相同?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    构建 PC2时,程序在目标上的行为不符合预期。

    客户如何确定该程序的行为不正确? 它是否遇到某种异常? 是否应该产生一些结果、但结果不正确?

    Kier 还提出了一个关于检查 SDK 等差异的任何依赖项的建议

    此外、请让客户在构建控制台中为 OK 和 NG 构建提供完整构建输出。 他们可以复制并粘贴到文本文件、然后可以将其附加到该线程。

    谢谢

    小标题  

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

    您好、ki、

    很抱歉这么晚才回复。

    我们正在使用的器件是 MSP432P401R、SKD 是"simplelink_msp432p4_SDK_3_40_01_02"。
    使用器件的目的是为了进行临时验证、但如果此问题与器件无关、我们将提供任何建议。

    客户如何确定该程序不运行? 它是否遇到某种异常? 是否应该产生一些结果,但结果不正确?

    他们正在使用 UART 与外界进行串行通信、但他们已经确认、只有在我们对异常的 PC 进行写入时、在执行某些命令时、它们在同一时刻总是会出现错误。

    Kier 还提出了有关检查 SDK 等差异的任何依赖项的建议[/报价]

    两台 PC 都保存在 C:\ti\simplelink_msp432p4_sdk_3_40_01_02中、该文件夹中的文件大小和数量完全相同、因此我们确定没有区别。

    此外,请客户在构建控制台中为 OK 和 NG 构建提供完整构建输出。 他们可以复制并粘贴到一个文本文件,然后可以附加到该线程。

    附件是在两台 PC 上构建的同一项目的控制台结果。
    (C 盘下的项目名称和名称有意隐藏、因为它们涉及客户信息。)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* OK Build */
    **** Clean-only build of configuration Debug for project PROJECT_A ****
    "C:\\ti\\ccs1011\\ccs\\utils\\bin\\gmake" -k -j 4 clean -O
    DEL /F "syscfg\ti_drivers_config.h" "syscfg\syscfg_c.rov.xs" "PROJECT_A.hex" "syscfg\ti_drivers_config.c" "PROJECT_A.out"
    DEL /F "ADXL346.obj" "syscfg\ti_drivers_config.obj" "FlashSettings.obj" "StartStop.obj" "Status_thread.obj" "adc_bat.obj" "deepsleep.obj" "empty.obj" "fram.obj" "main_tirtos.obj" "rtc.obj" "subThread.obj" "uart_thread.obj" "waitTimer.obj"
    DEL /F "ADXL346.d" "syscfg\ti_drivers_config.d" "FlashSettings.d" "StartStop.d" "Status_thread.d" "adc_bat.d" "deepsleep.d" "empty.d" "fram.d" "main_tirtos.d" "rtc.d" "subThread.d" "uart_thread.d" "waitTimer.d"
    RMDIR /S/Q "syscfg\"
    C:\Users\XXXX\workspace_v10\PROJECT_A\Debug\PROJECT_A.hex
    Finished clean
    **** Build Finished ****
    **** Build of configuration Debug for project PROJECT_A ****
    "C:\\ti\\ccs1011\\ccs\\utils\\bin\\gmake" -k -j 4 all -O
    Building file: "../PROJECT_A.syscfg"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* NG Build */
    **** Clean-only build of configuration Debug for project PROJECT_A ****
    "C:\\ti\\ccs1011\\ccs\\utils\\bin\\gmake" -k -j 4 clean -O
    DEL /F "syscfg\ti_drivers_config.h" "syscfg\syscfg_c.rov.xs" "PROJECT_A.hex" "syscfg\ti_drivers_config.c" "PROJECT_A.out"
    DEL /F "ADXL346.obj" "syscfg\ti_drivers_config.obj" "FlashSettings.obj" "StartStop.obj" "Status_thread.obj" "adc_bat.obj" "deepsleep.obj" "empty.obj" "fram.obj" "main_tirtos.obj" "rtc.obj" "subThread.obj" "uart_thread.obj" "waitTimer.obj"
    DEL /F "ADXL346.d" "syscfg\ti_drivers_config.d" "FlashSettings.d" "StartStop.d" "Status_thread.d" "adc_bat.d" "deepsleep.d" "empty.d" "fram.d" "main_tirtos.d" "rtc.d" "subThread.d" "uart_thread.d" "waitTimer.d"
    RMDIR /S/Q "syscfg\"
    C:\Users\XXXX\workspace_v10\PROJECT_A\Debug\PROJECT_A.hex
    Finished clean
    **** Build Finished ****
    **** Build of configuration Debug for project PROJECT_A ****
    "C:\\ti\\ccs1011\\ccs\\utils\\bin\\gmake" -k -j 4 all -O
    Building file: "../PROJECT_A.syscfg"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    此致、
    还可以

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

    谢谢你。 这两者之间的构建输出非常相似。 文件的编译器顺序略有不同、但链接顺序看起来相同。 SysConfig 调用的参数有点不同、但我认为这不会在这里产生影响。 使用相同版本的编译器和 CCS。

    是否也可以提供两种场景的*。map 文件?

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

    Hell Ki:

    感谢您的支持。

    由于客户请求,*。map 文件已通过私人聊天发送给您。

    此致、
    还可以

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

    谢谢你。 我确实看到了细微的差异。 我不知道原因是什么。 我需要将此主题提请编译器专家注意、以进一步引起注意

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

    感谢您提交地图文件。  我可以看到差异。  我无法解释它们。   

    前几行中列出了工具的版本。  从 OK 映射文件...

    Fullscreen
    1
    TI ARM Linker PC v20.2.1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    从 NG 构建...

    Fullscreen
    1
    TI ARM Linker PC v20.2.7
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    NG 构建使用版本20.2.7.LTS。  这与几篇文章之前的构建日志中显示的不同。  这两个编译日志中都使用了版本20.2.1.LTS。

    另一个差异是其中一个函数的大小。  下面是 OK 映射文件中的条目...

    Fullscreen
    1
    00008af8 000000e0 sysbios.aem4f : BIOS.obj (.text:ti_sysbios_knl_Task_Instance_init__E)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    以下是 NG 映射文件中相应的条目...

    Fullscreen
    1
    00008938 000000e4 sysbios.aem4f : BIOS.obj (.text:ti_sysbios_knl_Task_Instance_init__E)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    这是函数的代码  TI_SysBIOS_KNL_Task_instance_init__E ,从目标文件中 BIOS.obj ,它是图书馆的成员 sysbios.aem4f 。  第一列是地址。  就目前而言、忽略该差异。  第二列是"Size (大小)"。  专注于这种差异。  我无法解释为什么它们的尺寸不同。

    但也可能存在其他差异。  但这两个差异似乎是一个很好的起点。

    谢谢。此致、

    -George.

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

    您好、George、

    感谢您的支持。

    前几行中列出了工具的版本。  从 OK 映射文件...

    全屏
    1.
    TI ARM 链接器 PC v20.2.1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    TI ARM Linker PC v20.2.1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    从 NG 构建...

    全屏
    1.
    TI ARM 链接器 PC v20.2.7
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    TI ARM Linker PC v20.2.7
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    NG 构建使用版本20.2.7.LTS。  这与几篇文章之前的构建日志中显示的不同。  这两个编译日志中都使用了版本20.2.1.LTS。

    [/报价]

    我的道歉。

    我们将编译器版本统一到了"v20.2.1"、但*。map 文件没有区别。
    "sysbios.aem4f:BIOS.obj (.text:ti_sysbios_KNL_Task_instance_init__E)" zise 不受影响。

    另一个差异是其中一个函数的大小。  下面是 OK 映射文件中的条目...

    全屏
    1.
    00008af8 000000e0 sysbios.aem4f:BIOS.obj (.text:ti_sysbios_KNL_Task_instance_init__E)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    00008af8 000000e0 sysbios.aem4f : BIOS.obj (.text:ti_sysbios_knl_Task_Instance_init__E)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    以下是 NG 映射文件中相应的条目...

    全屏
    1.
    00008938 000000e4 sysbios.aem4f:BIOS.obj (.text:ti_sysbios_KNL_Task_instance_init__E)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    00008938 000000e4 sysbios.aem4f : BIOS.obj (.text:ti_sysbios_knl_Task_Instance_init__E)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    这是函数的代码  TI_SysBIOS_KNL_Task_instance_init__E ,从目标文件中 BIOS.obj ,它是图书馆的成员 sysbios.aem4f 。  第一列是地址。  就目前而言、忽略该差异。  第二列是"Size (大小)"。  专注于这种差异。  我无法解释为什么它们的尺寸不同。

    [/报价]

    是否有任何指标可确定编译是否正常工作?
    顺便说一下、该情况是否仅适用于 MSP432P4?

    仅在这段时间内、我们已经能够识别出可以正常构建的 PC、因此如果我们只在该 PC 上运行、我们就可以处理该问题。
    然而、当我们考虑未来时、我们不希望构建结果随着 PC 的不同而改变。。

    此致、
    还可以

    [/quote]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    是否有任何指标可确定版本是否正常运行?

    否  运行测试以查看其是否正常运行。

    此情况是否仅适用于 MSP432P4?

    我们不知道发生了什么、也不知道原因是什么。  它不太可能特定于 MSP432P4。

    使用"代码生成工具 XML 处理实用程序"并输入.out 文件后、文件存在差异。

    我想看看这个。

    .map 文件有区别。

    我想您的意思是我尚未谈到的一些不同之处。  我想看看这个。

    谢谢。此致、

    -George.

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

    您好、George、

    感谢您的支持。

    在使用"代码生成工具 XML 处理实用程序"并输入.out 文件后、文件存在差异。

    我想看看这个。

    [/报价]

    附件为文件。

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* OK PC */
    C:\Program Files (x86)\ti\cgxml-2.61.00\bin>ofd6x -x OK.out | sectti
    Reading from stdin ...
    ************************************************************
    REPORT FOR FILE: OK.out
    ************************************************************
    Name : Size (dec) Size (hex) Type Load Addr Run Addr
    -------------------- : ---------- ---------- ---- ---------- ----------
    .text : 66850 0x00010522 CODE 0x00000040 0x00000040
    .const : 2454 0x00000996 DATA 0x00010564 0x00010564
    .cinit : 1632 0x00000660 DATA 0x00010f00 0x00010f00
    .data : 5597 0x000015dd UDATA 0x20008140 0x20008140
    .bss : 3409 0x00000d51 UDATA 0x20009800 0x20009800
    .priheap : 32768 0x00008000 UDATA 0x20000140 0x20000140
    .stack : 1024 0x00000400 UDATA 0x2000fc00 0x2000fc00
    .resetVecs : 60 0x0000003c DATA 0x00000000 0x00000000
    ------------------------------------------------------------
    Totals by section type
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* NG PC */
    c:\Program Files (x86)\ti\cgxml-2.61.00\bin>ofd6x -x NG.out | sectti
    Reading from stdin ...
    ************************************************************
    REPORT FOR FILE: NG.out
    ************************************************************
    Name : Size (dec) Size (hex) Type Load Addr Run Addr
    -------------------- : ---------- ---------- ---- ---------- ----------
    .text : 66858 0x0001052a CODE 0x00000040 0x00000040
    .const : 2454 0x00000996 DATA 0x0001056c 0x0001056c
    .cinit : 1640 0x00000668 DATA 0x00010f08 0x00010f08
    .data : 5597 0x000015dd UDATA 0x20008140 0x20008140
    .bss : 3409 0x00000d51 UDATA 0x20009800 0x20009800
    .priheap : 32768 0x00008000 UDATA 0x20000140 0x20000140
    .stack : 1024 0x00000400 UDATA 0x2000fc00 0x2000fc00
    .resetVecs : 60 0x0000003c DATA 0x00000000 0x00000000
    ------------------------------------------------------------
    Totals by section type
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    .map 文件存在差异。

    我想您的意思是我尚未谈到的一些不同之处。  我想看看这个。

    [/报价]

    抱歉。 我给出了令人困惑的信息。
    对于上述内容、"Code Generation Tools XML Processing Utilities"输出和.map 文件之间没有差异。
    流程是"代码生成工具 XML 处理实用程序"的输出存在差异、因此我检查了.map 文件。

    此致、
    还可以

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

    重点说明了的大小有8字节的差异 .text 首选。  我们已经知道、这种差异的4个字节是由函数引起的  TI_SysBIOS_KNL_Task_instance_init__E 。   若要查找导致其他4个字节差异的函数、请使用 查找代码大小增加源中介绍的方法。  但可以使用它来查找所有具有不同大小的函数。   

    我重复我刚才所说的一点。  我无法解释为什么要使用该功能  TI_SysBIOS_KNL_Task_instance_init__E 会有不同的尺寸。

    谢谢。此致、

    -George.

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

    您好、George、

    感谢您的答复。

    是不是很难想出某种猜测这一问题的原因?

    重点说明了的大小有8字节的差异 .text 首选。  我们已经知道、这种差异的4个字节是由函数引起的  TI_SysBIOS_KNL_Task_instance_init__E 。   若要查找导致其他4个字节差异的函数、请使用 查找代码大小增加源中介绍的方法。  但可以使用它来查找所有具有不同大小的函数。   

    我重复我刚才所说的一点。  我无法解释为什么要使用该功能  TI_SysBIOS_KNL_Task_instance_init__E 会有不同的尺寸。

    [/报价]

    使用上述工具,我们发现唯一有区别的功能是" TI_SysBIOS_KNL_Task_instance_init__E "。
    此外、出于某种原因、大小增加到了6Byte、...

    确定。输出 TI_SysBIOS_KNL_Task_instance_init__E c:/ti/simplelink_msp432p4_sdk_3_40_01_02/kernel/tirtos/packages/ti/sysbios/knl/Task.c 0x00008af8 0x00008bc2 202.
    NG.out TI_SysBIOS_KNL_Task_instance_init__E c:/ti/simplelink_msp432p4_sdk_3_40_01_02/kernel/tirtos/packages/ti/sysbios/knl/Task.c 0x00008938 0x00008a08 208.

    此致、
    还可以

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

    你好——两个版本之间的内容有什么区别ti_sysbios_knl_Task_Instance_init__E?你可以分解它吗? 似乎每台 PC 上的环境有些不同。

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

    您好、Alan Phipps、

    感谢您的建议。

    "TI_SysBIOS_KNL_Task_instance_init_E"在"task.h"中定义为"Task_instance_init"。
    由于"Task.c"包含"Task_instance_init ()"、我将按照你的建议在 PC 之间进行比较。

    最好的房间
    还可以

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

    您好、 Alan Phipps、

    "ti_sysbios_KNL_Task_instance_init_E"在 task.h"中定义为"Task_instance_init"。
    由于"Task.c"包含"Task_instance_init ()",我将按照你的建议在 PC 之间进行比较。

    由于上述原因、未发现任何差异...

    另外、他们在异常 PC 上卸载了 SDK、并复制并将文件夹粘贴到正常 PC 上、.map 文件未像发生异常时那样更改。

    此致、
    还可以

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

    嗨——我问的是反汇编的对象代码,而不是源代码。  如上所述、函数的目标代码大小不同。 您可以使用 dis2000工具将其分解。  我们尝试了解的是尺寸差异的原因。  环境中的某些内容似乎会导致代码在不同 PC 上的构建方式略有不同。

    谢谢。

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

    您好、 Alan Phipps、

    嗨--我问的是反汇编的对象代码,而不是源代码。  如上所述、函数的目标代码大小不同。 您可以使用 dis2000工具将其分解。  我们尝试了解的是尺寸差异的原因。  似乎环境中的某些内容会导致代码在不同 PC 上的构建方式略有不同。

    很抱歉误解。

    CPU 是 M4F、因此我们在一台正常的 PC 上按照以下路径运行该工具。 附加了在没有"armdis.exe"选项的情况下运行该工具的结果。
    C:\ti\ccs1011\ccs\tools\compiler\ti-cgt-arm_20.2.1.LTS\bin

    字节数增加了4个字节、但指令的顺序和内容也略有变化。

    是不是很难从这种差异或从进一步调查中考虑因素和对策...?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* OK.out */
    TEXT Section .text 0x10522 bytes at 0x00000040
    ~~~~~
    008af8: ti_sysbios_knl_Task_Instance_init__E:
    008af8: .thumb
    008af8: .text:ti_sysbios_knl_Task_Instance_init__E:
    ~~~~~
    008b48: $C$L385:
    008b48: 002A CMP R2 #0
    008b4a: 08BF IT EQ
    008b4c: 2362 STREQ R3 [R4 #32]
    008b4e: 09D0 BEQ $C$L386 [0x8b64]
    008b50: 9B18 ADDS R3 R3 R2
    008b52: 521E SUBS R2 R2 #1
    008b54: 5B1E SUBS R3 R3 #1
    008b56: 9343 BICS R3 R2
    008b58: 2362 STR R3 [R4 #32]
    008b5a: E969 LDR R1 [R5 #28]
    008b5c: FF1A SUBS R7 R7 R3
    008b5e: 7F18 ADDS R7 R7 R1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /* NG.out */
    TEXT Section .text 0x1052a bytes at 0x00000040
    ~~~~~
    008938: ti_sysbios_knl_Task_Instance_init__E:
    008938: .thumb
    008938: .text:ti_sysbios_knl_Task_Instance_init__E:
    ~~~~~
    008988: $C$L385:
    008988: 002A CMP R2 #0
    00898a: 04BF ITT EQ
    00898c: 2362 STREQ R3 [R4 #32]
    00898e: 381C ADDEQ R0 R7 #0
    008990: 0BD0 BEQ $C$L386 [0x89aa]
    008992: 501E SUBS R0 R2 #1
    008994: 9B18 ADDS R3 R3 R2
    008996: C043 MVNS R0 R0
    008998: 5B1E SUBS R3 R3 #1
    00899a: 00EA0302 AND.W R2 R0 R3
    00899e: 2262 STR R2 [R4 #32]
    0089a0: E969 LDR R1 [R5 #28]
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    此致、
    还可以

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

    谢谢!  是的、您可以使用 armdis (不能像我在上面所说的那样使用 dis2000)。 这毫无疑问地证明了、对于每个环境、该函数的编译是不同的。  我认为您必须从这开始反向工作、以弄清编译中发生了什么变化。 您可能需要联系 SDK 所有者进行调试。

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

    您好、 Alan Phipps、

    这是否意味着此问题可能取决于 msp432p4_sdk

    此致、
    还可以

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

    我不确定这是 SDK 特异性的问题、但我认为 SDK 产品线最适合帮助了解导致该问题的原因。 它似乎依赖于实际工程以及有关编译系统环境的东西、而不是编译器本身。

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

    您好、 Alan Phipps、

    很抱歉迟到了回复。

    我们与客户讨论了这一点、并决定不进行任何进一步的调查。
    根据调查结果、我们得出结论:"这取决于 PC 端的构建系统环境"。

    我不确定这是 SDK 的具体问题,但我认为 SDK 产品线最适合帮助确定是什么引起了该问题。 它似乎依赖于实际的项目和与构建系统环境有关的东西,而不是编译器本身。

    感谢您的大力支持!

    此致、
    还可以