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.

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

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

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

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

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