public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH 1/2] Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver
Date: Tue, 19 Apr 2022 23:47:38 +0100	[thread overview]
Message-ID: <20220419224739.3029868-2-pedro@palves.net> (raw)
In-Reply-To: <20220419224739.3029868-1-pedro@palves.net>

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
---
 .../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
-- 
2.26.2


  reply	other threads:[~2022-04-19 22:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 22:47 [PATCH 0/2] Fix gdbserver/linux memory access regression Pedro Alves
2022-04-19 22:47 ` Pedro Alves [this message]
2022-04-19 22:47 ` [PATCH 2/2] gdbserver: track current process as well as current thread Pedro Alves
2023-04-25 13:57   ` Andrew Burgess
2023-04-26  6:35     ` Aktemur, Tankut Baris
2023-06-19 16:46       ` Aktemur, Tankut Baris
2023-06-22 17:49       ` Andrew Burgess
2023-06-28  8:39         ` Aktemur, Tankut Baris
2022-05-03 14:24 ` [PATCH 0/2] Fix gdbserver/linux memory access regression Pedro Alves
2022-05-04  9:11   ` Luis Machado
2022-05-04  9:42     ` Luis Machado
2022-05-04  9:45       ` Pedro Alves
2022-05-04  9:52         ` Luis Machado
2022-05-04 10:14           ` Pedro Alves
2022-05-04 13:44             ` Pedro Alves
2022-05-04 14:03               ` Luis Machado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220419224739.3029868-2-pedro@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).