From 52e0e32b34e503630e124cd60365a6d3ec5b1181 Mon Sep 17 00:00:00 2001 From: Simon Marchi Date: Thu, 10 Jun 2021 10:47:39 -0400 Subject: [PATCH] gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run When running this test with the native-extended-gdbserver, we get: main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19 19 while (! should_exit) The program being debugged has been started already. Start it from the beginning? (y or n) PASS: gdb.base/attach.exp: cmdline attach run: run to prompt y Don't know how to run. Try "help target". (gdb) FAIL: gdb.base/attach.exp: cmdline attach run: run to main This test tests using both "-p " and "-ex start" on the command line, making sure that we first attach and then run. Normally, after that "y", we should see the program running again. However, a particuliarity of the native-extended-gdbserver is that it uses "set auto-connect-native-target off" on the command line. The full GDB command line is: ./gdb -nw -nx -data-directory /home/simark/build/binutils-gdb/gdb/testsuite/../data-directory \ -iex set height 0 -iex set width 0 -ex set auto-connect-native-target off \ -ex set sysroot -quiet -iex set height 0 -iex set width 0 --pid=536609 -ex start The attach succeeds. I guess it is done before "set auto-connect-native-target off", or it somehow bypasses it. When the "start" is executed, the native target is unpushed, while killing the existing process, but not re-pushed, due to "set auto-connect-native-target off". So we get that "Don't know how to run" message. Really, I think it's a case of the test doing things incompatible with the board, I think it should just be skipped. And as we can see with the current code, there were some attempts at doing this, just using the wrong checks: - isnative: this is a dejagnu proc which checks if the target board has the same triplet as the build machine. In the case of native-extended-gdbserver, it does. - is_remote target: this checks whether the target board is remote, as in executing on a different machin. native-extended-gdbserver is not remote. Since the --pid option specifically attaches to a process using the native target, change the test to use gdb_is_target_native instead. gdb/testsuite/ChangeLog: * gdb.base/attach.exp (test_command_line_attach_run): Use gdb_is_target_native to check if test is supported. Change-Id: I762e127f39623889999dc9ed2185540a0951bfb0 --- gdb/testsuite/gdb.base/attach.exp | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp index b0ded430bb2..8b78dcc5181 100644 --- a/gdb/testsuite/gdb.base/attach.exp +++ b/gdb/testsuite/gdb.base/attach.exp @@ -472,14 +472,19 @@ proc_with_prefix test_command_line_attach_run {} { global gdb_prompt global binfile - # Skip test if we cannot attach on the command line and use the run command. - # ??? Unclear what condition to use to return here when using gdbserver. - # ??? None of the below works. - # ![isnative] || [target_is_gdbserver] - # ![isnative] || [use_gdb_stub] - if { ![isnative] || [is_remote target] } then { + # The --pid option is used to attach to a process using the native target. + # Start GDB and run to main just to see what the execution target is, skip + # if it's not the native target. + clean_restart $binfile + + if { ![runto_main] } { + fail "could not run to main" + return + } + + if { ![gdb_is_target_native] } { unsupported "commandline attach run test" - return 0 + return } set test_spawn_id [spawn_wait_for_attach $binfile] -- 2.30.2