From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12828 invoked by alias); 7 Sep 2007 10:04:51 -0000 Received: (qmail 12820 invoked by uid 22791); 7 Sep 2007 10:04:50 -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; Fri, 07 Sep 2007 10:04:42 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ITahZ-0001YQ-HM for gdb@sources.redhat.com; Fri, 07 Sep 2007 14:04:38 +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 1ITahG-0001Xv-DM; Fri, 07 Sep 2007 14:04:18 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: MI: "^running" issues Date: Fri, 07 Sep 2007 10:59:00 -0000 User-Agent: KMail/1.9.6 Cc: Eli Zaretskii , gdb@sources.redhat.com References: <200709041653.22357.ghost@cs.msu.su> <18145.5117.427647.382269@kahikatea.snap.net.nz> In-Reply-To: <18145.5117.427647.382269@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071404.14065.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/msg00073.txt.bz2 On Friday 07 September 2007 13:03:57 Nick Roberts wrote: > > > The code related to that bug has something to do with async mode, > > > but it's pretty unclear why it should be, and how would I test > > > that my fixes don't break that async mode. > > > > Well, Nick is trying to improve on the async code, perhaps he could > > help understand the offending code and find the right fix for the > > problem you found. > > 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 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? > I could create another branch for it but I suspect that it wouldn't get looked > at. I would like to commit it to mainline after the release but Daniel doesn't > like this idea as some changes are copied verbatim from Apple. However, I've > tried to confine these changes to the "--async" option so that usual > (synchronous) operation is unchanged. 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, 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. - There are no tests to come with the patch, which makes it even harder to understand what are you aiming at. 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. - Volodya