From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30361 invoked by alias); 31 Jan 2008 08:37:30 -0000 Received: (qmail 30336 invoked by uid 22791); 31 Jan 2008 08:37:27 -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; Thu, 31 Jan 2008 08:36:56 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3032A21707 for ; Thu, 31 Jan 2008 09:36:53 +0100 (CET) X-AuditID: c1b4fb3e-ab5e9bb0000007e1-7f-47a188a5e10c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E43F212AE for ; Thu, 31 Jan 2008 09:36:53 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 09:36:52 +0100 Received: from mwlx285 ([159.107.197.47]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 09:36:52 +0100 Subject: Re: remote protocol patch From: Zoltan Filyo To: gdb-patches@sourceware.org In-Reply-To: <20080130154538.GA17097@caradoc.them.org> References: <1201703427.7578.64.camel@mwlx285> <20080130154538.GA17097@caradoc.them.org> Content-Type: text/plain Date: Thu, 31 Jan 2008 13:44:00 -0000 Message-Id: <1201768612.10353.39.camel@mwlx285> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit 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/msg00846.txt.bz2 On Wed, 2008-01-30 at 10:45 -0500, Daniel Jacobowitz wrote: > On Wed, Jan 30, 2008 at 03:30:27PM +0100, Zoltan Filyo wrote: > > 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.) > > This does not sound right. Could you describe your original example > as seen by the KGDB stub - what text did it lose, and what text did it > receive and ignore? > The code in the netbsd 4.0 is: /usr/src/sys/kern/kgdb_stub.c, line 239, kgdb_recv(). After the kgdb_recv() read packet start step into the while statement in line 253. It is waiting here until gets a "packet end char" or the temp buffer run out of space. It seems characters generally looses in set. Many times kgdb collects "$6" or "$7" strings instead of "$g#67". The GDB before the patch gives up after 3 trying, and sends "-" characters. But at this moment program control had been leave the putpkt_binary() function. Finally netbsd uses the com_common_getc() function to read characters from the line (/usr/src/sys/dev/ic/com.c). I think this function should be improved to handle "timeout" -- in that case too when the interrupts are disabled. And a "timeout char" should be passed back as in GDB. > > 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. > > It won't help you, anyway. The protocol is not robust against a noisy > line, and modeling it more accurately will just make it clear how > broken it is if the line is noisy. > > > 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. > > I don't understand the difference between these two cases. > First case (state): the gdb waiting for an acknowledge from the peer after packet send (sub state of the next). The second case (state): GDB trying to send a packet to the peer. In this particular debug session after the patch, gdb does not giving up the packet resending, and kernel stub sooner or later get a "packet end char" or its buffer run out of space. This causes that kgdb stub leaves "collecting the packet" state and go into the "wait for packet start" state. Yes, this patch does not solve command duplication.