esp-gdbstub: cannot step through code

[joostn]

Hi,

Many thanks espressif (and sprite_tm?) for releasing esp-gdbstub! Not sure where to post questions regarding this so I'll just try here.

I got it mostly working by following the instructions. I'm able to set the hardware breakpoint (code in flash) and I can inspect variables. Only thing which doesn't seem to work is stepping through the code. I can step manually by clearing the breakpoint and setting it to the next source line. But stepping with the 'next' command fails with message '0x40000504 in ?? ()'. See log:

Code: Select all

MacBook-Pro:wifirgbled joostn$ ../../esp8266/xtensa-lx106-elf/bin/xtensa-lx106-elf-gdb -x gdbcmds -b 115200
GNU gdb (crosstool-NG 1.20.0) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_apple-darwin14.5.0 --target=xtensa-lx106-elf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
0x4010649b in gdbstub_do_break_breakpoint_addr ()
(gdb) hb main.cpp:535
Hardware assisted breakpoint 1 at 0x4023a5d1: file user/main.cpp, line 535.
(gdb) c
Continuing.

Breakpoint 1, jnuc::Application::Run (this=this@entry=0x3fff1608) at user/main.cpp:535
535      m_TimerInterrupt.Start(1);
(gdb) bt
#0  jnuc::Application::Run (this=this@entry=0x3fff1608) at user/main.cpp:535
#1  0x4023a994 in main () at user/main.cpp:42
(gdb) d 1
(gdb) hb main.cpp:536
Hardware assisted breakpoint 2 at 0x4023a5db: file user/main.cpp, line 536.
(gdb) c
Continuing.

Breakpoint 2, jnuc::Application::Run (this=this@entry=0x3fff1608) at user/main.cpp:536
536      m_FlashStorage.LoadData(&m_ConfigData);
(gdb) bt
#0  jnuc::Application::Run (this=this@entry=0x3fff1608) at user/main.cpp:536
#1  0x4023a994 in main () at user/main.cpp:42
(gdb) n
0x40000504 in ?? ()
(gdb) bt
#0  0x40000504 in ?? ()
#1  0x4023a5db in jnuc::Application::Run (this=0x3fffc230) at user/main.cpp:535
#2  0x40104d5c in gdbPacketEnd () at ../../esp8266/esp-gdbstub/gdbstub.c:184
#3  0x401053c5 in gdbHandleCommand (cmd=cmd@entry=0x3ffef808 <cmd> "m3ffef800,8",
    len=len@entry=1) at ../../esp8266/esp-gdbstub/gdbstub.c:457
#4  0x40105492 in gdbReadCommand () at ../../esp8266/esp-gdbstub/gdbstub.c:509
#5  0x3ffea2d2 in info ()
warning:
Unrecognised function prologue. Stack trace cannot be resolved. This message will not be repeated in this session.

(gdb)


The finish command gives similar problems:

Code: Select all

(gdb) hb main.cpp:535
Hardware assisted breakpoint 1 at 0x4023a5d1: file user/main.cpp, line 535.
(gdb) c
Continuing.

Breakpoint 1, jnuc::Application::Run (this=this@entry=0x3fff1608) at user/main.cpp:535
535      m_TimerInterrupt.Start(1);
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) finish
Run till exit from #0  jnuc::Application::Run (this=this@entry=0x3fff1608)
    at user/main.cpp:535
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x4023a994: Input/output error.

(gdb)


I suspect this is because my code is in flash and gdb is trying to set a temporary software breakpoint instead of a hardware breakpoint?

[joostn]

To answer my own question: yes, stepping works fine for code in RAM.
So does that mean it is not supposed to work for code in flash?

Anyway I can put relevant sections of code to RAM for debugging, so it's no big deal.

[Freeck]

Hi there,

First of all, great news there is a gdbstub available, it saves 4 IO pins. I have used VisualGdb and a jtag-device for debugging, but it was/is far from stable.

To answer your question: It should be possible to single step through flash code, at least that was possible using jtag.
First you have to disable all breakpoints before continuing single stepping.

[joostn]

I've deleted all breakpoints before issuing the 'n' command, but the problem persists (see below).

It's strange, I've debugged ARM chips via JTAG with code running from flash, and there the 'b' command sets a hardware breakpoint. Here I have to issue the 'hb' command explicitly, otherwise it tries to set a software breakpoint.

Code: Select all

MacBook-Pro:wifirgbled joostn$ ./gdb.command
GNU gdb (crosstool-NG 1.20.0) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_apple-darwin14.5.0 --target=xtensa-lx106-elf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/joostn/GitProjects/ucprojects/projects/wifirgbled/build/app.elf...done.
Remote debugging using /dev/cu.wchusbserial1410
0x4010649b in gdbstub_do_break_breakpoint_addr ()
(gdb) hb main.cpp:535
Hardware assisted breakpoint 1 at 0x4023a5d1: file user/main.cpp, line 535.
(gdb) c
Continuing.

Breakpoint 1, jnuc::Application::Run (this=this@entry=0x3fff1618) at user/main.cpp:535
535      m_TimerInterrupt.Start(1);
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) n
0x40000504 in ?? ()
(gdb) bt
#0  0x40000504 in ?? ()
#1  0x4023a994 in main () at user/main.cpp:42
(gdb)


[Freeck]

I suppose the designers of gdbstub chose this default behaviour because the esp8266 has only one hardware breakpoint....an armprocessor has 5 hb's, so after hitting a breakpoint in ram or flash they are always able to continue single stepping using the next free hb, the esp8266 cannot...

[ESP_Sprite]

Ah, sorry, didn't spot this topic before... Yes, breakpointing flash is pretty much only possible with a hw breakpoint for now, and hw breakpoints aren't set by default because we only have one. Also, I just concluded that may also interfere with the 'next' command... hmm, I may want to change the logic of that code around a bit and/or document this. Thanks for bringing it up.

[Freeck]

Hi Sprite_tm,

Is there any progress on this subject? I also posted this issue to Sysprogs , but they refer to Espressif as being the developer of gdb-stub. I hope you will continue your efforts resolving this issue.
Thanks.