- Wed May 20, 2015 11:03 pm
#18016
Your understanding is right, the gdbserver (here it would be openocd or xt-ocd) talks via JTAG to the esp8266 and via the gdb remote protocol to gdb.
You can produce gdb remote protocol logs with gdb itself:
Setting this in gdb should cause it to print every gdb protocol packet to/from the gdbserver. There's a detailed description of the remote protocol in the gdb manual.
If you're using openocd then running with the '-d' command line argument will produce a fairly detailed log of the JTAG operations at the OCD TAP level. This is a different view to the gdb commands, but you can usually infer what gdb asked for (ie if it's reading memory then gdb just asked for a memory read, or if it's reading registers then gdb is refreshing register state after a halt, etc.)
Where things can get complex from a "debugging the debugger" point of view is that openocd (or xt-ocd, although I don't know anything about it) will also cache the status of the target in various ways, because it can't query much while the target is running - only when halted. Also the ocd tool manipulates the state of registers itself in order to do things like read/write memory, but it restores the registers to the program values whenever it resumes execution. The OCD tool hides those low-level debug manipulations from gdb.
One other command worth mentioning is:
where X is a level 0-4 I think (check the help). This enables printing of the debug lines from the XTensa gdb support, which is handy if you're trying to figure out processes like stack unwinding! My debugging of openocd so far has used this feature and the '-d' output of openocd.
Angus
cal wrote:Can you do me a favor?
As far as I understand the OCD/JTAG/whatever stuff the gdb communitates with some JTAG speaking
gdbserver.
Do you have access to the logs of such a communication between gdb and gdb server from the startup to
some single stepping and continue?
I would like to clarify how some gdb stuff is used on a bare metal target.
Your understanding is right, the gdbserver (here it would be openocd or xt-ocd) talks via JTAG to the esp8266 and via the gdb remote protocol to gdb.
You can produce gdb remote protocol logs with gdb itself:
Code: Select all
set debug remote 1
Setting this in gdb should cause it to print every gdb protocol packet to/from the gdbserver. There's a detailed description of the remote protocol in the gdb manual.
If you're using openocd then running with the '-d' command line argument will produce a fairly detailed log of the JTAG operations at the OCD TAP level. This is a different view to the gdb commands, but you can usually infer what gdb asked for (ie if it's reading memory then gdb just asked for a memory read, or if it's reading registers then gdb is refreshing register state after a halt, etc.)
Where things can get complex from a "debugging the debugger" point of view is that openocd (or xt-ocd, although I don't know anything about it) will also cache the status of the target in various ways, because it can't query much while the target is running - only when halted. Also the ocd tool manipulates the state of registers itself in order to do things like read/write memory, but it restores the registers to the program values whenever it resumes execution. The OCD tool hides those low-level debug manipulations from gdb.
One other command worth mentioning is:
Code: Select all
set debug xtensa X
where X is a level 0-4 I think (check the help). This enables printing of the debug lines from the XTensa gdb support, which is handy if you're trying to figure out processes like stack unwinding! My debugging of openocd so far has used this feature and the '-d' output of openocd.
Angus
