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 <pid>" 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

1 files changed, 12 insertions, 7 deletions

diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp
index b0ded43..8b78dcc 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]