From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16780 invoked by alias); 2 May 2008 15:57:42 -0000 Received: (qmail 16769 invoked by uid 22791); 2 May 2008 15:57:41 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 May 2008 15:57:21 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 6BE91983EC; Fri, 2 May 2008 15:57:20 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 43CE3983D6; Fri, 2 May 2008 15:57:20 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JrxdP-0001f1-6y; Fri, 02 May 2008 11:57:19 -0400 Date: Fri, 02 May 2008 15:59:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Implement *running. Message-ID: <20080502155719.GT29202@caradoc.them.org> Mail-Followup-To: Vladimir Prus , gdb-patches@sources.redhat.com References: <200805011735.52447.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805011735.52447.vladimir@codesourcery.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes 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/msg00098.txt.bz2 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 :-) 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? > * 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. > + /* We try not to notify the observer is not is not -> if no. -- Daniel Jacobowitz CodeSourcery