From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18044 invoked by alias); 3 May 2002 21:28:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18037 invoked from network); 3 May 2002 21:28:06 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 3 May 2002 21:28:06 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 173kax-0007H2-00; Fri, 03 May 2002 17:28:03 -0400 Date: Fri, 03 May 2002 14:28:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020503212803.GB27650@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020502022543.GA22594@nevyn.them.org> <3CD15D5A.7020308@cygnus.com> <20020502155203.GA12647@nevyn.them.org> <3CD16BC9.2010209@cygnus.com> <20020502191411.GB19130@nevyn.them.org> <3CD19DEB.2010803@cygnus.com> <20020502210908.GA25410@nevyn.them.org> <3CD2D5EC.5020708@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD2D5EC.5020708@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00033.txt.bz2 On Fri, May 03, 2002 at 02:24:44PM -0400, Andrew Cagney wrote: > >On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote: > > > >>>These are threading information packets. They are completely optional, > >>>and I believe that they are of an appropriate nature for the > >>>environments which support it; such systems generally: > > > >> > >>Optional or not, it needs to be reliable. You need to be able to run a > >>test cases 1000 times and have it pass 1000 times. > > > > > >I really do not see what is unreliable here. They're still ACKed... > > Not necessarily. > > What should happen if, at the same time as the target is creating / > sending an O packet, GDB sends a ? The protocol spec says nothing. > > I believe, to define this, one would end up specifying a new protocol. I see; the only reason this is not an issue for 'T' responses is that the break should be ignored in that case. I actually handle this correctly for TCP, if I get an interrupt while I'm expecting an ACK. I don't know how this works on serial lines. The clobbers the traffic in the other direction? > In the mean time, the existing protocol remains ``synchronous''. GDB > sends a request, the target replies. At any time either GDB, xor the > target is in control. .. sort of; see above in that GDB is already in getpkt () when these n/x packets are received. So it thinks the target is in control. Asynchronous breaks are a separate problem. > Out of interest, does the n/x packet code in gdbserver, let go of a > created thread immediatly or does it wait until it has received the ack? Right now, waits for the ACK; it was easier and I'm more concerned about running threads than new threads. It would be more correct to release the thread first, in my opinion, but that conflicts with reporting "some threads stopped" to GDB. Depends which direction we go... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer