From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14242 invoked by alias); 10 Mar 2005 17:44: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 13521 invoked from network); 10 Mar 2005 17:44:06 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 10 Mar 2005 17:44:06 -0000 Received: from white ([68.9.64.121]) by lakermmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050310174405.NQPZ2476.lakermmtao12.cox.net@white>; Thu, 10 Mar 2005 12:44:05 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D9Rhg-0003nS-00; Thu, 10 Mar 2005 12:44:08 -0500 Date: Thu, 10 Mar 2005 17:44:00 -0000 From: Bob Rossi To: Dave Korn , 'Karganov Konstantin' , 'GDB' Subject: Re: MI output command error Message-ID: <20050310174408.GE14061@white> Mail-Followup-To: Dave Korn , 'Karganov Konstantin' , 'GDB' References: <20050310144013.GB14061@white> <20050310160852.GC14061@white> <20050310161309.GA14175@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310161309.GA14175@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00116.txt.bz2 On Thu, Mar 10, 2005 at 11:13:09AM -0500, Daniel Jacobowitz wrote: > On Thu, Mar 10, 2005 at 11:08:52AM -0500, 'Bob Rossi' wrote: > > > > That's why I think the output > > > > > > > > (gdb) > > > > 444-exec-continue > > > > 444*running > > > > 444*stopped... > > > > (gdb) > > > > > > > > is better. > > > > > > Well, you're wrong. "running" is the output from the exec-continue > > > command and it is synchronous: the exec-continue command executes, starts up > > > the inferior, prints out "running", and is then complete. At that point the > > > inferior is running, but regardless of that, gdb is ready to take more > > > commands and so should prompt you. > > > > It is? It is still busy executing the inferior. I was under the > > impression GDB was somehow "busy" while executing the inferior. Is this > > not true? > > Not necessarily; some targets are asynhronous. Hi Daniel, The whole idea of GDB being asyncronous is new to me. Up until now, I have been very content thinking that GDB would become "busy" whenver the inferior was started up to do some work. I would really like to understand the concept and the reason why GDB had to have the asyncronous feature. While looking for documentation on GDB being asyncronous, I've only found very little. A grep of gdb.texino yeilded me nothing interesting. I noticed that the command line option is not documented in the manual. Which made me think it didn't exist. However, when I run gdb --help, it's there. gdb --help --[no]async Enable (disable) asynchronous version of CLI When I try to use the option, it fails, $ gdb --async ./main gdb: unrecognized option `--async' Use `gdb --help' for a complete list of options. $ gdb --noasync ./main gdb: unrecognized option `--noasync' Use `gdb --help' for a complete list of options. Am I doing something wrong? Thanks, Bob Rossi