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

[Daniel Jacobowitz <drow at mvista dot com>]

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