From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5583 invoked by alias); 30 Dec 2002 15:46:55 -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 5564 invoked from network); 30 Dec 2002 15:46:54 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 30 Dec 2002 15:46:54 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18T40R-0003EO-00 for ; Mon, 30 Dec 2002 11:47:15 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18T27l-0008LW-00 for ; Mon, 30 Dec 2002 10:46:41 -0500 Date: Mon, 30 Dec 2002 08:05:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFC: gdb.c++/main-falloff.exp (a new KFAIL) Message-ID: <20021230154641.GA23984@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200212300612.gBU6Cro28859@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212300612.gBU6Cro28859@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00755.txt.bz2 On Mon, Dec 30, 2002 at 12:12:53AM -0600, Michael Elizabeth Chastain wrote: > This is an RFC for main-falloff.exp, a new test script with a single > KFAIL. > > This script tests a C++ main() function which has return type int but does > not return a value. I don't like it, but this is legal C++. I noticed > this happening with anon-union.exp on 2002-12-18. anon-union.exp is > exposing another gcc bug so I am writing a separate test just for the > the fall-off-main behavior. > > I'd like to get comments on the KFAIL aspect. main-falloff.exp has just > one useful test, which currently KFAIL's with gcc HEAD%20021224 -gdwarf-2. > I have written the KFAIL code the way that I would like to use KFAIL. > > . Is this an acceptable way to use KFAIL? > . Is this a good way to use KFAIL? > . Should we ask/require everyone to do KFAIL like this? > > I know I'm probably being a little pedantic about this, I just want to > have a discussion before we find ourselves with four different KFAIL > philosophies in our test suite. I won't mind at all doing it whatever > way that FernandoN and AndrewC think is best. I've got two separate complaints. First of all, KFAIL is (in my opinion) for things that we have analyzed and established to be known bugs _in the tool under test_. That's what differentiates them from XFAILs; I thought that was the consensus. I don't see that kind of analysis having happened yet; and in fact I see reason to believe that it isn't the case. The bug in this case is apparently: 10: c7 45 fc 65 00 00 00 movl $0x65,0xfffffffc(%ebp) 17: c7 45 f8 66 00 00 00 movl $0x66,0xfffffff8(%ebp) 1e: c7 45 f4 67 00 00 00 movl $0x67,0xfffffff4(%ebp) 25: b8 00 00 00 00 mov $0x0,%eax <2><3f>: Abbrev Number: 3 (DW_TAG_lexical_block) DW_AT_low_pc : 0x10 16 DW_AT_high_pc : 0x25 37 I.E. the "return 0" is outside of the lexical block for main. That's not necessarily wrong. We have to decide if it is wrong - whether the test case should be updated or a GCC bug report filed. My inclination is that it's a GCC bug. GDB is behaving exactly as expected given its inputs; ergo, this is not a KFAIL at all. > send_gdb "info locals\n" > gdb_expect { > -re "(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)\r\n$gdb_prompt $" { > pass "info locals" > } > -re "No locals.\r\n$gdb_prompt $" { > # The locals have disappeared just before the end of the function. > # This happened with gcc HEAD%20021224 -gdwarf-2. > # -- chastain 2002-12-29 > kfail "gdb/900" "info locals" > } > -re ".*$gdb_prompt $" { > fail "info locals" > } > timeout { > fail "info locals (timeout)" > } > } Secondly, I really dislike this form. Adding gdb_expect's all over is bad, because gdb_test has a much more thorough list of things to expect indicating various errors. Better would be to solve this problem with a little TCL. What do you think of: gdb_test_multiple "info locals" \ {pass "(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)" kfail "gdb/900" "No locals."} \ "testing locals" -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer