From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24036 invoked by alias); 11 Mar 2005 21:36:33 -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 23997 invoked from network); 11 Mar 2005 21:36:29 -0000 Received: from unknown (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org with SMTP; 11 Mar 2005 21:36:29 -0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050311213625.NWQR18351.lakermmtao08.cox.net@white>; Fri, 11 Mar 2005 16:36:25 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D9ro3-0004Sw-00; Fri, 11 Mar 2005 16:36:27 -0500 Date: Fri, 11 Mar 2005 21:36:00 -0000 From: Bob Rossi To: Nick Roberts , Dave Korn , Karganov Konstantin , GDB Subject: Re: MI output command error Message-ID: <20050311213627.GA16933@white> Mail-Followup-To: Nick Roberts , Dave Korn , Karganov Konstantin , GDB References: <16946.1979.617105.196894@farnswood.snap.net.nz> <20050311213042.GA14428@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050311213042.GA14428@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00127.txt.bz2 On Fri, Mar 11, 2005 at 04:30:43PM -0500, Daniel Jacobowitz wrote: > On Sat, Mar 12, 2005 at 10:03:55AM +1300, Nick Roberts wrote: > > > > > I'm as mystified as Dave as to how you could read the manual and > > > believe GDB/MI was designed to operate synchronously. A number of MI > > > commands have documentation that begins with "Asynchronous command." In > > > particular, look at -exec-interrupt, which makes no sense as a > > > synchronous command. > > > > I think the problem that people like Bob and myself have with this, is that > > when GDB is compiled out of the box, it doesn't operate asynchronously. So > > if we run GDB using MI, -exec-interrupt *doesn't* interrupt the inferior: > > ... > > ^done > > (gdb) > > 111-exec-continue > > 111^running > > (gdb) > > 222-exec-interrupt > > > > Dave Korn's explanation is very helpful. Considering the MI output to be > > asynchronous, makes it much easier to understand. The fact remains, however, > > that for native targets at least (the most common configuration?), operation > > is synchronous. It leads me to wonder how this discrepancy arises. > > Lack of implementation. No one's done the work. So currently, is it best to realize that the MI protocol is asynchronous, but to treat GDB as if it's executing syncronously? Basically, send commands to GDB as if the MI interface was synchronous? Bob Rossi