From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5880 invoked by alias); 17 Mar 2004 16:07:58 -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 5648 invoked from network); 17 Mar 2004 16:07:55 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 17 Mar 2004 16:07:55 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 482BC2B92; Wed, 17 Mar 2004 11:07:55 -0500 (EST) Message-ID: <405877DB.3060700@gnu.org> Date: Wed, 17 Mar 2004 16:07: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> <4050F435.1040906@gnu.org> <20040311233833.GA32710@nevyn.them.org> In-Reply-To: <20040311233833.GA32710@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00157.txt.bz2 > 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. Unfortunatly, an event driven state machine is the "text book correct" way of implementing a protocol (anything less is a crock). Thats why I wrote RDA the way I did, and thats why gdb's remote code continues to need an overhaul (hopefully eventually sharing code with gdbserver). If the original author of that code had thought to read s/w telco text, your and my life today would have been a lot easier, sigh. Anyway, if F is used as the interaction model, should F also be used as the packet format? Can I suggest, for queries to GDB, 'f' be used as the packet prefix letter but use 'F' for the rest of the specification. That would give us: <- fSymbol, -> f0,0,; or -> f0,EINTR,; or -> f0,EINTR,C; I suspect that is sufficient (looking at the code I think "F" can be simplified somewhat - time permitting :-(). The other option would be to generate T00 packets - cause GDB to go through the motions but then resume it? Andrew