GDB build not working

[riban-bw]

Using libsming complied with ENABLE_GDB is failing with wdt reset on Windows 7 using cygwin32.

[Vinimuller]

Same error on Ubuntu

[riban-bw]

I observe that Makefile-rboot.mk has uses $(THIRD_PARTY_DIR)/gdbstub which does not exist. There is $SMING_HOME/third-party/esp-gdbstub and $SMING_HOME/gdb.

Changing Makefile-rboot.mk to use $(THIRD_PARTY_DIR)/esp-gdbstub does not help on cygwin.

[slaff]

$(THIRD_PARTY_DIR)/gdbstub which does not exist

That is probably a bug. When I have time I will take a look at it.

[riban-bw]

Basic_Debug example fails to run because HardwareTimer fails (I will investigate and report as separate issue if required.) Changing the example to use Timer allows me to build and run the example successfully if I disable GDB.
Changing Makefile-rboot.mk to use either esp-gdbstub or gdb and comiling sample with ENABLE_GDB=1 still runs if used with a non GDB enabled libsming.
Compiling libsming with ENABLE_GDB=1 results in all samples failing after rBoot has loaded their image, i.e. I see the rBoot prompts but then the app stops, e.g.

load 0x40100000, len 1344, room 16
tail 0
chksum 0x9c
load 0x3ffe8000, len 660, room 8
tail 12
chksum 0xbd
csum 0xbd

rBoot v1.4.2 - [email protected]
Flash Size:   32 Mbit
Flash Mode:   QIO
Flash Speed:  40 MHz
rBoot Option: Big flash

Booting rom 0.
��␃�␒�o�s��N|�␌l␄lll ␂��r�l��␅�␂��j
rf[113] : 00
rf[114] : 01

SDK ver: 2.0.0(5a875ba) compiled @ Aug  9 2016 15:12:27
phy ver: 1055, pp ver: 10.2


 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

Attempts to connect GDB via serial all fail.
It looks like a non-release libsming will include the gdb stuff (which looks like simplified esp-gdbstub) and non-release libsming with ENABLE_GDB=1 inculdes esp-gdbstub. The current Makefile-rboot.mk looks like it attempts to do similar but fails with ENABLE_GDB=1 due to issue described in previous post.
My inference is that there should be some level of gdb support even without ENABLE_GDB=1 but I haven't figured out exactly how this all works.

I am struggling to get anything more than the simplest of samples running reliably and hence want gdb working to allow me to figure out what is going wrong and help to improve the framework. Getting gdb working would be a very useful tool to assist with improving Sming.

[slaff]

is failing with wdt reset

I have fixed the compilation, in PR #1544, but also hit the WDT reset issue that you have stumbled upon.
As a bonus I can see a bit more information about the SDK version and the phy version. For example the following showed:

SDK ver: 1.5.4(baaeaebb) compiled @ May 17 2016 19:23:54
phy ver: 972, pp ver: 10.1

But why the WDT is happening will require time and investigation which I don't have at the moment, but others are free to analyze and fix.

Getting gdb working would be a very useful tool to assist with improving Sming.

The esp-gdbstub is very unrelyable software. A much better way to debug is to have the code compiled under Linux or Windows and use the debugger there. That is what I am having locally to debug the TCP stack and network related issues.

[slaff]

Hm.. I was able to progress a bit (by accident).

1. Open a terminal to connect to the device
   python -m serial.tools.miniterm /dev/ttyUSB0 115600

2. Once the session is established press Ctrl-C. At least on my test setup I saw the following printed:

$T02#b6

3. Close the terminal session and try to connect to the device with xtensa-gdb. Here are the commands:

xtensa-lx106-elf-gdb -b 115200
# and then in GDB type
file out/build/app_0.out
set remote hardware-breakpoint-limit 1
set remote hardware-watchpoint-limit 1
set debug xtensa 4
target remote /dev/ttyUSB0

After the last command GDB will try to connect to the device. On success you should see something like:

Remote debugging using /dev/ttyUSB0
(trace) xtensa_unwind_pc (next_frame = 0x2041c30)
(info ) [xtensa_unwind_pc] pc = 0x4000bd9c
(trace) xtensa_alloc_frame_cache ()
0x4000bd9c in ?? ()

Just to be sure where the execution has stopped you can type (in GDB)
l #this is lower case L

On my device I get the following response

(gdb) l
1	//////////////////////////////////////////////////
2	// rBoot open source boot loader for ESP8266.
3	// Copyright 2015 Richard A Burton
4	// [email protected]
5	// See license.txt for license terms.
6	//////////////////////////////////////////////////
7	
8	#ifdef RBOOT_INTEGRATION
9	#include <rboot-integration.h>
10	#endif

Which is good.
Now set the breakpoint to init function

break init

And try to run the bootloader AND the application

(gdb) continue
Continuing.
(trace) xtensa_breakpoint_from_pc (pc = 0x401059d8)
(trace) xtensa_breakpoint_from_pc (pc = 0x401059d8)

At that moment, at least for me, the debugging breaks.... Yeah... :(

[riban-bw]

I am using PR #1544 and can now see what you are seeing using the ctrl+c trick.

A much better way to debug is to have the code compiled under Linux or Windows and use the debugger there.

I don't understand what you suggest. Are you using the host machine to run the code or are you still running it on the target ESP8266 module? What I need to do is figure out why the ESP8266 fails to run almost everything I write (well, anything that does anything useful) which is why I want to get debug working.
Thanks for the tip. At least I can now get gdb to connect to the device. It is a start....

[riban-bw]

Defining

GDBSTUB_CTRLC_BREAK 0

allows the application to flow through to the first breakpoint (within gdbstub_init due to GDBSTUB_BREAK_ON_INIT 1). You can then set a breakpoint in app init, e.g.

b init

then continue. GDB will then continue until the init breakpoint. Can then step forward with 'n'.
Setting a breakpoint at "blink" fails though. Yet to figure that out but I do have a working gdb now!

This may be because GDBSTUB_CTRLC_BREAK adds a uart hook which upsets Sming. More investigation required but there is a way to get gdb (pretty much) working. :-)

[slaff]

allows the application to flow through to the first breakpoint

Wonderful! @riban-bw Thanks for finding this out. I can debug again Live from the device in Eclipse :).

The fixes will arrive soon and the PR will be merged once the CI system approves it.

[riban-bw]

This still isn't fully working. gdb will break before running user_init and then step through init but then fails after leaving init. It seems to get to the first blink timer callback then resets. I have only once been able to step through the timer callback but don't know how I managed to get there. Possibly related to gdbstub waiting for input or interrupt whilst interrupts are disabled and gdb not sending any data (because it is waiting for input).

[riban-bw]

It seems that gdb debugging is unreliable if performed too quickly. I am now able to add setpoints to timer callback which mostly works but if I press 'c ' too quickly (like more than once per second) then gdb does not show then next breakpoint or the app crashes / restarts. Also, now that we have disabled ctrl+c there is no way to recover from a "continue" with no more breakpoints, i.e. the app just runs and gdb becomes unresponsive, requiring forced stop (kill -9). I guess we have two or three issues here which maybe should be reported as separate tickets???

1. Rapid continuing (and sometimes just first continue) results in app restart.
2. Rapid continuing (and sometimes just first continue) results in gdb becoming unresponsive.
3. Unable to break from gdb (due to disable ctrl+c)

[slaff]

Fixed with the merge of PR #1655.