[SOLVED] Top of stack - no unwinding of symbols

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Top of stack - no unwinding of symbols

    I'm experiencing the same issue documented here: forum.segger.com/index.php/Thr…nding-symbols-at-address/

    The call stack only displays the current function, and underneath shows the text:
    Top of stack - no unwinding of symbols at <address>


    Debug probe: J-Link Plus v10.1 18 - 46
    Ozone V3.28b
    Target: Xilinx Zynq7000 series (XA7Z020)

    Compiler: GreenHills GHS ARM 2020.1.4



    Please find the attached example project which can be used to replicate the issue.
    Files
    • xa7z020.zip

      (29.61 kB, downloaded 139 times, last: )
  • Hi JCP,

    Green Hills tool chain creates debug information that is proprietary and not conforming to standard formats. Green Hills also does not disclose documentation or information on that proprietary format. Therefore Ozone can only work with the fraction of debug information that is conforming, which limits the debug experience.

    Does that answer your question?

    Best regards
    -- AlexD
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Alex,

    Thanks for the reply! GreenHills does have a proprietary format, but they also support an option to export the normal DRAWF2 symbols, which is what I'm using to debug with Ozone. So far most of the functionality works, so I can set and hit breakpoints, step through the code, and view variable values. The main issue I'm having is with the call stack, and since someone else experienced the same issue while using gcc I don't know that it is solely related to GHS. If you might have a chance to check out the behavior with the example project I provided, I would appreciate it.

    Thanks,
    JCP
  • Hi JCP,

    there are two reasons for this message being displayed in Ozone:
    1. Data location of the return address is invalid.
    2. Data location of the CFA (canonical frame address) is invalid.
    Root causes may be (among others) stack corruption or lack of debug information in the ELF file.

    Could you provide info on which eval board this can be reproduced? And which steps I need to perform in order to reproduce the issue?

    Best regards
    -- AlexD
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Alex,

    I re-built the example application using gcc (arm-xilinx-eabi gcc version 4.9.2 (Sourcery CodeBench Lite 2015.05-16)) and I still see the same behavior with the call stack. Please find the updated example attached.

    Reproducing this issue is as simple as flashing the target hardware (either externally in flash, or using J-Link to write the application to RAM), and then starting a debug session. As you set breakpoints or step through the code, the call stack window will only show the function entry for the current PC location, but it will not unwind up the stack.

    As far as evaluation kit, I believe any Zynq 7020 based setup should work to reproduce the issue. For example, this one seems reasonably easy to use, and it does feature a JTAG header. Unfortunately I haven't found one which supports the 20 pin header on the J-Link plus, so a wire harness would need to be created.
    digilent.com/shop/arty-z7-zynq-7000-soc-development-board/


    This is the evaluation kit I have used before. Unfortunately it requires a custom main board for it to plug into, so I'm thinking this wouldn't work for your investigations.
    avnet.com/shop/us/products/avn…ICROZED-PRODUCTS-08282021


    My one concern with those evaluation kits is that they use different RAM and flash than the custom PCB I'm currently working with, so the example I provided might not run on them without updates. If you would be willing to look into this functionality, I might be able to arrange for our custom PCB with the proper wire harness to connect with the J-Link to be shipped to you.

    Thanks,
    JCP
    Files
    • xa7z020_gcc.zip

      (43.52 kB, downloaded 128 times, last: )
  • Hello JCP

    I used readelf --all app0.elf and found the following:

    There are no unwind sections in this file.

    So apparently your tool chain did not create unwind information. Without such information Ozone cannot do unwinding.

    I recommend persuading your tool chain to create that information, than Ozone should be able to operate as expected :)

    Best regards
    -- AlexD
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Alex,

    Thanks for the suggestion. I've tried adding the unwind section by specifying the -funwind-tables to the compiler options, and adding a .ARM.exidx section to the linker script. This appears to have worked correctly, as running readelf --all app0.elf now includes the following:

    Unwind section '.ARM.exidx' at offset 0x232f0 contains 32 entries:
    0x100508 <test_func>: 0x80b0b0b0
    Compact model index: 0
    0xb0 finish
    0xb0 finish
    0xb0 finish

    Unfortunately, I'm still seeing the same behavior in Ozone.


    Any other ideas?

    Thanks!

    JCP
    Files
  • Hi JCP,

    unfortunately we do not have the eval board you described on stock. since the application is quite simple, can you reproduce that behavior on a different evaluation board or hardware platform?

    Could you provide an Ozone log you recorded during your debug session? How to create an Ozone log is described in section 8 of the Ozone user's manual.

    Best regards
    -- AlexD
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Alex,

    Please find the attached Ozone log. I looked through it, and the part that may be interesting is:
    Invalid BP data location for function main. Falling back to SP

    I'm not sure what that might mean or how to fix it though. The stack pointer it lists in the call stack does seem correct, so it seems like it could unwind successfully.

    I have reproduced this on multiple instances of hardware, but all were using the XA7020 chip. We do use JLink + Ozone on completely different hardware platforms, and on those the call stack works correctly, so it does seem to be related to this particular chip. If you have access to any eval kits for this processor family, let me know which one and I'll check if we can test on it.

    Thanks,
    John
    Files
  • Hi JCP,

    at first glance I see


    Warning (107): The program file does not contain DWARF debug information.


    So apparently your ELF file does not contain debug information. Such debug information is required for stack unwinding.

    So could you please check if you can create an ELF file which actually contains debug information?

    Best regards
    -- AlexD
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Alex,

    My apologies, when I switched that example project over to the gcc compiler I ensured the optimization level was set to debug (-Og) but neglected to add the -g option to generate debug symbols. After adding this, the call stack does work properly in Ozone.

    That brings me back to the original problem of why this is not working with the GHS compiler. While it is able to generate DWARF2 compatible debug information, I do not think this includes the call stack. After going back and re-examining the options for generating stack unwind information, I found a note in the GreenHills documentation which states that 3rd party debuggers would need to unwind the stack through disassembling the code. Is this something that Ozone supports, or something that might be added in the future? I understand that this feature might have a small user base, so if this will not be supported then I think this thread can be closed, but I figured it was worth checking. Thank you for your help in looking into this.

    - JCP
  • Hi JCP,

    thanks for coming back to us and glad to see that you are now able to proceed in your work using Ozone.

    We are not planning to implement such a disassembly based stack unwinding feature. Providing the unwinding information as DWARF information in the ELF file is default for virtually all development tools, GHS being the rare exception. You may contact GHS support and ask for providing that information in a more standardized fashion, though.

    Best regards
    -- AlexD
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.