• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 121 subscribers
  • Views 1023 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Wrong source files displayed when debugging code in ITCM

Oscar Huang

It looks like code near address zero cannot show matched source code while debugging in the DS IDE. Some functions not called at all are showed. The ITCM in my SoC starts from address 0.  I remember there is a compiler option to fix it, but don't remember what it is. Could anybody help me out here? Many thanks.

Parents
  • +1

    Hi Oscar

    My name is Stephen and I work at Arm.

    I believe the effect you are seeing is caused by "dangling" debug information.  This results in unused code apparently appearing unexpectedly around address 0x0 when debugging at source level.  This can occur with images generated by both GCC and Arm Compiler 5 & 6.  The problem is just with the debug illusion - actual code execution is unaffected.

    What is "dangling" debug information?  Linkers such as armlink and gld are able to reduce image size by removing unused code & data.  But when they do so, they might not be able to remove all the associated debug information.  The unused debug information gets left ("dangling") in the debug image.  The linker has to associate the dangling debug information with some address, and by default chooses 0x0.  This causes problems when the user is trying to debug (e.g. startup code) around 0x0, because the real debug information for code at 0x0 is now polluted with multiple unwanted debug data from removed code.

    One option is to temporarily turn off the automatic removal of unused code by the linker (e.g. "--no_remove" for armlink and "--no-gc-sections" in gld).  The side-effect of this is your overall code size will be larger.  When you are at the stage that you no longer need to debug your startup code, then you can re-enable this feature.

    armlink has a better solution, as follows:

    armlink has an option to force the dangling debug data to be associated with a different address:
    armlink --dangling_debug_address <address> [rest of cmd line]

    Typically, you’d use a high address well away from your code (but not at the very top of the address range), for example:
    armlink --dangling_debug_address 0xF0000000

    This forces any dangling debug data to be moved well away from the startup code around 0x0 that you are trying to debug.  

    This solution applies to armlink.  I don't believe GCC has an equivalent option.

    For more information, see:
    developer.arm.com/.../--dangling-debug-address-address

    Hope this helps

    Stephen

Reply
  • +1

    Hi Oscar

    My name is Stephen and I work at Arm.

    I believe the effect you are seeing is caused by "dangling" debug information.  This results in unused code apparently appearing unexpectedly around address 0x0 when debugging at source level.  This can occur with images generated by both GCC and Arm Compiler 5 & 6.  The problem is just with the debug illusion - actual code execution is unaffected.

    What is "dangling" debug information?  Linkers such as armlink and gld are able to reduce image size by removing unused code & data.  But when they do so, they might not be able to remove all the associated debug information.  The unused debug information gets left ("dangling") in the debug image.  The linker has to associate the dangling debug information with some address, and by default chooses 0x0.  This causes problems when the user is trying to debug (e.g. startup code) around 0x0, because the real debug information for code at 0x0 is now polluted with multiple unwanted debug data from removed code.

    One option is to temporarily turn off the automatic removal of unused code by the linker (e.g. "--no_remove" for armlink and "--no-gc-sections" in gld).  The side-effect of this is your overall code size will be larger.  When you are at the stage that you no longer need to debug your startup code, then you can re-enable this feature.

    armlink has a better solution, as follows:

    armlink has an option to force the dangling debug data to be associated with a different address:
    armlink --dangling_debug_address <address> [rest of cmd line]

    Typically, you’d use a high address well away from your code (but not at the very top of the address range), for example:
    armlink --dangling_debug_address 0xF0000000

    This forces any dangling debug data to be moved well away from the startup code around 0x0 that you are trying to debug.  

    This solution applies to armlink.  I don't believe GCC has an equivalent option.

    For more information, see:
    developer.arm.com/.../--dangling-debug-address-address

    Hope this helps

    Stephen

Children