From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8027 invoked by alias); 1 Apr 2008 19:41:00 -0000 Received: (qmail 8018 invoked by uid 22791); 1 Apr 2008 19:40:59 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 Apr 2008 19:40:33 +0000 Received: from kahikatea.snap.net.nz (187.61.255.123.dynamic.snap.net.nz [123.255.61.187]) by viper.snap.net.nz (Postfix) with ESMTP id 1C4E13DA0B8; Wed, 2 Apr 2008 08:40:25 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 94CD88FC6D; Wed, 2 Apr 2008 07:40:23 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18418.36774.469694.449649@kahikatea.snap.net.nz> Date: Tue, 01 Apr 2008 20:09:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: linux native async mode support In-Reply-To: References: <200803140810.22883.pedro@codesourcery.com> <20080322220542.4DF038FC6D@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.92.3 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-04/txt/msg00027.txt.bz2 > > =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_prompt= " { >=20 > I don't think this is right. MI is (supposed to be) extensible. In parti= cular, new async > notification may be added. The above will break if any notification will= be emitted > between ^running and ^done and the prompt. 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 relea= sed versions of Emacs. This is a test, however, and it's purpose *is* to detect changes in Gdb output. If they are undesirable changes then it's done its = job and detected a regression. If the changes are deliberate, we update the te= st. There's no way to know, in advance, which type the change is and the danger= of making the regexp too general is that we miss a real failure. > > ... > > =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,reason= =3D\"end-stepping-range\",thread-id=3D\"0\",frame=3D\{addr=3D\"$hex\",func= =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 "Asynchro= nous 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_prompt$= " { > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0fail "Asynchro= nous 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 "Asynchro= nous 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 abstra= ct > clarify -- I've already spend hours updating the current MI testsuite for > non-stop mode. 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 like -exec-next). Not really worth a dedicated helper function do you agree? --=20 Nick http://www.inet.net.nz/~nick= rob