From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25679 invoked by alias); 8 Sep 2007 11:55:13 -0000 Received: (qmail 25669 invoked by uid 22791); 8 Sep 2007 11:55:12 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Sep 2007 11:55:07 +0000 Received: from kahikatea.snap.net.nz (4.41.255.123.static.snap.net.nz [123.255.41.4]) by viper.snap.net.nz (Postfix) with ESMTP id A115D3D9D75; Sat, 8 Sep 2007 23:55:03 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 9CF768FC6D; Sat, 8 Sep 2007 23:54:56 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18146.36234.394471.602914@kahikatea.snap.net.nz> Date: Sun, 09 Sep 2007 20:10:00 -0000 To: Vladimir Prus Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: MI: "^running" issues In-Reply-To: <200709071404.14065.ghost@cs.msu.su> References: <200709041653.22357.ghost@cs.msu.su> <18145.5117.427647.382269@kahikatea.snap.net.nz> <200709071404.14065.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 23.0.50.5 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/msg00092.txt.bz2 > > I've run Vladimir's example under GDB with my async patch and it also > > printed a ^running record and no *stopped, so perhaps ^running should > > indeed be printed later. However, the best way to get the right > > asynchronous MI output is probably to develop this code. > > Why? It seems to me that outputting "^running" only when the target is > running is completely different matter from being able to enter more > commands when the target is running. I mean more generally than when "^running" is printed, e.g. "next" returning "^done" instead of "*stopped". > I don't see why we can fix "^running" > now, so that folks who are either not interested in asynchronous mode, or > don't like to wait for it, can get right behaviour now? If there is a simple fix then it can only make sense. However, I dont think this should require removing existing async code. >... > Assuming that > > http://sourceware.org/ml/gdb-patches/2006-11/msg00225.html > http://thread.gmane.org/gmane.comp.gdb.patches/31081 > > are the most recent discussions about your patch, it does not seems like > "copied verbatim from Apple" is the problem. The problem is that is a big > patch, diffstat (without ChangeLog) gives something like: 20 files changed, 388 insertions, 25 deletions, 221 modifications > and: > > - I can't find high-level overview of what the patch is trying > to do, and how it changes gdb behaviour. While a doc patch > might be premature, some text file would be great. I've already spent a lot of time on this patch and don't plan to spend much more when there is no maintainer willing/able to review it. I'll just keep it in sync with the repository and maybe look at it more closely again if interest increases. > - There are no tests to come with the patch, which makes it > even harder to understand what are you aiming at. There's a test attached to msg00225.html listed above. Also, as I think I've said before, to run testsuite with the asynchronous event loop just put the line: set GDBFLAGS "--async" at the bottom of site.exp. at the end of site.exp for the tests. Asynchronous output from MI requires new tests but I haven't included these in the diff. > That's pretty much what I was complaining recently -- without a design > doc for async mode it's not only impossible to understand the existing > code, but it's also impossible to understand the code that you're proposing. I can't write a design doc for code that others have already written. It doesn't make it impossible to understand, just more difficult. -- Nick http://www.inet.net.nz/~nickrob