• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 533 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

MCU-PLUS-SDK-AM243X: freeRTOS-Flash-access blocks all lower priority-tasks in a while loop

MCU-PLUS-SDK-AM243X: LTS1.3.0 Linker-option --symbol_map does not work

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

As explained in the related question:

I used the --symbol_map option to override a library-function with our implementation, as it is stated in the manual: https://software-dl.ti.com/codegen/docs/tiarmclang/rel1_3_0_LTS/compiler_manual/linker_description/04_linker_options/symbol-management-options.html#mapping-of-symbols-symbol-map-option
"Symbol mapping allows a symbol reference to be resolved by a symbol with a different name. Symbol mapping allows functions to be overridden with alternate definitions. This feature can be used to patch in alternate implementations, which provide patches (bug fixes) or alternate functionality."

But this won't work. I also noticed that there is an open ticket at TI: https://sir.ext.ti.com/jira/browse/EXT_EP-10043

This also references to the exact same issue but the LTS-Version is different.

I tried passing the option directly as a command-line argument as well in the linker-script. It won't work. the map file does just not show our wanted mapped symbol but the original instead.

Best regards,

Felix.

  • 0
    TI__Guru**** 242325 points

    Unfortunately, I can confirm that while EXT_EP-10043 was first reported against the proprietary TI ARM compiler named armcl, it is also present in the clang based compiler from TI named tiarmclang.  I added your details to that entry, and am looking into the status.

    Thanks and regards,

    -George

  • 0
    TI__Intellectual 2560 points

    Please try the option with double quotes and see if that works for you:

    --symbol_map="foo=foo_patch"

    It appears that single quotes only work when the option is passed via the command line but double quotes work for both passing the option via the command line and in a file.
  • 0 in reply to Anna Youssefi
    TI__Intellectual 2560 points

    Also I do see now that you tried passing via the command line.  Did you pass it after the -z option to invoke the linker?

  • 0 in reply to Anna Youssefi
    TI__Intellectual 2560 points

    I'm sorry, since you are using TI Arm Clang and not the proprietary option, the -z option does not invoke the linker.  The option would be -Wl,--symbol_map=... Let me verify with the TI Arm Clang compiler as I was only testing the issue with proprietary Arm compiler.

  • 0 in reply to Anna Youssefi
    TI__Intellectual 2560 points

    I can confirm I see the same behavior with TI Arm Clang as with the proprietary Arm compiler.  Passing the option using single quotes works on the command line only whereas passing with double quotes works for both command line and files.  For passing via command line, please make sure you are passing as a linker option.  These should both work as command line options:

    -Wl,--symbol_map='Sym1=Sym2'

    -Wl,--symbol_map="Sym1=Sym2"

    Please let me know if that is not the case for you.

    Thanks,

    Anna

  • 0 in reply to Anna Youssefi
    Guru 92251 points
    Anna Youssefi said:
    Passing the option using single quotes works on the command line only whereas passing with double quotes works for both command line and files. 

    I haven't investigated myself, but was that found when running the compiler under Windows and/or Linux?

    There may be some interaction with how the Windows/Linux command line handles the quoting and what gets passed to the compiler in argv.

  • 0 in reply to Chester Gillon
    TI__Guru**** 242325 points

    We are still characterizing the issue.  

    While this is subject to change, it presently appears the best solution is to use no quotes at all.  For example: --symbol_map=old_name=new_name. 

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1130 points

    Well that seems to work for me!

    But I guess my use case does not work this way. The library is a static library (from mcu plus SDK AM243x, the board-lib) where I want to use our own implementation of Flash_norOspiWaitReady instead of the one of the SDK.

    so I tried it like this: --symbol_map=Flash_norOspiWaitReady=Flash_norOspiWaitReadyMyImpl

    But the linker tells me:

    error: symbol "Flash_norOspiWaitReady" is mapped to symbol
   "Flash_norOspiWaitReadyMyImpl"; mapped symbol cannot have definition and
   reference in the same file
   ("../../../../xx/xx/lib/board.am243x.r5f.ti-arm-clang.debug.l
   ib<flash_nor_ospi.obj>")

    I am not sure what that means. So our implementation of Flash_norOspiWaitReadyMyImpl is compiled beforehand. It has no header-file where a prototype is declared or anything, it's just the implemented function inside a c-file which is compiled and used for linking.

    Our current workaround works by changing the sdk-code and declaring the sdk-function to "weak". So the linker will then override it. But we did not want to change that much inside the SDK.

    kind regards

    Felix

  • 0 in reply to Felix Heil
    TI__Guru**** 242325 points
    Felix Heil said:
    I want to use our own implementation of Flash_norOspiWaitReady instead of the one of the SDK

    I presume the function Flash_norOspiWaitReady comes from a library in the SDK.  You don't need --symbol_map to do that.

    Instead, supply an implementation of Flash_norOspiWaitReady in the main source code of the project.  Note you give your implementation the exact same name, not a different one.  The presence of your implementation means the one in the library does not get used.  You can see it in the linker map file.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1130 points

    That's what I tried but then I got just a redefinition/already defined when linking, that's why I needed to declare the symbol weak. And instead I thought - according to the documentation of the Linker - that I can replace the function at link-time.

  • 0 in reply to Felix Heil
    TI__Guru**** 242325 points

    I'd like to focus on how this ...

    Felix Heil said:
    I got just a redefinition/already defined when linking

    ... happened.  Please put the project back into the state where this diagnostic is issued.  In your next post, show exactly how the linker is invoked, and all the system response.  Please copy-and-paste the text, and do not use a screen shot.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 92251 points
    George Mock said:
    The presence of your implementation means the one in the library does not get used.  You can see it in the linker map file.

    I think using that technique to replace one library function assumes the library was compiled with -ffunction_sections, to place each function in it's own section. If a library is compiled with -fno-function-sections and the compilation unit containing the function to be replaced has multiple functions, then you could get multiple definition errors.

    Compiling the ospi_flash_diag example from MCU-PLUS-SDK-AM243X can see there is the drivers.am243x.r5f.ti-arm-clang.debug.lib library, which from the map file has been compiled with -ffunction_sections. E.g. there is the section .text.OSPI_norFlashWaitReady providing the OSPI_norFlashWaitReady function.

    However, Felix mentioned the function Flash_norOspiWaitReady from library board.am243x.r5f.ti-arm-clang.debug.lib is causing the issue. I.e. think need to check how the board.am243x.r5f.ti-arm-clang.debug.lib library was compiled.