While it isn’t strictly required to have a good debugger, we can get a lot done quickly with greater confidence if we have one at our disposal. Dealing with the ESP8266 is hard enough without being able to quickly and easily test hypothesis and verify things are where they should be.
I spent a good deal of time getting GDB up and running using the espressif gdbstub, and the result really paid off when I was implementing rboot into our project. The ability to poke and prod on live hardware was worth the time it took to get up and running.
Ryan is used to debugging from eclipse, so I wanted to make sure that worked. Unfortunately, that ended up being quite an ordeal. Despite having a huge variety of GDB options, each one always ended in some dead end. I’ll outline what worked, but there are definitely caveats.
I’ve tested with a variety of different eclipse versions, but for this document, I’ll stick with the eclipse 4.7 (“oxygen”). Install CDT, and make sure you've got the gdb-related plugins installed.
Depending on how you've configurated gdbstub, your application will have been suspended early in its startup process waiting for the debugger to be attached. It'll start inside the gdbstub-entry code that is written in ASM - stepping forward to the end of the routine will bring you back to your code and you can start debugging from there.
There are times where things don't quite work the way I'd like, and I'm not sure why. For instance, most of the time breakpoints work as expected, but in some cases they don't. The memory inspector doesn't work, it displays all 0xff. Occasionally gdb itself will segfault out. If you find further work arounds or have tips and tricks, send me an email at email@example.com and I'll expand this document.