• State
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 61 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MCU-PLUS-SDK-AM243X: linking with tiarmclang produces error when multiple sections with the same name are placed in the linker-file

Felix Heil
Expert 1175 points
Part Number: MCU-PLUS-SDK-AM243X

Tool/software:

Hello, 

I hope the title matches the problem well. 

So our situation is that we use the mcu-plus-sdk and we want to overwrite some functions, while this works well for most of the drivers, overwriting some dpl-functions doesn't work as assumed. I had some guidance by George for the understanding of how the linker-works: MCU-PLUS-SDK-AM243X: "not stripping symbol X because it is named in a relocation" - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums
And we also fixed a problem with linking with sections when redefining your own implementations in your library but you mention both libraries - the one which contains the functions to be overriden, as well as your own, by explicitly mentioning the library which contains the sections which overwrite functions of the sdk: MCU-PLUS-SDK-AM243X: overwriting sdk-functions with own implementation not working correctly - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

While in the above-case we did overwrite the abort-handlers, now we want to overwrite some of the debug-functionality. 

So far I managed that the linke does not complain about redefined smybols, so this seems to work. This is the folder-structure of the example:

The .c-files are copied from the sdk and contain modified content, but still define all the functions that will be overwritten to be contained in one compilation unit. 

The modification also affects the sections, since we will place some of those functions in a special .text.debug-section like this (the header activates this part, just VSCode does not show it correctly):

Note that in the sdk, those functions are not placed in a section like this!

And now the important part happens which is a bit special in the linker-script.

We are placing the freertos library, which contains the symbols to be overriden, in a section:

the .text.debug-section is also placed:

If I now compile without further modifications, our .text.debug-section does not contain those symbols. in contrary, the map-file shows that the ones of the freertos-library are included:

Our library is linked in the link-command before the freertos-library. extract from the link-command:

As soon as I remove the freertos-library from the linker-script, it works and uses our copy of the file from our library:

but as soon as I add the freertos-lib again and try to add it like with the other solution:

I get this error when linking:

linker_r5f_mcu1_0_freertos_debug.cmd", line 63: error #10068-D: 
   no matching section

This doesn't make sense to me, since this section is obviously inside this library. 

It gets even more confusing, since, when I now remove the freertos-library again, it builds again as well and places our section in there with the addition of the explicit placement of the libti_hw_support-mcu1_0.a!

Why does the linksr say there is no matching section, when there even is one and it uses it? Could it be the message is just an indicator for another issue?
My guess is, since there is no .text.debug-section-attribute for the functions in the sdk, they differ in their input section to our definitions, and thus the linker would handle them differently?

What am I doing wrong here?

Edit: I tested it by removing our section-attributes and then it works with including both libraries in the linker-script. so putting those functions into a separate section, other than in the sdk, seems to be the problem. 
Unfortunately we had a reason why this was needed, but it's some time ago and I will find out. 

Is there a possibility to achieve the replacing of the sdk-library functions while at the same time, placing them in a different section than the one in the sdk?

Best regards, 

Felix

  • 0
    TI__Guru**** 249420 points

    I have a suggestion.  I am not certain it is practical, or that it resolves the problem.  But I think it is worth considering.

    Change the command the invokes the linker so that all the object files are named before all the libraries.  Name the libraries in the order that puts your functions before functions of the same name from FreeRTOS.  If you use the linker option --reread_libs, remove it.  Add the linker option --priority.  

    If that does not resolve the problem, then capture the text of the linker invocation in a text file (not a screenshot) and attach it to your next post.  

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1175 points

    Hey George, 

    ok, then this needs to be handled sometimes later. We still need to fix our linking-order for --priority, since we still use the --reread_libs option.
    I think the issue ehy we needed to put those into an extra section was, because we use the DDR-RAM and not the internal RAM. We had some issues with the initialization-timing of the RAMs and thus we needed to create extra sections which are allocated in the internal SRAM/TCM so the functions would be placed there and available early enough. I think the main-issue was a call to one of those functions inside the _mpu_init for us. 
    The more I think about it, we may even remove the freertos-library now from the linker-script, since it seems to work when we mention our library then. 
    But I need to check if this is sufficient enough. 

    Nevertheless, we NEED to fix our linking order. so thanks for this hint again and we will try to fix this as soon as possible. 

    I will come back, when I was able to verify if the solution we have now is already sufficient. 

    best regards

    Felix