Without this commit, doing...
make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \
TESTS="gdb.base/dprintf-execution-x-script.exp"
...will show one failure.
Here's a snippet from gdb.log showing the circumstances - I've trimmed
the paths for readability:
builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script
...
Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script...
Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38.
Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26.
testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file:
Don't know how to run. Try "help target".
(gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x
...
GNU gdb (GDB) 12.0.50.
20211118-git
Copyright (C) 2021 Free Software Foundation, Inc.
...
(gdb) set height 0
(gdb) set width 0
(gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
...
[Tests after this point will pass.]
Note that the command which spawns gdb prevents the gdb script from
using the native target via "-iex set auto-connect-native-target off".
Moreover, the script in question contains a "run" command, so GDB
doesn't know how to run (since it's prevented from using the native
target and no alternate "target" command has been issued. But, once
GDB finishes starting up, the test will spawn a gdbserver and then
connect to it. The other (two) tests after this point both pass.
I've fixed this by using gdb_test_multiple instead of gdb_test.
When a "Don't know how to run message" is received, the test is
unsupported.
I've also added a comment explaining the reason for needing to check
for "Don't know how to run" despite bailing out at the top of the test
via:
if ![target_can_use_run_cmd] {
return 0
}
set pat "${d}0.*?$b.*?${d}1.*?$b.*?${d}2.*?$b.*?"
proc do_test {cmd test} {
- gdb_test $cmd "$::pat$::inferior_exited_re normally.*" $test
+ gdb_test_multiple $cmd $test {
+ -re "$::pat$::inferior_exited_re normally.*$::gdb_prompt $" {
+ pass $test
+ }
+ -re "Don't know how to run.*$::gdb_prompt $" {
+ # Even though we bailed out at the beginning of this test case
+ # for targets which can't use the "run" command, there are
+ # still targets, e.g. native-extended-gdbserver, which can
+ # run, but will still print the "Don't know how to run"
+ # message. In the case of native-extended-gdbserver, it would
+ # first need to connect to the target in order to run. For
+ # that particular target, the very first test which attempts
+ # to use the "run" command from a command line script is
+ # the one that is unsupported. The other two tests will
+ # pass because, after reaching the (gdb) prompt, a gdbserver
+ # is spawned and then connected to. (The command line which
+ # spawns GDB for this target has a "-iex set
+ # auto-connect-native-target off" which prevents it from
+ # attempting to "run" using the native target.)
+ unsupported $test
+ }
+ }
}
# Check output from running script with -x