From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17962 invoked by alias); 11 Mar 2004 23:21:00 -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 17955 invoked from network); 11 Mar 2004 23:20:59 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 11 Mar 2004 23:20:59 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DE11F2B92; Thu, 11 Mar 2004 18:20:21 -0500 (EST) Message-ID: <4050F435.1040906@gnu.org> Date: Thu, 11 Mar 2004 23:21:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: [remote protocol] Allow qSymbol response to continue packets References: <20040306235253.GA10376@nevyn.them.org> <4050C69E.7060906@gnu.org> <20040311201632.GA26795@nevyn.them.org> <4050D9B4.7080102@gnu.org> <20040311214033.GA29430@nevyn.them.org> In-Reply-To: <20040311214033.GA29430@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00110.txt.bz2 >>>> >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 :) I quoted the relevant section of the manual as it hopefully explained why it was necessary. If that doesn't answer the question then we've a bug in the manual. >>> 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. Protocol's can't make such assumptions. > 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: - - Andrew