Re: remote protocol patch

[Zoltan Filyo <zoltan dot filyo at ericsson dot com>]

Hi Daniel!

I did not fall in love with noisy lines but the real world...

I have GDB 6.5 code. I am debugging netbsd kernel with KGDB stub. Whole
stuff runs in vmware virtual machines. The KGDB eat the processor, and
the emulated serial chips does not honour this.

Imagine the situation. The GDB sends packets. Packets maybe arrived
{successfully, partially, nothing}.
Target stub have to follow instructions from GDB. Stub can do {wait a
new command, wait part of a command, refuse the packet}, but stub can
not know its response if arrived {successfully, partially, nothing}.

The KGDB stub does not handle timeouts (fact). The stub go in a state,
and waiting until an end packet character or a new packet start
character. (Maybe this is a misbehaviour.)

If the GDB does not get positive acknowledge in a period of time or gets
negative acknowledge or gets junk, then resends the previous packet. The
GDB logic is in putpkt_binary() function. The old code does not take
difference the above three case. When timeout expired three times,
putpkt_binary() returns with error code. But caller code (see {putpkg()
getpkg()} pair calls in remote.c file!) do not handle the error
condition. This causes that the GDB run into a state where never send
packet start nor packet end. See log: GDB sends packet nack infinitely
and KGDB wait packet start infinitely.

I could not find protocol definition (the requested behaviour, the state
diagrams for two sides etc.) of GDB. The exact solution will be a full,
closed protocol definition and conformance test suite for target and
remote side too. I have no enough spirit for this, sorry.

My patch causes a "better" behaviour only on the GDB side, but without
affect previous behaviour (if you want that). It takes differences
between "single send/response session"  and a "whole command resend"
case. Two parameters "max_ack_retry_count" and "max_packet_retry_count"
to be able to use regulate the GDB behaviour.
(And a better programming style, without "while(1)".)

Zoltan Filyo


On Tue, 2008-01-29 at 14:27 -0500, Daniel Jacobowitz wrote:
> On Wed, Jan 16, 2008 at 11:11:26AM +0100, ZoltÃn Filyà wrote:
> > 
> > Hi,
> > 
> > I found that the serial remote protocol runs into a deadlock when
> > the serial line is noisy. Below a gdb log fragment with original
> > code:
> 
> My strong recommendation is to not use the GDB serial protocol over a
> noisy line.  There's other problems, for instance with packets which
> have different effects when repeated.
> 
> > r +$S05#b8
> > w +$g#67
> > r <Timeout: 3 seconds>
> > w $g#67
> > r <Timeout: 3 seconds>
> > w $g#67
> > r <Timeout: 3 seconds>
> > w $g#67
> > r <Timeout: 3 seconds><Timeout: 3 seconds>
> > w -
> > r <Timeout: 3 seconds>
> > w -
> > r <Timeout: 3 seconds>
> > w -+
> > 
> > infinitely. Because the target side NetBSD kernel throws all
> > characters until get a new packet start ('$') char.
> 
> What's happened here, the four repetitions of $g#67 were all
> completely lost, and then GDB timed out?  IMO, we should treat some of
> these timeouts as fatal to the protocol conversation.
>