Thanks for analyzing a possible scenario where
gdb and kgdb could go out of sync.
The gdb remote debugging protocol isn't quite safe whenever
both gdb and stub try to talk to each other. There are
a few other scenarios which occur more frequently.
Some gdb developers are trying to make the gdb
remote protocol better. Hopefully they should come up
with a protocol that does not suffer from such problems.
You can look in gdb mailing list archives from
http://sources.redhat.com/gdb/
I'll list another unsafe gdb packet on which there was
a discussion on gdb mailing list: The kgdb console output
uses "O" gdb packet which doesn't have an acknowledgement
associated with it. Since the number of console messages
can be large at times, this may cause gdb to go out of sync
when a user presses Ctrl + C. I have seen this occur,
though rarely.
Hanish Menon C wrote:
>
> Hi
>
> This patch takes care of 2 things related to remote debuging of Linux
> kernel using Gdb
>
> Problem and Solution (1)
> ------------------------
>
> When trying out Remote Debugging of Linux kernel using GDB, I found a
> possible protocol synchronisation issue between gdb (in host) and gdbstub
> (on RemoteTarget) in the current gdb remote protocol implementation (i.e
> which don't use the SequenceNumber mechanism of the protocol).
>
> The situation unfolds as follows
> 1) HostGdb sends a command to the RemoteTargetStub.
> 2) Before the RemoteTargetStub can process the command a exception or
> breakpoint occurs. Or the RemoteTargetStub is getting activated only now
> during booting of the RemoteTarget m/c.
> 3) RemoteTargetStub sends Sxx to HostGDB. HostGDB takes this as response
> to command from 1 above (or ignores the command from 1 due to this)
> 4) HostGDB sends a new gdb command.
> 5) RemoteTargetStub picks up the old gdb command (from 1), and responds
> to it.
> 6) HostGDB assumes its the response to the new command from 4 above, but
> actually its response to the old (now stale or no longer valid) command
> from 1 above.
>
> Thus the RemoteTargetGdbStub and the HostGDB go out of sync.
>
> I faced this problem when trying out remote debuging between a Linux Host
> and a PC Emulation software (vmware or so) using /dev/ptyq0 and /dev/ttyq0
> for communication. On looking into this I found this possible
> synchronisation problem between the Host and Remote in GDB protocol, if
> there is any content or old command in the Recieve buffers (s/w buffer in
> gdbserial.c and or h/w buffer of uart) due to what ever reason.
>
> To solve this problem I have implemented a clearRecieveDataBufferGDB in
> gdbserail which when invoked will clear all buffered contents associated
> with recieving ((a) the s/w buffer in gdbserial and (b) the buffer in
> uart). It uses the existing read_char implementation of gdbserial in a
> loop to accomplish this.
>
> INTURN I call this from with in handle_exception of gdbstub just before
> sending SXX signal(to notify of the exception) to HostGDB, So that
> handle_exception won't respond to any old (and no longer valid)command or
> invalid data in the Recieve buffer.
>
> Problem and Solution (2)
> ------------------------
>
> Also I noticed that HostGDB was sending a qOffsets query to the
> RemoteTargetStub, but x86 gdbstub doesn't currently provide a
> implementation for qOffset. So I implemented one which uses the following
> symbols to provide the required offsets
>
> stext for Text
> gdt_table for Data (currently corresponds to .data or sdata)
> __bss_start for Bss.
>
> However once Implemented I did find that HostGDBs symbol info was getting
> corrupted and I was forced to reload the symbols using symbol_file. On
> looking into gdb source casualy it felt as if I can ignore qOffsets
> command. Either way I already had a implementation (which is very
> simple) for qOffsets command, so I have retained it in the patch __as the
> bug__ seems to be __in the HostGDB code__. On looking into other gdbstub
> implementations in the linux kernel Even the PPC arch's gdbstub talks
> about this bug in HostGDB.
>
> Also I picked up the elegent sprintf solution to create the response
> string for qOffset from the PPC guys. Earlier I had tried a solution with
> mem2hex which retains the Bytes of the address in the Target Byte order,
> but for qOffset one requires to represent the address (in Hex) in the
> normal reading order (varified by looking into remote.c in gdb
> source) which automaticaly suites the sprintf solution.
>
> These problem seems to be universal as far as gdb remote debug protocols
> current implementations are concerned, so may be even the GDB guys need to
> be informed about these possible problems. But I am not in the GDB devel
> list, so someone on the list can inform them also.
>
> -----------
> Keep :-)
> HanishKVC
>
> ------------------------------------------------------------------------
> Name: linux-2.4.3-kgdb-hankvc-30Apr2001-p1.patch
> linux-2.4.3-kgdb-hankvc-30Apr2001-p1.patch Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
-- Amit Kale Veritas Software ( http://www.veritas.com ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:24 EST