[RFC] Better intergratetion between uart and gdbstub

[slaff]

This issue is created to gather all improvements that need to be done for better intergratetion between uart and gdbstub.

At the moment when the code is compiled with gdbstub the serial output and input does not work as expected. The output is not shown and the input is discarded. The esp-arduino project has already done a great job and outlined the way to integrate both systems. See this PR.
What we need to do from our side is to integrate those and port them to Sming.

Once the integration is merged it will fix #1548.

[slaff]

@mikee47 Do you want to try and integrate the gdbstub changes into the uart code? As guideline you can use the code from esp8266/Arduino@bff3a6d.

[mikee47]

@slaff I'll give it a go!

[slaff]

@mikee47 Do you think you can start working on this so that we can merge it as part of the 3.8.0 release?

[mikee47]

@slaff Yes, I've made a start reviewing the changes and considering how best to implement them. I'll post details here once I've decided on a way forward.

[slaff]

Thanks a lot Mike! You are doing an amazing job!

[mikee47]

@slaff Thanks, trying to fix more stuff than I break :-)

Issues

So having had a play around with GDB (on Windows) these are the things I feel need to be dealt with:

• Reliablity. As reported in GDB build not working #1542 there are issues connecting reliably. Once it's connected it's OK, can reset, etc. and still works, but it seems to lose sync and then it's a pain to get back. (The cause is unclear.)
• GDB build not working #1542 Rapid continuing (and sometimes just first continue) results in app restart or gdb becoming unresponsive.
• GDB build not working #1542 Unable to break from gdb (due to disabled ctrl+c). Highly desirable so a running system can be stopped in order to set a breakpoint. The stub breaks in the serial ISR which reportedly causes undesirable interactions. (It would probably work better using the task queue so code is stopped outside of the ISR.)
• Windows. The toolkit doesn't include an xtensa-compatible version of GDB, though I did manage to source one elsewhere - http://gnutoolchains.com/esp8266/
• Serial output does not appear in gdb #1548 serial output doesn't appear. Needs update to gdbstub.
• gdbstub (not esp-gdbstub) inappropriately named #1547 gdbstub (not esp-gdbstub) inappropriately named. This lives in Sming/gdb but is not a debugger, it's an exception stack dumper. There is also Sming/system/crash_handler.c for user applications to hook exceptions. It's confusing, there's some code duplication so should all be in the same place.

Arduino update

• The (new) Arduino stub has been revised to work with an un-patched GDB application. Users would need to be aware of this since (presumably) the patched one would no longer work.
• Most of the stub is now in flash. It may no longer be necessary to have separate gdb/debug builds.
• A separate ISR selectively overrides the one in the uart driver
• The uart driver has been modified to use hook functions (implemented in gdbstub). From file comment header: When gdbstub_has_uart_isr_control() (only true in the case GDB is enabled), UART0 needs to be under the control of the GDB stub for enable/disable/irq (but speed, parity, etc. still allowable). Basically, GDB needs to make sure that UART0 is never really disabled.

Sming

Here's what I propose to implement for Sming:

1. Put all debugging-related code into the 'gdb' directory

• Remove esp-gdbstub as a third-party module and instead use the Arduino code as a starting point
• Incorporate existing stack dumper code for non-gdb debug builds
• Move uart_set_debug and related code out of the uart driver

2. Modify the GDB stub to use the uart driver instead of addressing the hardware directly

• Implement an additional 'virtual' serial port in the uart driver - Serial would use this instead of UART_0 in debug/gdb builds (though applications can override this as usual).
• Provide debug port initialisation function in uart driver for gdbstub to call, passing a table of callbacks. (This mechanism could potentially be used to customise any serial port or add other types of virtual port, with minimal overhead.)

Documentation

Slaff has a great article about debugging with GDB - time for an update?
https://blog.attachix.com/live-debugging-with-open-source-tools-programming-for-esp8266-part-4/

[mikee47]

I'm considering (and not for the first time) whether the uart driver would be better as a C++ class. I guess the question here is whether any Sming users are using the driver directly?

[slaff]

Slaff has a great article about debugging with GDB - time for an update?

Absolutely. Once we have the changes I will take care to update the article in the blog, add here a Wiki copy so that we can easily keep it up to date.

[slaff]

@mikee47 Did you have to time to work on this?

[mikee47]

@slaff I should have a PR in a day or two

[slaff]

I should have a PR in a day or two

Wow, that is going to be awesome! The new release will wait for this feature to be merged :)

[mikee47]

@slaff OK, just pushed initial commit. The last thing I did was add the make gdb part, which works OK but make gets in the way of Ctrl+C handling. We also need to sort out a way to get GDB for Windows users; I've put some instructions on how to do that but it's far from just 'working out of the box'.

UPDATE: Fixed by adding trap '' INT

[mikee47]

I've successfully modified the stub to read asynchronously from GDB console and pipe to UART2, but all the debug output gets ignored by GDB. The 'O' packets are acknowledged but discarded. Same in both Linux and Windows. If I could get GDB to open a separate console for output it might change behaviour. Any suggestions?

[slaff]

Implemented in PR #1655 which is merged in the develop branch.