From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21376 invoked by alias); 27 Jun 2005 13:53:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21322 invoked by uid 22791); 27 Jun 2005 13:53:12 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 27 Jun 2005 13:53:12 +0000 Received: from farnswood.snap.net.nz (p208-tnt1.snap.net.nz [202.124.110.208]) by viper.snap.net.nz (Postfix) with ESMTP id C380854CE10; Tue, 28 Jun 2005 01:52:50 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 52C3862A99; Mon, 27 Jun 2005 14:53:53 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17088.1264.104928.522819@farnswood.snap.net.nz> Date: Mon, 27 Jun 2005 13:53:00 -0000 To: Daniel Jacobowitz Cc: Mark Kettenis , gdb@sourceware.org Subject: Re: MI-related testsuite regressions In-Reply-To: <20050627130030.GA10394@nevyn.them.org> References: <200506270815.j5R8FZO6026261@jop31.nfra.nl> <17087.60064.541364.938844@farnswood.snap.net.nz> <20050627130030.GA10394@nevyn.them.org> X-SW-Source: 2005-06/txt/msg00258.txt.bz2 Daniel Jacobowitz writes: > On Tue, Jun 28, 2005 at 12:01:36AM +1200, Nick Roberts wrote: > > > I see a fair number of new testsuite regressions: > > > > > > -PASS: gdb.mi/mi2-stack.exp: stack select same frame > > > +FAIL: gdb.mi/mi2-stack.exp: stack select same frame > > > > Yes. These are due to my changes. > > I'm going to echo Mark here. I assumed that you would not post a patch > which introduced failures in the testsuite. Its not a regression. I just removed the test from mi-stack.exp as it was no longer appropriate. I attach a patch below which also adds the test for -stack-info-frame and for "-stack-list-locals 2" (which I added in January of last year) from mi-stack.exp. I can't test them at the moment but they've just been copied so they should be OK. > > Currently the default MI interpreter *is* > > mi2, so these tests are just duplicated. It would seem sensible, and save > > effort, to have just one file (mi-stack.exp) until the MI version is bumped > > up one number. Then mi-stack.exp could be renamed mi2-stack.exp and a new > > file mi-stack.exp could be created. > > > > In reality GDB doesn't support more than one version of MI (the current > > one). As has been shown on the mailing list recently, even MI output > > from GDB 6.3 differs from MI output from GDB in CVS. > > mi2 is a released protocol; the intent is that we not make > backwards-incompatible changes to mi2-*.exp, at least not without > paying close attention to them. -i=mi sets mi_version to 3 today. > Until we're ready to declare mi3 usable, we need to continue caring > about mi2. -i=mi sets mi_version to 2 in my copy: interp_add (interp_new (INTERP_MI, NULL, mi_out_new (2), &procs)); and if (current_interp_named_p (INTERP_MI1)) deprecated_command_loop_hook = mi1_command_loop; else if (current_interp_named_p (INTERP_MI2)) deprecated_command_loop_hook = mi2_command_loop; else if (current_interp_named_p (INTERP_MI3)) deprecated_command_loop_hook = mi3_command_loop; else deprecated_command_loop_hook = mi2_command_loop; As far as I can see mi3 does nothing that mi2 doesn't do. Nick 2005-06-28 Nick Roberts * gdb.mi/mi-stack.exp (test_stack_locals_listing): Remove test for -stack-select-frame without arguments. Add test for newly implemented command -stack-info-frame. (test_stack_locals_listing): Test for case "-stack-list-locals 2". *** gdb.mi/mi2-stack.exp.~1.4.~ 2005-05-18 20:18:15.000000000 +1200 --- gdb.mi/mi2-stack.exp 2005-06-28 01:29:40.000000000 +1200 *************** *** 55,60 **** --- 55,61 ---- # -stack-list-frames # -stack-list-frames 1 1 # -stack-list-frames 1 3 + # -stack-info-frame mi_gdb_test "231-stack-list-frames" \ "231\\^done,stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",fullname=\"${fullname_syntax}${srcfile}\",line=\"$line_callee4_body\"\},frame=\{level=\"1\",addr=\"$hex\",func=\"callee3\",.*\},frame=\{level=\"2\",addr=\"$hex\",func=\"callee2\",.*\},frame=\{level=\"3\",addr=\"$hex\",func=\"callee1\",.*\},frame=\{level=\"4\",addr=\"$hex\",func=\"main\",.*\}\\\]" \ *************** *** 69,74 **** --- 70,79 ---- mi_gdb_test "234-stack-list-frames 1" \ "234\\^error,msg=\"mi_cmd_stack_list_frames: Usage.*FRAME_LOW FRAME_HIGH.*\"" \ "stack frame listing wrong" + + mi_gdb_test "235-stack-info-frame" \ + "235\\^done,frame=\{level=\"0\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",fullname=\"${fullname_syntax}${srcfile}\",line=\"$line_callee4_body\"\}" \ + "selected frame listing" } proc test_stack_args_listing {} { *************** *** 149,154 **** --- 154,160 ---- # Tests: # -stack-list-locals 0 # -stack-list-locals 1 + # -stack-list-locals 2 # -stack-list-arguments mi_gdb_test "232-stack-list-locals 0" \ *************** *** 170,175 **** --- 176,185 ---- "232\\^done,locals=\\\[\{name=\"A\",value=\"1\"\},\{name=\"B\",value=\"2\"\},\{name=\"C\",value=\"3\"\}\\\]" \ "stack locals listing 1" + mi_gdb_test "232-stack-list-locals 2" \ + "232\\^done,locals=\\\[\{name=\"A\",type=\"int\",value=\"1\"\},\{name=\"B\",type=\"int\",value=\"2\"\},\{name=\"C\",type=\"int\",value=\"3\"\}\\\]" \ + "stack locals listing 2" + mi_gdb_test "234-stack-list-locals" \ "234\\^error,msg=\"mi_cmd_stack_list_locals: Usage.*PRINT_VALUES.*\"" \ "stack locals listing wrong" *************** *** 182,197 **** "232\\^done,locals=\\\[\\\]" \ "stack locals listing for new frame" - # this should be a no-op - - mi_gdb_test "232-stack-select-frame" \ - "232\\^done" \ - "stack select same frame" - mi_gdb_test "232-stack-list-locals 1" \ "232\\^done,locals=\\\[\\\]" \ "stack locals for same frame (level 1)" - } mi_runto callee4 --- 192,200 ----