Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver
authorPedro Alves <pedro@palves.net>
Mon, 18 Apr 2022 22:04:21 +0000 (23:04 +0100)
committerPedro Alves <pedro@palves.net>
Tue, 3 May 2022 14:10:21 +0000 (15:10 +0100)
commitf4138e8f48948314d1049e713f4b793eec9757ca
tree30ac14b300f48b7ea1362feaa9b2e46097b54a65
parent1f9d9e321ca0416d970a8a4ae94df69de0e22d14
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
gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp