From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24129 invoked by alias); 11 Mar 2004 21:40:35 -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 24110 invoked from network); 11 Mar 2004 21:40:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Mar 2004 21:40:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B1Xur-0007jj-IT; Thu, 11 Mar 2004 16:40:33 -0500 Date: Thu, 11 Mar 2004 21:40:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [remote protocol] Allow qSymbol response to continue packets Message-ID: <20040311214033.GA29430@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20040306235253.GA10376@nevyn.them.org> <4050C69E.7060906@gnu.org> <20040311201632.GA26795@nevyn.them.org> <4050D9B4.7080102@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4050D9B4.7080102@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00109.txt.bz2 On Thu, Mar 11, 2004 at 04:27:16PM -0500, Andrew Cagney wrote: > > >>>look through the File-I/O section that discuss cntrl-c. > >>> > >>>I think something based on the existing F packet would be better. At > >>>least that way we have a situtation where the clear intent is for > >>>identical semantics. > > > > > >Could you explain why you this is necessary? > > >I'm guessing in the File I/O case this handles the user hitting C-c > >while the client is processing a request, and there is considerable > >complexity involved in reporting whether the I/O has completed. But > >using errno doesn't make any sense in the symbol lookup context and it > >seems to me easier to make GDB delay sending the C-c to the target > >until the qSymbol has been processed: > > -> c > > <- qSymbol:AAAAAAAAAAAAA > > Control-C > > -> qSymbol:AAAAAAAAAAAAA:012131312 > > -> \003 > > Here's the problem: I did read the manual when you referenced it, you don't need to paste the whole thing :) > A user trying to cntrl-c GDB while GDB is taking its time looking up a > symbol isn't theory. There needs to be an error/abort mechanism and > adopting "F" provides that. > > The alternative is to specify some sort of customized q packet semantics > - giving two callbacks and two different behaviors - I'm really not > interested in going there. Perhaps you've noticed that we have hashed minimal symbol table lookups? There is no excuse for symbol table lookups to take long enough for there to need to be an abort mechanism. This is in contrast to file I/O which can block. I don't think we need to use the heavy-weight mechanism which supports interruption for operations that don't need to be interrupted, and I can't see a reason to support interruption of this lookup. If you do, please enlighten me. Race conditions obviously need to be handled, which they will be automatically in the current code. GDB will write an \003 to the serial connection, which as I describe below, gdbserver will immediately consume and process, and then report next time it's asked to wait (i.e. when the qSymbol is done). > >That keeps the stub implementation much simpler. And the client > >implementation is easy using blocked signals. > > >Implementing something as you describe would be a bit trickier in > >gdbserver; I'd have to force-stop all threads and then fake a SIGINT > >event. > > You need to handle such race conditions anyway. > > -> c > <- qSymbol | cntrl-c -> That's a different problem, and it is already correctly handled by gdbserver. We'll write out the qSymbol, read in the Ctrl-C, signal the inferior, look again for an ACK, eventually get the ACK. Then we'd wait for and get a qSymbol reply, resume the suspended thread that made the lookup request, wait for it, and see the SIGINT we created. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer