From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19388 invoked by alias); 6 Sep 2007 03:19:21 -0000 Received: (qmail 19379 invoked by uid 22791); 6 Sep 2007 03:19:21 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (213.8.233.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 03:19:16 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-42-47.inter.net.il [84.228.42.47]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id DNY29900 (AUTH halo1); Thu, 6 Sep 2007 06:19:12 +0300 (IDT) Date: Thu, 06 Sep 2007 06:46:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: (message from Vladimir Prus on Wed, 05 Sep 2007 22:41:38 +0400) Subject: Re: MI: "^running" issues Reply-to: Eli Zaretskii References: <200709041653.22357.ghost@cs.msu.su> <18142.15716.179444.106490@kahikatea.snap.net.nz> <200709050938.45290.ghost@cs.msu.su> 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/msg00042.txt.bz2 > From: Vladimir Prus > Date: Wed, 05 Sep 2007 22:41:38 +0400 > > > 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. That's because introduction of asynchronous execution into GDB was never finished. > What commands are actually meaningful to emit while target are > running Anything that does not need the target itself, or modifies its state. For example, "help". A less trivial example is "info break" (to see what breakpoints were already hit during execution up to now, in case your "commands" for the breakpoints continue the target). Note that I'm not actually saying these commands will work asynchronously in the current GDB, as the implementation of async execution was never finished, AFAIK. > and are those commands of big enough value to user to warrant > extensive coding? "Big enough" is in the eyes of the beholder. In principle, every command in GDB that could take a long time could run in the background, and GDB could be free to accept other commands in the meantime. So you are in effect questioning the value of multithreading. As another data point, the people who wrote the infrastructure for the async execution were two long-time and experienced GDB users and developers, and they obviously thought it was worth coding. > Can interested parties document those commands at GDB Wiki, or even > in email? The list depends on what we decide to code, so I don't think anyone can publish it now.