[参考译文] MCU-PLUS-SDK - AM243X：&quot；不去除符号 X、因为它在重定位和 quot 中命名；

Felix、您好！  

感谢您的提问。

首先我尝试用 weak 声明它们、所以我们将覆盖 SDK 的那些、但它不起作用

如果您想使用自己的代码覆盖中止处理程序、我建议在函数本身内部编写您的代码、而不是将其声明为弱代码。

是否有不在函数本身中覆盖代码定义的特定用例？

此致、

Tushar

嗨、Tushar、

是的、原因是、我们的异常中断处理程序也会调用我们自己的代码、这个代码在 SDK 编译时并不属于构建过程。 因此编译会失败、或者我们需要为此引入额外的接口。 有时我们还需要构建某些 SDK 目标、例如示例、这些目标使用这些 SDK 库、然后异常中断处理程序还会包含对我们源代码的调用、然后我们需要执行入门教程、以此类推。 最简单的方法是剥离它们。

Felix、您好！

感谢您的答复。

我将把您的问题发送给我们的域名专家,请他们提供进一步的意见。 请在几个工作日内回复。

此致、

Tushar

我已将该线程提请编译器专家的注意。

请注意,美国度假期间,回复将延迟。  

感谢您的耐心。

请明白我对 SDK 知之甚少。  我认为异常中断处理程序是一组函数、它们在库的目标文件中定义  freertos.am243x.r5f.ti-arm-clang.debug.lib .  如果这种推定是错误的,那么忽略这篇文章中的所有其他内容。

假设有一个名为的库 示例 具有一个定义名为函数的目标文件 F100 .  您编写一个调用的应用程序 F100 和中的链接 示例 .  该函数 F100 、在常规应用程序源文件中提供您自己的实现。  则链接器不会引入 F100 的符号 示例 、然后使用您的。  将这种通用技术应用于您的情况是否合理？

谢谢。此致、

-George.

我想专注于...

对于第二部分、我想这也是我应该理解的工作方式。 但遗憾的是、它无法以这种方式工作。 我们只看到它对 malloc 等符号起作用、但在这里也不起作用

我深信我们需要了解为什么这不起作用。  因为在我们清楚地了解问题之前、不可能制定稳健的解决方案。  因此,现在,我建议我们忽略所有关于保留,剥离符号等的细节  我已经开始调查了。  我不相信我迄今为止所建立的理解。  我想在说任何事情之前进行更多的调查。

同时、我建议您阅读 本文 (不是来自 TI)、了解链接、库和强/弱符号之间的关系。  它开头的问题似乎与该线程无关。  但是,为了回答这个问题,作者积累的一般背景在这里也很有用。

我明天会回到你身边。

谢谢。此致、

-George.

谢谢 George

此外、为了更好地理解、我想添加、SDK 本身已经将中止处理程序链接到内部的向量。 我不确定这是否也可能是有关这个主题的问题。 它看起来是这样的：

我还将继续深入自我介绍这个 tatic lib 主题

因此我阅读了您发送的链接、这有助于更好地理解。 答中指出、要让链接器尽快知道符号、这与链接器的顺序差不多。 但它还指出、它将仅从静态库中获取所需的符号。 因此、即使我们首先放置我们的静态库、它也会看到符号、但不会无条件地将它们放入链接中、因为此时它们在任何其他位置都没有被引用。 如果我正确理解、只要我链接.o-file 就会有不同的内容。 则它会无条件地考虑这些符号。

我想这已经是答案了。 由于只在 FreeRTOS-static-library 内需要符号、因此在链接时某种程度上、链接到底部是针对该符号进行链接的 在这里、它会直接在库本身中查找这些符号。

嗯。 我想我明白基本的问题。 但我怎样才能解决这个问题呢？ 我需要传递确切的.o-file 而不是我们的静态库吗？

实际上我不想从 SDK 中删除它们、因为这样很多 SDK 构建本身就不再起作用。

此致

Felix

还不错、乔治的另一个更新

对不起这个洪水。
我需要在 FreeRTOS-library 之前管理它链接 tho .obj-files (TIABortImpl.cpp.obj)。 我现在还记得我为什么从 weak-attribute 开始、因为现在我是每个处理程序的其中一条消息：
错误：符号"Hwip_data_abort_handler_c"重新定义：首先在中定义
  "CMakeFiles/ti-implementation-mcu1_0.dir/__/___/modules/xxx/ti-sitara-
  支持包/TI_Implementation/TI_UtilityImplementation /TIABortImpl.CPP。
  obj"；在中重新定义
  "/home/heilf/xxx/sdk-build/mcu1_0/lib/freertos.am243x.r5f.ti-arm-
  clang.debug.lib "

注意、我删除了 weak-attribute 和--retain-option (reduced linking-command、删除了一些不相关的库、顺序不变)：

/home/heilf/ti/ti-cgt-armllvm_3.2.0.LTS/bin/tiarmclang
-Wl,--search_path=/home/heilf/xxx-rp1/xxx-en/sdk-build/mcu1_0/lib
-Wl,--search_path=/home/heilf/xxx-rp1/xxx-en/build/lib
-Wl,--define=PLATFORM_MANAGER_SEARCH_PATH=\"CMakeFiles/x-en.mcu1_0.dir\"
-Wl,--reread_libs
-Wl,--ram_model
-Wl,--diag_suppress=10063
-Wl,-e_vectors
-Wl,--mapfile_contents=load_addr
-Wl,-m=/home/heilf/xxx-rp1/xxx-en/build/bin/mcu1_0/xxx-en.mcu1_0.elf.map
-Wl,--xml_link_info=/home/heilf/xxx-rp1/xxx-en/build/bin/mcu1_0/xxx-en.mcu1_0.elf.xml
/home/heilf/xxx-rp1/xxx-en/config/platform/mcu1_0/linker_r5f_mcu1_0_freertos_debug.cmd
-Wl,--retain=malloc
-Wl,--retain=realloc
-Wl,--retain=calloc
-Wl,--retain=free
CMakeFiles/xxx-en.mcu1_0.dir/__/__/__/xxx_mcu1_0_xxxNGPlatformManager_main.cpp.obj
CMakeFiles/xxx-en.mcu1_0.dir/xxxNGPlatformManager.cpp.obj
CMakeFiles/ti-implementation-mcu1_0.dir/__/__/__/xxx/TI_Implementations/TI_UtilityImplementation/TIAbortImpl.cpp.obj
-o
../../../bin/mcu1_0/xxx-en.mcu1_0.elf

libencryptionkey-mcu1_0.a
libiiot-components-mcu1_0.a
libballuff-platform-utilities-mcu1_0.a
libled-components-mcu1_0.a
libpower-status-mcu1_0.a
libti-hw-support-mcu1_0.a
../../../../sdk-build/mcu1_0/lib/board.am243x.r5f.ti-arm-clang.debug.lib
../../../../sdk-build/mcu1_0/lib/drivers.am243x.r5f.ti-arm-clang.debug.lib
../../../../sdk-build/mcu1_0/lib/security.am243x.r5f.ti-arm-clang.debug.lib
../../../../sdk-build/mcu1_0/lib/freertos.am243x.r5f.ti-arm-clang.debug.lib

那么、这是如何发生的？ 是因为它已经在 SDK-library 中被引用了吗？

到目前为止、谢谢！ 这很有帮助、您为我提供了正确的浏览方向。

此致

Felix

我很高兴你指出...

错误：符号"Hwip_data_abort_handler_c"重新定义

这正是我希望返回的时间点。

这是如何发生的？

我将通过一个刻意的示例进行解释。  请耐心等待。  构建此接口需要一段时间。

下面是成为库成员的一个文件的源代码。

/* inside_lib.c */
__attribute__((section(".text.hwi")))
int il100() { return 100; }

__attribute__((section(".text.hwi")))
int il200() { return 200; }

它有两个功能。  。 __属性___ 将每个函数的代码放在同一个 输入部分中。  这在后面将成为一个关键细节。

这些命令用于构建文件并将其放入名为的库中 示例 .

% tiarmclang -c inside_lib.c
% tiarmar -r sdk.lib inside_lib.o

此处是一个源文件、表示调用中函数的应用代码 示例 .

/* main.c */
extern int il100(), il200();

int main()
{
    return il100() + il200();
}

这些命令用于构建应用程序代码、然后与之链接 示例 最后一个可执行文件 app.out .

% tiarmclang -c main.c
% tiarmclang main.o sdk.lib -o app.out -Wl,-c

假设您要提供您自己的函数实现 il100 .  有一种方法可以解决这个问题。  创建另一个应用程序源文件。

/* override.c */
int il100() { return 500; }

构建该文件、并将其链接进来。

% tiarmclang -c override.c
% tiarmclang main.o override.o sdk.lib -o app.out -Wl,-c
error: symbol "il100" redefined: first defined in "override.o"; redefined in
   "sdk.lib<inside_lib.o>"
error: errors encountered during linking; "app.out" not built
tiarmclang: error: tiarmlnk command failed with exit code 1 (use -v to see invocation)

在概念层面上、此符号重新定义了您遇到的错误。  我将通过这个刻意的示例来解释发生了什么。

链接器具有的最小控制单元是输入段。  输入段是来自一个目标文件的一段代码或数据。  链接器无法将输入段拆分为更小的段。  在这种情况下、主应用程序代码会同时调用这两者 il100 和 il200 .  的实现 il100 限制产生的 覆盖.o 、按预期。  的实现 il200 限制产生的 示例 .  更具体地说、函数 il200 输入部分 .text.hwi 、从目标文件中 insile_lib.o 是图书馆的一个成员 示例 .  是由输入段定义的唯一符号 .text.hwi ？  否  它还定义了功能 il100 .  当链接器尝试将所有这些段组合在一起时、它会发现有两种实现 il100 .  无法删除其中任何一个。  因此、发出错误诊断并且编译失败。

解决方案是什么？  应用程序提供要覆盖的代码 il100 必须覆盖在库提供的定义的输入段中定义的所有函数 il100 .  对于您不打算覆盖的函数、应用程序代码中的实现必须与库代码中的实现相匹配。  以下是源代码。

/* more_override.c */
int il100() { return 500; }
int il200() { return 200; }

这些命令用于构建和链接。

% tiarmclang -c more_override.c
% tiarmclang main.o more_override.o sdk.lib -o app.out -Wl,-c
<No diagnostics emitted>

接下来、我需要讨论如何将该解决方案从精心设计的示例扩展到您的情况。  在开始之前,我需要确保你清楚地理解一切。  如有任何问题、请随时提问。

谢谢。此致、

-George.

嗨、George、

这是一个很好的解释并且是有道理的、因为同一个段不仅仅包含异常中断处理程序。 它还具有 Hwip_irq_handler_c 和 Hwip_fiq_handler。 如果我也要超越它们,它应该会起作用,按照解释。 我想、还会出现错误消息"因为符号在重定位中命名而未剥离符号 Hwip_data_abort_handler_c "、因为这些符号是 text.hwi-input-section 的一部分、不能拆分成更小的段、因此也无法从中删除任何符号？ (不要以为这是现在的正确方式、而是为了理解)
这可能是一个通用的构建/链接器理解问题：如果库已经定义了输入段、那么该段不会定义(或者至少强烈建议您不要这样做？) 能够被操控？ 我想这也是一致性问题的原因吗？

此致

Felix

您的目标是阻止链接器引入  HwiP_armv7r_handlers_freertos.obj 一个示例  freertos.am243x.r5f.ti-arm-
  clang.debug.lib .  因此、需要了解链接器为什么仍然可以实现它。  使用相同的 tiarmnm 我之前展示了一条命令、以了解在库中的目标文件中定义了哪些函数。  您必须调用其中一个函数、但不能在您自己的应用代码中提供该函数的实现方式。

谢谢。此致、

-George.

我现在尝试了很多。

我还理解到、现在包含了我们的中止处理程序。 我是这样实现的、我还在构建过程中包含了.asm-files、用于将处理程序链接至矢量表。 我也直接像您提到的那样将这些函数之一称为、该函数也可以正常工作、但以这种方式工作似乎是无意中发现的。 但不管怎样、结果是一样的：针对处理程序的 text.hwi 段并不在链接器脚本中定义的通用 text.hwi 段中。 而是将其放在其他地方？

我们明确地将一些段(.a-libs)放入 GPMC 的范围中、因此您可以在该位置看到地址。 看起来、当使用目标文件时、它会将这些函数直接链接到任何使用其中一个函数的库中、因为它在此处进行了链接：

    xyz-mcu1_0.a
       xyt.cpp.obj                                        74284     14490     37     
       TIDebugImpl.c.obj                                  1188      51        166    
       OSTimerImplTIFREERTOS.cpp.obj                      1160      130       0      
       TIAbortImpl.cpp.obj                                1096      0         4      
       TaskImplTIFREERTOS.cpp.obj                         940       123       0      
       SemaphoreImplTIFREERTOS.cpp.obj                    756       191       0      
       EventsImplTIFREERTOS.cpp.obj                       756       163       0      
       MailboxImplTIFREERTOS.cpp.obj                      752       64        0      
       MutexImplTIFREERTOS.cpp.obj                        608       125       0      
       SignalImplTIFREERTOS.cpp.obj                       592       98        0      
       TIDeviceResetImpl.cpp.obj                          300       32        0      
       OSManagerImplTIFREERTOS.cpp.obj                    64        16        0      
       HwiP_armv7r_handlers_freertos_asm.S.obj            72        0         0      
       HwiP_armv7r_vectors_freertos_asm.S.obj             64        0         0      
       LockTaskSwitchImplTIFREERTOS.cpp.obj               64        0         0      
       LockHWInterruptsImplTIFREERTOS.cpp.obj             60        0         0      
       TISharedMemoryImpl.cpp.obj                         44        0         4      
       TimeBPImplTIFREERTOS.cpp.obj                       20        0         0      
       CpuLoadImplTIFREERTOS.cpp.obj                      8         0         0      
    +--+--------------------------------------------------+---------+---------+---------+
       Total:                                             82828     15483     211    
                                                                                     

它会除了在链接器脚本中定义的段之外、还创建一个单独的 text.hwi 段。 它现在是库的一部分。

因此我不知道如何告诉链接器、它不应将这些目标文件包含到任何库的段中、而应仅包含在链接器脚本中的指定 text.hwi-section 中。

如果这可行、我认为我们有一个解决方案！ 即使我也需要从 SDK 中复制.s-文件、但这样做似乎可以完成！

当我之前举长示例时、我没有注意任何函数分配到哪个节。  SDK 中的代码将所有这些功能放入输入节中 .text.hwi .  如果您复制了该代码、但未在源代码中更改该详细信息、则代码会执行相同的操作。  很可能链接器命令文件的 SECTIONS 指令中有一个类似于...的行

text.hwi > special_memory_range

此处说明如何创建一个名为的输出段 .text.hwi .  它由所有具有该名称的输入节组成。  在本例中、只有一个这样的输入段。  此输出段分配给了 SPECIAL_MEMORY_RANGE .  这可能是唯一的分配 SPECIAL_MEMORY_RANGE .   

如果需要同样的行为、则需要在链接器命令文件中使用类似的行。

谢谢。此致、

-George.

嗨、George、

抱歉我还错过了提供我们所用链接器脚本的示例。 我将其分解为核心：

    GROUP {
        .text.hwi: palign(8)
        .text.cache: palign(8)
    } > R5F_TCMA
    
        GROUP {
        .text.mpu: 
        {
            *(.text.mpu)
        } palign(8)
        .text.boot:
        {
            *(.text.boot)
        } palign(8)
        .text:   { } palign(8)
        .rodata: { } palign(8)
    } > MCU1_0_SRAM_TEXT
    
        GROUP {
        .stack:  {} palign(8)
        .bss:    {} palign(8)
        RUN_START(__BSS_START)
        RUN_END(__BSS_END)
        .data:   {} palign(8)
    } > MCU1_0_SPACE 
    
    GROUP {
        .locatedStack:   
        {
            -l "someLib.a"(.text)
            -l "odtherLib.a"(.text)
        }
    } > MCU1_0_PSRAM_CODE
    

我们注意到、目标库 GET 包含其链接的符号、现在在 MCU1_0_PSRAM_CODE 中创建了一个新的 text.hwi 段、而不是 TCMA 中的 text.hwi 段。 当然,我们可以这样写:

        .text.hwi: 
        {
            *(.text.hwi)
        } palign(8)

但是、使用此选项的所有当前工程都需要更改此值。

相反、我会返回到包含了 asm 文件的静态库、如下所示：

如果我了解了一切正确、那么所需的符号现在全部包含在文件夹中、以及设置矢量表的 asm 文件会引用这些符号。 之后、在链接 SDK 时、那些符号名称已经存在并已定义、因此不会考虑 SDK-library。

我明白了吗？

很难理解你的案例的所有细节,因为它有很多。  我可以说,你做的一切都是正确的。

这是一项需要考虑的建议。  为了防止混淆库中的输入段名称和您的代码、请使用不同的名称。  该库使用输入节名称 .text.hwi .  当您在代码中为同一个输入节命名时、请使用不同的内容、如 .text.myhwi .  当然、您必须在链接器命令文件中考虑到这一点。

谢谢。此致、

-George.