From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3645 invoked by alias); 30 Jan 2008 14:31:53 -0000 Received: (qmail 3627 invoked by uid 22791); 30 Jan 2008 14:31:52 -0000 X-Spam-Check-By: sourceware.org Received: from mailgw4.ericsson.se (HELO mailgw4.ericsson.se) (193.180.251.62) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jan 2008 14:31:29 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3666B219D0 for ; Wed, 30 Jan 2008 15:30:28 +0100 (CET) X-AuditID: c1b4fb3e-ab5e9bb0000007e1-00-47a08a04663a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 19EC221476 for ; Wed, 30 Jan 2008 15:30:28 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 15:30:27 +0100 Received: from mwlx285 ([159.107.197.47]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 15:30:27 +0100 Subject: Re: remote protocol patch From: Zoltan Filyo To: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 Date: Wed, 30 Jan 2008 15:17:00 -0000 Message-Id: <1201703427.7578.64.camel@mwlx285> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00795.txt.bz2 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=C3=A1n Fily=C3=B3 wrote: > >=20 > > Hi, > >=20 > > 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: >=20 > 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. >=20 > > r +$S05#b8 > > w +$g#67 > > r > > w $g#67 > > r > > w $g#67 > > r > > w $g#67 > > r > > w - > > r > > w - > > r > > w -+ > >=20 > > infinitely. Because the target side NetBSD kernel throws all > > characters until get a new packet start ('$') char. >=20 > 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. >=20