From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29445 invoked by alias); 27 May 2008 15:55:34 -0000 Received: (qmail 29434 invoked by uid 22791); 27 May 2008 15:55:33 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 May 2008 15:55:11 +0000 Received: (qmail 18775 invoked from network); 27 May 2008 15:55:05 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 May 2008 15:55:05 -0000 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: [RFA] Implement *running. Date: Tue, 27 May 2008 19:07:00 -0000 User-Agent: KMail/1.9.9 Cc: Eli Zaretskii , gdb-patches@sources.redhat.com References: <200805011735.52447.vladimir@codesourcery.com> <20080502155719.GT29202@caradoc.them.org> <200805041837.44909.vladimir@codesourcery.com> In-Reply-To: <200805041837.44909.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805271955.04084.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00710.txt.bz2 On Sunday 04 May 2008 18:37:43 Vladimir Prus wrote: > On Friday 02 May 2008 19:57:19 Daniel Jacobowitz wrote: > > On Thu, May 01, 2008 at 04:35:52PM +0300, Vladimir Prus wrote: > > > This has no regressions in default and async modes on x86. OK? > > > > Just minor concerns. Docs - yes, I know very well that you know this > > - but making sure we see docs before the code change goes in makes > > sure that no one forgets in the crush of other patches. So, sorry, > > but expect to keep getting this reply :-) > > I've added the docs. Eli, are those OK? > > > Also, what are the expected changes in async and non-async? Will we > > start generating this for non-async and is that likely to break any > > frontend? > > The expected change than any command that resumes a target will produce > *running, in either all-stop or non-stop mode. I don't expect this > to break any frontend, as frontends are supposed to ignore things > they don't understand. > > > > > > * doc/observer.texi (target_resumed): New observer. > > > > Doc has its own changelog. > > > > > diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp > > > index 48527fd..b895020 100644 > > > --- a/gdb/testsuite/gdb.mi/mi-break.exp > > > +++ b/gdb/testsuite/gdb.mi/mi-break.exp > > > @@ -174,11 +174,11 @@ proc test_error {} { > > > # containing function call, the internal breakpoint created to handle > > > # function call would be reported, messing up MI output. > > > mi_gdb_test "-var-create V * return_1()" \ > > > - "\\^done,name=\"V\",numchild=\"0\",value=\"1\",type=\"int\"" \ > > > + ".*\\^done,name=\"V\",numchild=\"0\",value=\"1\",type=\"int\"" \ > > > "create varobj for function call" > > > > The comment suggests this test is supposed to fail if there is stray > > output... adding a leading .* is not nice. > > Right. In fact, this test no longer has to be changed. > > Here's a revised patch, OK? Dan, do you have any further comments on this patch, or it's OK to commit? - Volodya