[1/2] gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run

Message ID 20210610144740.2021125-1-simon.marchi@polymtl.ca
State New
Headers show
  • [1/2] gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run
Related show

Commit Message

Metzger, Markus T via Gdb-patches June 10, 2021, 2:47 p.m.
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
    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"

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

Since the --pid option specifically attaches to a process using the
native target, change the test to use gdb_is_target_native instead.


	* 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 b0ded430bb27..8b78dcc51811 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]