Debugging Issue: OpenOCD & GDB reporting stack level of -1, crashing Microsoft MI

[jollytopper]

Code: Select all

#-1 app_main () at /Users/zhe/esp/wifihub/main/main.c:59
Backtrace stopped: Cannot access memory at address 0x400d3bd4

I am getting the above and it seems to be confusing MI Engine. Does anyone know why the stack level would start at -1 instead of 0? Microsoft reported this may happen

if the gdb <--> gdbserver architectures are mismatched and the correct way to fix it is to make sure that the local gdb is cross compiled to support the same version of gdbserver running on the remote.

How would I go about checking that the gdbserver architectures are the same?

[ESP_igrr]

In this case, gdb server is provided by OpenOCD. If you are using xtensa GDB as the client (via MI), then it should be able to talk with OpenOCD. If you are running generic GDB (not cross GDB for Xtensa) then there certainly will be an issue. Can you trace somehow, which GDB binary is used by Microsoft debugger?

[jollytopper]

Yeah I went to look in the settings and I'm have

Code: Select all

"miDebuggerPath": "/Users/zhe/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-gdb",

in my debug config. So it seems that is not the problem.

I found that even when I start GDB on command line mode, my app_main has a stack level of -1, while the documentation screenshots shows a stack level of 0.

[ESP_igrr]

Thanks for checking, very interesting. Could you send me your application .elf and .bin files via a PM?
Also, is there anything special about the way you are building the application (new CMake build system, or something custom)?

[jollytopper]

Sent! Thanks for your help and prompt replies.

[ESP_igrr]

This issue is now fixed in the latest release, see https://github.com/espressif/openocd-esp32/releases/