From: Pedro Alves <pedro@palves.net>
Date: Mon, 18 Apr 2022 22:04:21 +0000 (+0100)
Subject: Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f4138e8f48948314d1049e713f4b793eec9757ca;p=binutils-gdb.git

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