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.

C29-CGT: Limitation in the management of constants created by the compiler

Part Number: C29-CGT

Hi all,

The compiler create constants like for the following scenarios:

  • jump table => located in the section ".rodata.<function name>"
  • switch table => located in the section ".rodata..Lswitch.table.<function name>"
  • string => located in the section ".rodata.str1.<an id>.1"

Customer thinks that there are some limitations related to these constants.

First, when using "#pragma clang section rodata=".rodata.<something>"" for functions, the ".rodata" created by the compiler do not use the section ".rodata.<something>". This is a huge limitation because it does not allow one to map these input sections to the proper output sections in the linker command file the same way one may do for the ".text" section.

Here is an example of a "#pragma section" for the code:

#pragma clang section text=".text.PROJ_SEC_CODE_LOCAL_CPU1" rodata=".rodata.PROJ_SEC_CODE_LOCAL_CPU1" bss=".bss.PROJ_SEC_CODE_LOCAL_CPU1" data=".data.PROJ_SEC_CODE_LOCAL_CPU1"


Second issue if the above one cannot be solved: for a table of jumps, the name of the section does not contain a keyword like ".Lswitch.table" for the switch tables or "str1" for the strings which makes the mapping of these input sections at the file level or independently of the files impossible because one has to take into account each function independently

Could you suggest workarounds to the above? Also, are there other scenarios that would exhibit the same issue on top of the 3 ones listed (jump tables, switch tables, strings)?


Best regards,
François.

  • Please see this forum thread.  It complains about the same problem on tiarmclang.  Though the complaint is limited to strings, the problem is the same for jump tables and switch tables.  Note an issue has been filed, and a workaround is described.  I hope this workaround is practical for you.

    Thanks and regards,

    -George

  • Hello Mr Mock,

    I am the customer.

    The workaround could work for string and switch table but it will definitively not work for jump table as in this case there is no keyword indicating that we are dealing with a jump table.

    Also, using this workaround is very painful as we may have hundreds of files that we would have to handle one by one.

    A goal of AUTOSAR / MemMap is to avoid that by specifying sections during the development of components and then mapping these components sections to the project sections component per component (and not file per file). In addition, using MemMap sections allows to have a generic linker script when the project sections are defined, avoid any further updates of the linker command file by the project (always a risk for issues).

    And you are talking about an issue that has been filled but

    1/ it does not cover all the use cases (and maybe there are other use cases that I did not face yet)

    2/ it has not been prioritized even though it has been created almost 2 years ago. Not really reassuring for the hope of a quick modification of the compiler to take into account the "#pragma section rodata" for all constants created by the compiler while compiling a function

    Best regards

    Ronan Danioux

  • Hello Mr Danioux,

    Thank you for your feedback. I will take this to the Compiler R&D. 


    Best regards,
    François.