Re: [RFA/linespec] wrong line number in breakpoint location

[Pedro Alves <palves@redhat.com>]

On 01/30/2018 04:09 AM, Joel Brobecker wrote:
>> Thanks, this is fine with me.  Just a really small nit, I would suggest
>> initializing the line_actual variable to 0 or -1 (an invalid line number)
>> prior to calling gdb_test_multiple.  This way, if that test fails,
>> line_actual will still be defined, and the expression that refers to it will
>> generate a FAIL instead of an unreadable tcl backtrace.
> 
> Sounds good. Just for kicks, I took at look at what it looks like
> when the variable is undefined, and the error message is obvious
> about why it fails. When the error is defined, however, you have
> to figure out what the difference is, and track the value of that
> variable down. What won me over to your suggestion is that the
> error can go unnoticed if you just compare .sum files...

My view is that since "using" an undefined variable results in
a TCL error, that is a testsuite bug, plain and simple.  
A TCL error is lower level than a dejagnu FAIL, and aborts the
whole testcase, while a dejagnu FAIL indicates that the testing
harness is working and caught GDB behaving unexpectedly in the
particular use case being tested.  A FAIL can go on and run
subsequent procedures/tests.

In cases like this where we're extracting variables with expect_out,
we often add failed-to-extract-variable handling after
the gdb_test_multiple, like this:

# start with "impossible" value.
set whatever -1 

gdb_test_multiple $test $test {
    -re "whatever is ($decimal)\r\n$gdb_prompt $" {
        set whatever $expect_out(1,string)
        pass $test
    }
}

if {$whatever == -1} {
  # bail out, no use continuing the procedure.
  return
}

So you get a FAIL in the gdb_test_multiple case, and skip
running the rest of the procedure.  Sometimes we call "untested"
before returning.  It's a bit easier to see usefulness of the
pattern if the tests _are_ put in a procedure called by a
main testcase driver, like:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
proc_with_prefix test_whatever {} {
  set whatever -1 

  gdb_test_multiple $test $test {
      -re "whatever is ($decimal)\r\n$gdb_prompt $" {
          set whatever $expect_out(1,string)
          pass $test
      }
  }

  if {$whatever == -1} {
    # bail out, no use continuing the procedure.
    return
  }
}

proc_with_prefix test_whatever_else {} {
  ...
}

# The drive code that calls test procedures.
test_whatever
test_whatever_else
~~~~~~~~~~~~~~~~~~~~~~~~~~~

And now test_whatever_else runs even if test_whatever bails out.

Thanks,
Pedro Alves