From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18291 invoked by alias); 11 Mar 2005 21:31: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 18267 invoked from network); 11 Mar 2005 21:30:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Mar 2005 21:30:56 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D9riV-0003lH-2n; Fri, 11 Mar 2005 16:30:43 -0500 Date: Fri, 11 Mar 2005 21:31:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Dave Korn , Karganov Konstantin , GDB Subject: Re: MI output command error Message-ID: <20050311213042.GA14428@nevyn.them.org> Mail-Followup-To: Nick Roberts , Dave Korn , Karganov Konstantin , GDB References: <16946.1979.617105.196894@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16946.1979.617105.196894@farnswood.snap.net.nz> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00126.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery, LLC