From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24502 invoked by alias); 3 Jan 2003 21:37:06 -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 24494 invoked from network); 3 Jan 2003 21:37:05 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 3 Jan 2003 21:37:05 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18UbNQ-00034P-00; Fri, 03 Jan 2003 17:37:21 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UZUs-0005M0-00; Fri, 03 Jan 2003 16:36:54 -0500 Date: Fri, 03 Jan 2003 21:37:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: carlton@math.stanford.edu, gdb-patches@sources.redhat.com Subject: Re: RFC: gdb.c++/main-falloff.exp (a new KFAIL) Message-ID: <20030103213654.GA2690@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , carlton@math.stanford.edu, gdb-patches@sources.redhat.com References: <200301032116.h03LGhq19408@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301032116.h03LGhq19408@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00090.txt.bz2 On Fri, Jan 03, 2003 at 03:16:43PM -0600, Michael Elizabeth Chastain wrote: > Daniel J wrote: > > 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" > > David C replies: > > It would be nice if the branches could execute arbitrary code, like > > gdb_expect does, though, so that the xfails/kfails could be conditional > > on the operating system, debug format, or whatever. > > I'm changing my mind about the gdb_test_multiple approach. I'm not > opposed to gdb_test_multiple, but I don't want KFAIL activity to > wait for it. > > My original goals, back around April 2002, were: > > (1) provide a way to add new tests which show bugs in gdb. > > For example, look at PR gdb/186, "gdb have problems with C++ casting". > > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&database=gdb&pr=186 > > I have test code for this. It's not even a new test case; it is > more test code for gdb.c++/casts.exp (which does not cover classes > that have virtual functions). > > My understanding is that it's forbidden to add new tests which FAIL, > but acceptable to add new tests which KFAIL. > > I would like to commit my new tests and have them KFAIL with reference > to PR gdb/186. We talked about problems like this 9 months ago and > KFAIL is the solution that Fernando picked. > > (2) connect existing FAILs to the PR database. > > We have dozens of tests that already FAIL due to known reasons. > I think everybody wants to start marking those with KFAIL. > > I'm getting dismayed by the new turn of events where KFAIL deployment > is sprouting a dependency on new syntax in lib/gdb.exp which needs > to be designed and implemented. > > I would rather do these things in parallel. There are already plenty > of tests which use send_gdb/gdb_expect. If someone wants to implement a > better facility than send_gdb/gdb_expect, go for it, I will support such > an effort. As soon as it's available then I will convert gdb.c++/*.exp > to use it. But I no longer want to hold off on KFAIL activity to wait > for gdb_test_multiple. TCL is not as fierce as everyone seems to think it is! Really. gdb_test_multiple will only take me an hour tops to put together; I just wanted to get at least a little feedback on the syntax first. If it's bugging you that bad I'll do it or something similar tomorrow morning. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer