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.

[参考译文] BOOSTXL-CC2650MA:链接器无法解析应用程序级符号

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1042482/boostxl-cc2650ma-linker-inconsistently-fails-to-resolve-application-level-symbols

器件型号:BOOSTXL-CC2650MA
Thread 中讨论的其他器件:BLE-STACK

我已经修改了 Github 中更新的 SPP_BLE_Server 示例、以便在 UART 和 BLE 接口之间基本上具有代理。  这涉及添加到应用程序项目的"Application"目录中的一些源文件和头文件、以及在需要时为它们提供的 include 语句。

最近出现了编译无问题完成的问题、但链接器失败、出现错误#10234-D:未解析的符号仍然存在。  这些符号是同一源文件中的三个函数。  报头声明和源定义匹配、它们不是静态的、应用程序目录是项目属性中的显式包含路径。  调用其中一个函数的每个源文件都包含标头。

但是、重现问题可能很困难;有时、链接器会工作。  有时、如果我只是在生成失败后再次调用它、它就会起作用。  有时、我花了一整天的时间尝试将其连接起来。  有时、它会在我进行更改后中断、因此我会恢复更改、清理和构建、但它仍然会损坏。  有一次、我得到了一个不同的错误、有一个有用的建议尝试:-cinit_hold_wdt=off。  我相应地调整了配置、并在两天内一直无问题地进行链接、直到我尝试递增 ICALL_MAX_NUM_TASK任务、ICALL_MAX_NUM_ENTIESTIOSAL_MAX_NUM_PROXY 任务以完成上述代理任务。

以前有关未解析符号的大多数票证似乎与库和存档相关联、我发现在应用程序源代码级别处理符号的票证没有提供任何有关解析的详细信息。

一个可能相关也可能不相关的注意事项是、当项目属性在 CCS Build>Arm Compiler 下打开任何窗格时、顶部有一个红色的"X"图标、表示"Cannot open command file '${SRC_EX}/config/build_components.opt:no such file or directory (无法打开命令文件'${SRC_EX})"。  我已经确认了用于定义 SRC_EX 的变量层次结构、它们都签出了、并且应该会产生一个与相关的 opt 文件的实际位置相匹配的路径、这肯定存在。

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

    尊敬的 James:

    将其转发给编译器团队。 同时、考虑从此项目重新下载 SDK 和源代码、并处理中的旧文件。 有时、.opt 文件中的内容可能会对整个 SDK 造成混乱、这可能会使同一示例中移植的其他项目陷入混乱。

    最棒的

    不需要

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

    如果能看到4个文件、我会很感激。  链接器映射文件和编译日志文件、用于正常运行的编译、相同的2个文件用于失败的编译。

    下面介绍了如何创建一个构建日志文件。  重建整个项目。  一种方法是右键点击工程名称、然后选择 Rebuild Project。  然后将"Console"(不是问题)视图的内容保存到文本文件中。  使用名为 Copy Build Log 的图标。

    请压缩所有4个文件、然后将 zip 附加到下一篇帖子。

    谢谢、此致、

    乔治

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

    e2e.ti.com/.../ti_5F00_tkt_5F00_linker_5F00_maps_5F00_and_5F00_logs_5F00_20211006.zip

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

    这可能与 ICALL_MAX_NUM_TESS、ICALL_MAX_NUM_ENTRIES 和 OSAL_MAX_NUM_PROXY 任务的值不正确有关。  实际上、我还有两个额外的任务、但只有一个任务调用最终嵌套 iCall 函数的函数。  因此、我只向 iCall 注册了该任务。  我尝试注册另一个任务(有趣的是、任务既不需要也不使用其关联的信标和实体结构)、并相应地重新递增上述定义。  构建并链接堆栈和应用项目、我还获得了所需的行为。  我不知道这实际上是否解决了链接问题、因为它的复制不一致、但它可能是相关的、因为有时成功/失败行为的变化会导致这一领域的变化...

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

    您的问题可能与两个方面有关。  第一、使用编译器选项-O4、即优化级别4。  在此级别、链接器会重新编译整个程序、以尝试查找更多优化。  第二、您使用的编译器版本5.2.6大约为6年。

    要考虑的解决方案...

    升级编译器。  在执行此操作之前、请查阅您使用的 SDK 的文档。  文档中可能记录了使用几个不同版本的编译器进行测试的情况。  您应该使用其中一个版本或非常接近的版本。  决定版本后、文章 更新编译器 详细介绍了如何执行该操作。

    将优化级别从-O4降低-O3

    请告诉我这些解决方案中的一个是否解决了该问题。

    谢谢、此致、

    乔治

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

    根据 BLE-Stack 2.2.1的发行说明、v5.2.6是唯一受支持的编译器依赖项。  当我第一次深入了解 TI 环境时、我发现如果我使用的堆栈/编译器/工具版本比我希望使用的原始示例的版本更高、那么我无法成功构建。

    由于将这些定义与我添加的任务数同步、我将反复获得成功的链接、但鉴于这是如何实现的、我将在关闭 TT 之前提供一周的时间。  如果它在那段时间内再次出现、我将尝试降低优化级别、这只是 SPP_ble_server 项目使用的默认级别。

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

    唉,我今天早上启动了我的机器,执行了一个完全干净的堆栈和应用程序项目构建--由于这三个功能,应用程序无法链接。

    我转到了优化级别3、结果相同。  如果可以、我会继续下降、但项目需要注意的一点是、在 UART 和 BLE 接口之间填充的代码已经突破了空间限制、并且可能存在一个最小优化级别、所有优化级别都仍然适合闪存...

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

    或者...可能是优化设置未采用。  当设置2级时、我注意到它仍然在4级上。  我再次设置了3级、并确保了它的运行、但我担心、我已经耗尽了闪存空间。

    我们的定制代码从不同的架构移植过来、包含大量的技术债务。  我已经对其中的大部分内容进行了优化、但我想我需要找到更多机会、以便我可以查看-O3是否解决了问题。

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

    在-O2处继续出现未定义的符号问题后、我选择尝试使用当前编译器 v20.2.5 LTS。  _TI_Compiler_version 或__TI_Compiler_version__的定义改变了 osal.c 中 ltoa ()的原型;通过覆盖该行为以保留原始原型,我得以进行编译。

    我假设如果您没有先成功链接所有符号、就不会遇到空间不足的错误、因此在我继续进行高级优化时、我将再次为其提供更多时间。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="491177" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1042482/boostxl-cc2650ma-linker-inconsistently-fails-to-resolve-application-level-symbols/3859893 #3859893"]__TI_Compiler_version 或__TI_Compiler_version__的定义改变了 osal.c中 ltoa ()的原型

    编译器版本5.2.6和20.2.5.LTS 之间更改了函数 ltoa 的定义。  您需要确保正确调用它。  有关详细信息、请参阅文章 处理 ltoa 中的更改

    非常感谢您试用了版本20.2.5.LTS。  我相信它没有问题。

    谢谢、此致、

    乔治

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

    我仍然使用20.2.5 LTS 获得项目的 Release 构建的未解析符号。  Debug 编译为我提供了空间不足错误。 版本编译具有大约15kB 的备用空间、而调试编译似乎具有~2kB 的多余空间。  (我在上一条评论中对链接的假设似乎不正确。)

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

    好的、所以我意识到我只更新了调试构建的任务计数相关宏以及编译器...我还需要为发布构建更新此操作。  堆栈项目也是如此。  我相应地更新了两个工程上的 Release 编译、并重建了所有内容。

    该应用的 Debug 编译器现在只适用于闪存、但由于未定义的函数、使用20.2.5 LTS 版本的编译器、Release 编译仍会失败。

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

    我将通过私人邮件与您联系。  乔治

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

    总结:

     *正确配置 ICALL_MAX_NUM_TESS、ICALL_MAX_NUM_ENTRIES 和 OSAL_MAX_NUM_PROXY 任务后、我看到了明显的改进

     *使用当前编译器后,情况进一步改善,需要更改从 osal.c 调用 ltoa()的方式

     *很明显、包含有问题符号的源文件被排除在 Release 编译之外、我一直在忽略它、因为我习惯了(有问题)使用 Build All、这意味着我通常只注意到 Debug 编译的最终结果。

    我相信这一切都将为好而整理、尽管我将等待几天以确保...