Re: RFC: gdb.c++/main-falloff.exp (a new KFAIL)

[Michael Elizabeth Chastain <mec@shout.net>]

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.

Michael C