From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25892 invoked by alias); 4 Apr 2008 11:47:32 -0000 Received: (qmail 25879 invoked by uid 22791); 4 Apr 2008 11:47:31 -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, 04 Apr 2008 11:47:14 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1JhkNs-000741-Ka for gdb-patches@sources.redhat.com; Fri, 04 Apr 2008 15:47:07 +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_SHA1:32) (Exim 4.63) (envelope-from ) id 1JhkNb-00073b-8W; Fri, 04 Apr 2008 15:46:48 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: linux native async mode support Date: Fri, 04 Apr 2008 12:34:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200803140810.22883.pedro@codesourcery.com> <18418.36774.469694.449649@kahikatea.snap.net.nz> In-Reply-To: <18418.36774.469694.449649@kahikatea.snap.net.nz> Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200804041546.41673.ghost@cs.msu.su> 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-04/txt/msg00094.txt.bz2 On Tuesday 01 April 2008 23:40:22 you wrote: > > > =A0 =A0 send_gdb "start\n" > > > =A0 =A0 gdb_expect { > > > =A0=A0=A0=A0=A0=A0=A0=A0-re ".*\\^running\r\n\\^done\r\n$mi_gdb_prom= pt" { > >=20 > > I don't think this is right. MI is (supposed to be) extensible. In par= ticular, new async > > notification may be added. The above will break if any notification wi= ll be emitted > > between ^running and ^done and the prompt. >=20 > I try to make Emacs (the frontend) as tolerant as possible to changes in = MI > output, in the hope that future changes, e.g., new fields don't break rel= eased > versions of Emacs. This is a test, however, and it's purpose *is* to det= ect > changes in Gdb output. If they are undesirable changes then it's done it= s job > and detected a regression. By definition, MI is extensible, and a test for feature X should only fail = if feature X got broken, not when new fields or notification are added by feature Y. W= e already had "but how can we update all MI testsuite for new field" discussions here. > If the changes are deliberate, we update the test.=20 > There's no way to know, in advance, which type the change is and the dang= er of > making the regexp too general is that we miss a real failure. >=20 > > > ... > > > =A0 =A0 send_gdb "next\n" > > > =A0 =A0 gdb_expect { > > > =A0=A0=A0=A0=A0=A0=A0=A0-re "\\^running\r\n\\^done\r\n$mi_gdb_prompt= " { > > > =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0gdb_expect { > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-re "\\*stopped,reas= on=3D\"end-stepping-range\",thread-id=3D\"0\",frame=3D\{addr=3D\"$hex\",fun= c=3D\"main\",args=3D\\\[\\\],file=3D\".*basics.c\",line=3D\"$line_main_next= \"\}\r\n$mi_gdb_prompt$" > > { > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0pass "Asynch= ronous response after next command" > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0} > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-re ".*$mi_gdb_promp= t$" { > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0fail "Asynch= ronous response after next command (2)" > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0} > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0timeout { > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0fail "Asynch= ronous response after next command (timeout 2)" > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0} > > > =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0} > > > =A0=A0=A0=A0=A0=A0=A0=A0} > >=20 > > It appears there's a lot of duplicated logic above. Can we please have > > factor it out into a helper function? This is not for the sake of abst= ract > > clarify -- I've already spend hours updating the current MI testsuite = for > > non-stop mode. >=20 > The helper functions that you have written for common sequences are a good > idea as they need only be updated in one place but the three here are the > only ones of their kind (they output an extra "^done" over MI commands li= ke > -exec-next). Not really worth a dedicated helper function do you agree? Why there's extra "^done"? Presently, each command is supposed to have either "^running" or "^done", not both. I realize that fixing this requires introducing "*running", so that we still know that the target is resumed. I have the patch for *running basically done, so I suggest that I submit it, and then we'll have just ^done in this example. BTW, I'm not even sure that "^done" vs. "^running" + "^done" is so big difference that a helper function cannot be introduced. - Volodya