From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14209 invoked by alias); 4 Sep 2007 12:53:37 -0000 Received: (qmail 14199 invoked by uid 22791); 4 Sep 2007 12:53:35 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Sep 2007 12:53:28 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ISXuG-0007VM-O3 for gdb@sources.redhat.com; Tue, 04 Sep 2007 16:53:25 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ISXuG-0007VI-Ek for gdb@sources.redhat.com; Tue, 04 Sep 2007 16:53:24 +0400 From: Vladimir Prus To: gdb@sources.redhat.com Subject: MI: "^running" issues Date: Tue, 04 Sep 2007 12:53:00 -0000 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709041653.22357.ghost@cs.msu.su> 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/msg00022.txt.bz2 I've just run into a somewhat nasty behaviour of gdb. Suppose if you've set 5 hardware watchpoints (on x86) and to -exec-step. The output from gdb will be: (gdb) -exec-next ^running (gdb) 34^error,msg="...." The target is not really running at this point, but not that there's no *stopped message. This is because the "^running" is in error -- it's actually output when we only start processing -exec-next. I also recall the long-standing bug that "^running" is not output for CLI commands. I really wonder if this is hard to fix? Can we just move the printing of "^running" to target_resume, to catch all cases? Alternatively, we can notice that "^running" has double duty if identifying that: - async operation has started - target has started We can make "^running" more focuses by either: - Introducing "*running" notification, that means the target is running. - Making "^running" mean that the target has started. As for async/sync commands, gdb prompt will indicate new command will be accepted. - 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. Thoughts? - Volodya