[Ovmsdev] Debugging

[Stephen Casner]

Oh, and when you are finished with exploring a crash, use the "quit"
(abbreviated "q") command to exit gdb, then it will tell you something
about abandoning the process to which you answer "y", and then the
python monitor code presents four options for re-flashing, etc.  For
me the most reliable response at that point is just to hit return
which causes the device to be rebooted, then I either try another test
at that point or use the buttons on the device to put it back into
download state.

                                                        -- Steve

On Wed, 22 Nov 2017, Stephen Casner wrote:

> On Wed, 22 Nov 2017, Geir ?yvind V?lidalo wrote:
>
> > I see some of your are talking about gdb-stub, but I have never used
> > gbd and need some help.
> > How do I debug? What options do I have?
>
> Happy to help with that.  To use the gdb-stub you change the parameter
> in menuconfig / Component Config / ESP32-specific / Panic handler
> behavior / Invoke GDBStub.
>
> When the crash occurs, you'll be presented with a "gdb>" command
> prompt.  You can find references for "gdb commands" online.  Here is
> one:  http://www.yolinux.com/TUTORIALS/GDB-Commands.html
>
> The first command I would expect you will want is "bt" which displays
> a stack backtrace telling in which function each call is made,
> including the source line number.  The frames on the stack are
> numbered; you can give the command "frame N" where N is a frame number
> to change to the context of that frame, since the lowest one might not
> be the place where things started to go wrong.
>
> When you're at the right frame, you can use the "print" command to
> look at the value of variables.  If variable foo is a pointer, you can
> say "print *foo" to display the contents of the object foo points to.
> In many cases this will be enough to figure out the problem.  I also
> use the "x" command to examine memory by address in various ways.
>
> You can also use the "list" command to see a few lines of source code
> around the point in the code referenced by that stack frame.  Usually
> I just look at my source in a separate window.
>
> When using gdb on a real computer you can set breakpoints before
> starting the program, but I have not learned whether that is possible
> to do with the ESP32.
>
> As I mentioned in one of the emails, if you are running on a Mac you
> should use the gdb binary that I made which references the newer
> libiconv library in order to avoid gdb getting stuck in an infinite
> loop.  If so, let me know and I'll send the binary and library to you.
> If you are running on a different platform, you should check to see
> what version of libiconv DLL (Windows) or shared library (Linux) is
> referenced.  On my Mac the new one is 9.0.0 vs. 7.0.0.  The old one is
> usable, but you have to be careful not to give any command that might
> result in gdb tryinging to display a variable value that has non-ASCII
> chars.
>
>                                                         -- Steve