[binutils-gdb] Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver

[binutils-gdb] Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver

[Pedro Alves]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f4138e8f48948314d1049e713f4b793eec9757ca

commit f4138e8f48948314d1049e713f4b793eec9757ca
Author: Pedro Alves <pedro@palves.net>
Date:   Mon Apr 18 23:04:21 2022 +0100

    Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver
    
    When testing gdb.threads/access-mem-running-thread-exit.exp with
    --target_board=native-extended-gdbserver, we get:
    
      Running gdb.threads/access-mem-running-thread-exit.exp ...
      FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
      WARNING: Timed out waiting for EOF in server after monitor exit
    
                      === gdb Summary ===
    
      # of expected passes            3
      # of unexpected failures        1
      # of unsupported tests          1
    
    The problem is that the testcase spawns a second inferior with
    -no-connection, and then runto_main does "run", which fails like so:
    
     (gdb) run
     Don't know how to run.  Try "help target".
     (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
    
    That "run" above failed because native-extended-gdbserver forces "set
    auto-connect-native-target off", to prevent testcases from mistakenly
    running programs with the native target, which would exactly be the
    case here.
    
    Fix this by letting the second inferior share the first inferior's
    connection everywhere except on targets that do reload on run (e.g.,
    --target_board=native-gdbserver).
    
    Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed

Diff:
---
 .../gdb.threads/access-mem-running-thread-exit.exp | 30 +++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp
index dddb35dabc0..8dc9af05c8e 100644
--- a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp
+++ b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp
@@ -79,7 +79,35 @@ proc test { non_stop } {
 
     # Start the second inferior.
     with_test_prefix "second inferior" {
-	gdb_test "add-inferior -no-connection" "New inferior 2.*"
+	# With stub targets that do reload on run, if we let the new
+	# inferior share inferior 1's connection, runto_main would
+	# fail because GDB is already connected to something, like
+	# e.g. with --target_board=native-gdbserver:
+	#
+	#  (gdb) kill
+	#  ...
+	#  (gdb) target remote localhost:2348
+	#  Already connected to a remote target.  Disconnect? (y or n)
+	#
+	# Instead, start the inferior with no connection, and let
+	# gdb_load/runto_main spawn a new remote connection/gdbserver.
+	#
+	# OTOH, with extended-remote, we must let the new inferior
+	# reuse the current connection, so that runto_main below can
+	# issue the "run" command, and have the inferior run on the
+	# remote target.  If we forced no connection, then "run" would
+	# either fail if "set auto-connect-native-target" is on, like
+	# the native-extended-gdbserver board enforces, or it would
+	# run the inferior on the native target, which isn't what is
+	# being tested.
+	#
+	# Since it's reload_on_run targets that need special care, we
+	# default to reusing the connection on most targets.
+	if [target_info exists gdb,do_reload_on_run] {
+	    gdb_test "add-inferior -no-connection" "New inferior 2.*"
+	} else {
+	    gdb_test "add-inferior" "New inferior 2.*"
+	}
 	gdb_test "inferior 2" "Switching to inferior 2 .*"
 
 	gdb_load $binfile