• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 2448 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.

ARM compiler v5.1.5 generates incorrect address in debug information for static functions declared inside a function

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: TM4C123GH6PM

The attached example project 7558.TI_ARM_static_variables.zip was created in CCS 6.0.0.00175 using the TI ARM compiler v5.1.5, targetting a TM4C123GH6PM. The following screen show shows that the CCS debugger is showing the incorrect values for variable f_token2 and f_token3:

The summary of the problem is:

1) The running code produces the expected results, in that the CIO console output reports the correct values for all 6 variables g_token1, g_token2, g_token3, f_token1, f_token2 and f_token3

2) The CCS expressions view reports the correct values for the g_token1, g_token2, g_token3 and f_token1 variables and reports that the variables have an address in RAM.

3) The CCS expression view reports incorrect values for the f_token2 and f_token3 variables, and also reports that the variables have an address in flash. The resolved address of these variables is the address of main function in which they are declared.

If the armofd.exe -g program is run on the TI_ARM_static_variables.out executable generated the TI ARM v5.1.5 compiler the debug information reports the address of the g_token1, g_token2, g_token3 and f_token1 variables in RAM:

    00002732   2    DW_TAG_variable (.data)
    00002733           DW_AT_location       DW_OP_addr 0x200007dc
    00002739           DW_AT_name           g_token1
    00002742           DW_AT_decl_column    17
    00002743           DW_AT_decl_file      1
    00002744           DW_AT_decl_line      8
    00002745           DW_AT_type           .debug_info(12) + 0x17bd
    00002749           DW_AT_TI_symbol_name g_token1
    00002606   7    DW_TAG_variable (.bss)
    00002607           DW_AT_location       DW_OP_addr 0x200009cc
    0000260d           DW_AT_name           g_token2
    00002616           DW_AT_decl_column    17
    00002617           DW_AT_decl_file      2
    00002618           DW_AT_decl_line      9
    00002619           DW_AT_type           .debug_info(12) + 0x17bd
    0000261d           DW_AT_TI_symbol_name g_token2
    00002626   8    DW_TAG_variable (.bss)
    00002627           DW_AT_location       DW_OP_addr 0x200009d0
    0000262d           DW_AT_name           g_token3
    00002636           DW_AT_decl_column    26
    00002637           DW_AT_decl_file      2
    00002638           DW_AT_decl_line      10
    00002639           DW_AT_type           .debug_info(12) + 0x25f6
    0000263d           DW_AT_TI_symbol_name g_token3
    00001b3c   3       DW_TAG_variable (.data)
    00001b3d              DW_AT_location       DW_OP_addr 0x200007e0
    00001b43              DW_AT_name           f_token1
    00001b4c              DW_AT_type           .debug_info(12) + 0x17bd
    00001b50              DW_AT_TI_symbol_name f_token1$1

Whereas the debug information for the  f_token2 and f_token3 reports their address in flash:

    00001b5b   3       DW_TAG_variable (.text)
    00001b5c              DW_AT_location       DW_OP_addr 0x00002488
    00001b62              DW_AT_name           f_token2
    00001b6b              DW_AT_type           .debug_info(12) + 0x17bd
    00001b6f              DW_AT_TI_symbol_name f_token2$2
    00001b7a   3       DW_TAG_variable (.text)
    00001b7b              DW_AT_location       DW_OP_addr 0x00002488
    00001b81              DW_AT_name           f_token3
    00001b8a              DW_AT_type           .debug_info(12) + 0x25f6
    00001b8e              DW_AT_TI_symbol_name f_token3$3

Therefore, the problem appears to be that the TI ARM v5.1.5 compiler is generating incorrect debug information for some static variables declared inside a function.

  • 0
    Guru 92251 points

    Chester Gillon said:
    Therefore, the problem appears to be that the TI ARM v5.1.5 compiler is generating incorrect debug information for some static variables declared inside a function.

    Tried the same example using the TI ARM v5.0.8 compiler, and then the CCS displayed the correct values and addresses of all the static variables.

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

    Thank you for bringing this to our attention.  I can reproduce your problem results.  I filed SDSCM00050075 in the SDOWP system to have this investigated.  Feel free to follow it with the SDOWP link below in my signature.

    A workaround is to build with --common=off.  This is disables a new feature of the compiler where all uninitialized global and static variables become common symbols.  The Dwarf information for the function level static common symbols is where the problem occurs.  Disabling all common symbols is a bit of overkill, but it is still the best workaround.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 92251 points

    George Mock said:
    A workaround is to build with --common=off.  This is disables a new feature of the compiler where all uninitialized global and static variables become common symbols.  The Dwarf information for the function level static common symbols is where the problem occurs.  Disabling all common symbols is a bit of overkill, but it is still the best workaround.

    Changed the example to compile with the --common=off using the TI ARM v5.1.5 compiler, and confirm that output from armofd -g now shows all the variables with an address in RAM.

    [don't have a Tiva launchpad at hand to try debugging it, but based upon the output from armofd now expect the CCS debugger to show the correct information]

  • 0 in reply to George Mock
    Guru 92251 points

    George Mock said:
    I filed SDSCM00050075 in the SDOWP system to have this investigated.  Feel free to follow it with the SDOWP link below in my signature.

    A workaround is to build with --common=off.

    SDSCM00049324 was raised on a similar problem found with the MSP430 v4.2.3 compiler - based upon the thread CCS 5.5 debugger shows incorrect address for C++ class given static storage allocation in main. I have just checked with the test case for which SDSCM00049324 was raised and:

    - With MSP430 compiler v4.3.1 the problem still occurred

    - With MSP430 compiler v4.3.1 building with --common=off the CCS debugger then showed the correct values of the variables.

    Therefore, is it worth adding adding the following workaround to SDSCM00049324:

    Build with --common=off

    All uninitialized global and static variables are defined with the new common method. The dwarf information for global common variables and file level static common variables is fine. The dwarf information for function level static common variables has a problem. There is no method for disabling common variables just for function level static variables. Disabling common altogether is the best that can be done.

     

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

    Chester Gillon said:
    is it worth adding adding the following workaround to SDSCM00049324

    I added it.  Thanks for letting us know.

    -George