From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8619 invoked by alias); 3 May 2002 18:24:44 -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 8597 invoked from network); 3 May 2002 18:24:42 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 3 May 2002 18:24:42 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4D3603D70; Fri, 3 May 2002 14:24:44 -0400 (EDT) Message-ID: <3CD2D5EC.5020708@cygnus.com> Date: Fri, 03 May 2002 11:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00029.txt.bz2 > 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. 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. -- 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? Andrew