This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: gdb.c++/main-falloff.exp (a new KFAIL)
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: carlton at math dot stanford dot edu, gdb-patches at sources dot redhat dot com
- Date: Fri, 3 Jan 2003 16:36:54 -0500
- Subject: Re: RFC: gdb.c++/main-falloff.exp (a new KFAIL)
- References: <200301032116.h03LGhq19408@duracef.shout.net>
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