ESP8266 Community Forum

- Wed May 06, 2015 5:21 am #16683

Hmm, backtraces are still a bit flaky especially when being called from SDK code (ie stack will be intact and a0/a1 set correctly, but 'bt' produces nonsense). It could be an openocd bug, but I think maybe the call0 function prologue analysis in gdb is misreading the prologues sometimes.

I'm pretty sure gdb for xtensa has custom logic for dealing with stack unwinding, aimed at windowed ABI. I didn't attempt to make it work for call0 and I'm not sure that gcc emits enough DWARF information for it.

- Wed May 06, 2015 5:49 am #16684

I'm pretty sure gdb for xtensa has custom logic for dealing with stack unwinding, aimed at windowed ABI. I didn't attempt to make it work for call0 and I'm not sure that gcc emits enough DWARF information for it.

It does, and it has custom unwinding logic especially for call0 as well. It scans the function prologue and tries to rebuild the call stack information from disassembly, even without debugging information.

With the bugfix linked above it seems to unwind stack reliably with gcc when using either -fno-omit-frame-pointer or -O0, it may be less reliable with optimisations on and it seems to have problems with the SDK code (I assume compiled with xt-cc and high optimisations).

There may be some more reasonably easy to fix bugs or frame analysis heuristics to add. I will keep testing and see what I find. Slow progress is at least progress!

- Wed May 20, 2015 2:53 am #17930

Found what looks like a bug in gdb when unwinding call0 stack frames. Registers in previous frames aren't read properly. This becomes really obvious if the frame pointer is on (nonsense backtraces), but probably has other effects too. Patch here. Can anyone test this or confirm it looks reasonable before I take it to the gdb maintainers?

Moin Angus,

I try to understand the gdb register handling to understand the implications of your change ...
In windowed ABI ar_base points to the start of the "real" registers and a0_base is our current "windowed" a0. Yes?
I would expect ar_base == a0__base in Call0 ABI. Yes?
So your changing of ar_base to a0_base is for idiomatic reasons: "We don't have/need ar_base so avoid it in Call0 ABI code?" Yes?

Now I just have to understand what xtensa_frame_prev_register is good for ...
@Author of that code: a short comment would have been nice

Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Wed May 20, 2015 4:14 am #17938 You have the register meanings right, at least as far as I understand the Xtensa ABIs.

The real bug is that with call0 ar_base is unused and has the uninitialised value -1. So referring to it from a call0-only routine is, I think, just a simple copy-paste bug and they meant to refer to a0.

I agree on comments. Maybe for people intimately familiar with the Xtensa ABI the stack unwinding routines make perfect sense, but a few pointers would help for the rest of us.