From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25575 invoked by alias); 5 Sep 2007 18:42:02 -0000 Received: (qmail 25564 invoked by uid 22791); 5 Sep 2007 18:42:01 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Sep 2007 18:41:49 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ISzot-0006gH-68 for gdb@sources.redhat.com; Wed, 05 Sep 2007 20:41:43 +0200 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2007 20:41:43 +0200 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2007 20:41:43 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI: "^running" issues Date: Wed, 05 Sep 2007 18:42:00 -0000 Message-ID: References: <200709041653.22357.ghost@cs.msu.su> <18142.15716.179444.106490@kahikatea.snap.net.nz> <200709050938.45290.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00037.txt.bz2 Eli Zaretskii wrote: >> From: Vladimir Prus >> Date: Wed, 5 Sep 2007 09:38:45 +0400 >> Cc: gdb@sources.redhat.com >> >> > > - Killing the idea of async commands. It does not seem to be very >> > > useful >> > > at this point, so we might be better off ripping it and implementing >> > > afresh later, when it's understood what they should be. >> > >> > I'm working in the opposite direction: trying to get GDB to work >> > asynchronously. I don't see the point of ripping out what is already >> > there. >> >> Then, can you please provide a specification of what "asynchronously" >> means, and why it's good for users and frontends? > > Asynchronous execution means that some GDB commands can be run while > GDB waits for the target to stop. It is good for users because you > can do something useful while you wait for the target to stop. Unfortunately, I never saw more concrete details. What commands are actually meaningful to emit while target are running and are those commands of big enough value to user to warrant extensive coding? Can interested parties document those commands at GDB Wiki, or even in email? - Volodya