From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27966 invoked by alias); 11 Mar 2004 23:38: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 27959 invoked from network); 11 Mar 2004 23:38:33 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Mar 2004 23:38:33 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B1Zl3-0000BK-6t; Thu, 11 Mar 2004 18:38:33 -0500 Date: Thu, 11 Mar 2004 23:38: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: <20040311233833.GA32710@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> <20040311214033.GA29430@nevyn.them.org> <4050F435.1040906@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4050F435.1040906@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00111.txt.bz2 On Thu, Mar 11, 2004 at 06:20:21PM -0500, Andrew Cagney wrote: > Protocol's can't make such assumptions. I disagree. I consider symbol lookup a _fundamentally non-blocking_ operation, and I'm sure there are other similar fundamentally uninterruptible responses. For instance, any notification events (for things similar to tracepoints, though I don't know if it would apply to our tracepoint implementation, since the remote protocol bits of tracepoint support do not have documentation that I can find). Or a revised version of the 'console output' response that doesn't have the protocol-breaking problems you described to me the last time I tried to model something after it. > >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. > > I think we'll have to disagree on our definitions of heavy weight (if F > it is too heavy weight then perhaphs we need to remove a few things from > it). > > The protocol needs to specify the failure states, the F packet provides > that for free. As I said, I'm really not interested in cooking up > another callback packet with a different set of failure states. One is > enough. > > >>>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. > > If you've code to handle that you've code to handle a packet containing: > > - > - That's not correct, unfortunately. A packet containing , sure, that's easy. But is pretty hard. The call stack at this point goes through the middle of libthread_db; I can't resume the inferior to give it a real SIGINT without have to jump through hoops to re-initialize libthread_db after processing the SIGINT, so I would have to: - stop all other running threads, if there are any; there could be depending on what libthread_db is trying to look up - forge a stop-with-SIGINT packet - handle whatever packets GDB sends me while I'm stopped - wait for GDB to resume - cause the resume to trigger re-issue of the queued qSymbol "stop response" - repeat until this succeeds - return that result to libthread_db The long and short of it is that I'd have to duplicate or considerably modularize the packet processing, to make the main loop re-entrant, to support interruption of an otherwise non-blocking operation. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer