From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19544 invoked by alias); 24 Dec 2002 06:37:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19537 invoked from network); 24 Dec 2002 06:37:37 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 24 Dec 2002 06:37:37 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id gBO6bOS20981; Tue, 24 Dec 2002 00:37:24 -0600 Date: Mon, 23 Dec 2002 22:51:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200212240637.gBO6bOS20981@duracef.shout.net> To: fnasser@redhat.com, jimb@redhat.com Subject: Re: [Jim Blandy ] RFA: Check that `Local' is not in scope when it shouldn't be Cc: ac131313@redhat.com, gdb-patches@sources.redhat.com X-SW-Source: 2002-12/txt/msg00660.txt.bz2 Regarding this patch: 2002-11-14 Jim Blandy * local.exp: Don't expect Local to be in scope in main; it's local to foobar. Check for it there, and check that it's not present in main. * local.cc (marker2): New function. (foobar): Call marker1. (main): Call marker2 instead of marker1. The first part of this patch, "Don't expect Local to be in scope in main; it's local to foobar.", is approved. I agree with your analysis and most of your solution. I don't like the second call to "runto 'marker2'", because "runto" restarts gdb needlessly. I think it's better to do: gdb_test "break marker2" ... gdb_test "continue" "Break.* marker2 ... at ..." But the test works correctly as you wrote it, and the existing code doesn't, so I approve it and someone can rewrite the second "runto" after you commit this. The second part, "... check that it's not present in main", is not approved. You wrote the KFAIL like this: # setup_kfail "gdb/825" gdb_test "ptype Local" "No symbol \"Local\" in current context.*" \ "Local out of scope (gdb/825)" There is a coding style issue here. My vision is that KFAIL's are always a response to specific known bad output from gdb, like this: send_gdb "ptype Local\n" gdb_expect { -re "No symbol \"Local in current context.\r\n$gdb_prompt $" { pass "ptype Local" } -re "... big regular expression that matches the correct declaration of Local from the wrong scope ..." { # comment here about which configurations we expect this for kfail "gdb/825" "ptype Local" } -re ".*$gdb_prompt $" { fail "ptype Local" } timeout { fail "ptype Local (timeout)" } } This way, the test can still generate FAIL if gdb starts acting in a new unknown way. The first test actually does this; it went from FAIL (gdb/483) to an unmarked FAIL, which indicated that there was a problem (which turned out to be in the test script itself). I think this issue needs some discussion and then a decision from FernandoN or AndrewC so I'd like to hold off on the second test in this patch while we resolve this. (I spent too much time on this patch because I started doing my own update of Local.exp with my style of KFAIL's everywhere. Then I decided it's better just to respond to JimB and work on an all-updated local.exp later.) Michael C