[PATCH][gdb/testsuite] Emit unresolved for unknown proc

[PATCH][gdb/testsuite] Emit unresolved for unknown proc

[Tom de Vries]

Hi,

Since commit 26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
command in test-case" we don't abort the testrun when encountering an invalid
command.  However, since we don't report errors in the summary, there's a
chance that the error goes unnoticed.

Make the invalid command error more visible by marking the test-case
unresolved, such that we have f.i.:
...
PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
  testcase aborted due to invalid command name: gdb_py_test_multiple
ERROR: tcl error sourcing py-breakpoint.exp.
ERROR: invalid command name "gdb_py_test_multiple"
    while executing
  ...
                === gdb Summary ===

nr of expected passes            56
nr of unresolved testcases       1
...

Tested on x86_64-linux.

Any comments?

Thanks,
- Tom

[gdb/testsuite] Emit unresolved for unknown proc

gdb/testsuite/ChangeLog:

2020-06-29  Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (unknown): Make test-case unresolved.

---
 gdb/testsuite/lib/gdb.exp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index af3e02dac5..b0faf622a9 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5103,6 +5103,8 @@ proc default_gdb_init { test_file_name } {
 	rename ::unknown ::dejagnu_unknown
 	proc unknown { args } {
 	    # Use tcl's unknown.
+	    set cmd [lindex $args 0]
+	    unresolved "testcase aborted due to invalid command name: $cmd"
 	    return [uplevel 1 ::gdb_tcl_unknown $args]
 	}
     }

Re: [PATCH][gdb/testsuite] Emit unresolved for unknown proc

[Pedro Alves]

On 6/29/20 12:21 PM, Tom de Vries wrote:
> Hi,
> 
> Since commit 26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
> command in test-case" we don't abort the testrun when encountering an invalid
> command.  However, since we don't report errors in the summary, there's a
> chance that the error goes unnoticed.
> 
> Make the invalid command error more visible by marking the test-case
> unresolved, such that we have f.i.:
> ...
> PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
> UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
>   testcase aborted due to invalid command name: gdb_py_test_multiple
> ERROR: tcl error sourcing py-breakpoint.exp.
> ERROR: invalid command name "gdb_py_test_multiple"
>     while executing
>   ...
>                 === gdb Summary ===
> 
> nr of expected passes            56
> nr of unresolved testcases       1
> ...
> 
> Tested on x86_64-linux.
> 
> Any comments?

LGTM.

Sounds like we'll end up with two UNRESOLVEDs for this when Jacob's
changes land in DejaGnu, right?  Do you plan on making this
dependent on dejagnu version, or leave the two UNRESOLVEDs anyway?

Thanks,
Pedro Alves

Re: [PATCH][gdb/testsuite] Emit unresolved for unknown proc

[Tom de Vries]

On 6/29/20 1:54 PM, Pedro Alves wrote:
> On 6/29/20 12:21 PM, Tom de Vries wrote:
>> Hi,
>>
>> Since commit 26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
>> command in test-case" we don't abort the testrun when encountering an invalid
>> command.  However, since we don't report errors in the summary, there's a
>> chance that the error goes unnoticed.
>>
>> Make the invalid command error more visible by marking the test-case
>> unresolved, such that we have f.i.:
>> ...
>> PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
>> UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
>>   testcase aborted due to invalid command name: gdb_py_test_multiple
>> ERROR: tcl error sourcing py-breakpoint.exp.
>> ERROR: invalid command name "gdb_py_test_multiple"
>>     while executing
>>   ...
>>                 === gdb Summary ===
>>
>> nr of expected passes            56
>> nr of unresolved testcases       1
>> ...
>>
>> Tested on x86_64-linux.
>>
>> Any comments?
> 
> LGTM.
> 
> Sounds like we'll end up with two UNRESOLVEDs for this when Jacob's
> changes land in DejaGnu, right?  Do you plan on making this
> dependent on dejagnu version, or leave the two UNRESOLVEDs anyway?

I'm waiting for things to land in dejagnu master, and then plan to
update gdb accordingly, which hopefully will result in one UNRESOLVED.

Thanks,
- Tom