This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/linespec] wrong line number in breakpoint location
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org, Keith Seitz <keiths at redhat dot com>, Xavier Roirand <roirand at adacore dot com>
- Date: Tue, 30 Jan 2018 12:39:02 +0000
- Subject: Re: [RFA/linespec] wrong line number in breakpoint location
- Authentication-results: sourceware.org; auth=none
- References: <1513565091-118926-1-git-send-email-brobecker@adacore.com> <a02f608153c9050c0275ae058ffd60b9@polymtl.ca> <20171219092405.n2dql5ji52qhjilj@adacore.com> <206d75d6b1f14e55b6a0dff523d8c722@polymtl.ca> <20171221113127.ijqv6dnzjfifwfnb@adacore.com> <20171221113214.hezwvaatnbd4yzfq@adacore.com> <5bc2ff63-7341-4000-8ec4-d56c87779c3d@ericsson.com> <20180129044505.mtvh2ps464imwp2t@adacore.com> <ee45bc1fd2a4f82cbd517994e16a95a7@polymtl.ca> <20180130040949.mbvm33n7atqvuik3@adacore.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