Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH] gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp
Date: Wed, 14 Jan 2026 20:01:15 +0000	[thread overview]
Message-ID: <19b4a897d945398861334de10c7c2c3367ecec3a.1768420854.git.aburgess@redhat.com> (raw)
In-Reply-To: <3d52893e-d2a8-48e9-aab0-b0c85d736de4@simark.ca>

Bug PR gdb/33792 reported a gdb.server/fetch-exec-and-args.exp FAIL
when using the native-gdbserver board:

  FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file

The actual test output looks like this:

  (gdb) show remote exec-file
  The remote exec-file is unset, using automatic value "/tmp/build/gdb/testsuite/outputs/gdb.server/fetch-exec-and-args/fetch-exec-and-args".
  (gdb) FAIL: gdb.server/fetch-exec-and-args.exp: packet=on: set_remote_exec=false: test_server_with_no_exec: show remote exec-file

This test actually fails with native-gdbsever and
native-extended-gdbserver boards.  The problem is that these boards
clear the sysroot.

This exact test has the following conditions:

  + The qExecAndArgs is in use (see 'packet=on').

  + We're not explicitly doing 'set remote exec-file ...' (see
    'set_remote_exec=false').

  + The test starts gdbserver without an executable (see
    'test_server_with_no_exec').

  + And because of the native-gdbsever board, the sysroot is "".

What this means is that GDB knows that gdbserver doesn't have an
executable thanks to qExecAndArgs, the user hasn't set an executable
for GDB to use when starting a new inferior, but GDB does know that
GDB and gdbserver can see the same filesystem due to the sysroot
setting.  GDB will then automatically use the current executable as
the remote executable name.  The test script doesn't expect this case,
and so the test fails.

Fix this by adjusting the script to expect the 'using automatic value
...' text when appropriate.

I also extended the test_server_with_no_exec proc to take a new flag
'clear_sysroot', we now run the test with the sysroot set to 'target:'
and with the sysroot set to "", even when using the 'unix' board.

Additionally, I ran the test through check-all-boards and found one
additional failure, when using --host_board=local-remote-host-native
and --target_board=local-remote-host-native.  In this case GDB copies
the executable to the remote host, which changes its filename.  When
the filename appears in the 'using automatic value ...' text, I was
expecting the filename assuming a local host.

I could fix this, but it doesn't seem worth the extra complexity for
this one test, so I've just set the test to be skipped for that one
configuration.

Now, when using check-all-boards, I'm seeing no failures.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33792
---
 .../gdb.server/fetch-exec-and-args.exp        | 57 +++++++++++++++++--
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.server/fetch-exec-and-args.exp b/gdb/testsuite/gdb.server/fetch-exec-and-args.exp
index d85cd94fb1d..36189dec602 100644
--- a/gdb/testsuite/gdb.server/fetch-exec-and-args.exp
+++ b/gdb/testsuite/gdb.server/fetch-exec-and-args.exp
@@ -54,11 +54,22 @@ proc check_show_args { packet } {
 # 'off' and reflects whether the qExecAndArgs packet is turned on or
 # off.  FILENAME is what we expect to see included in the output, and
 # is converted to a regexp by this function.
-proc check_remote_exec_file { packet filename } {
+#
+# The AUTO_FILENAME should only be set when PACKET is on and FILENAME
+# is the empty sting.  If AUTO_FILENAME is set, then this is the
+# filename that GDB is using for the remote executable based on the
+# current executable's filename.  For example, if the sysroot is empty
+# then GDB can use the current executable as the remote executable.
+proc check_remote_exec_file { packet filename { auto_filename "" } } {
     if { $filename eq "" } {
 	if { $packet } {
-	    set remote_exec_re \
-		"The remote exec-file is unset, the remote has no default executable set\\."
+	    if { $auto_filename ne "" } {
+		set remote_exec_re \
+		    "The remote exec-file is unset, using automatic value \"[string_to_regexp $auto_filename]\"\\."
+	    } else {
+		set remote_exec_re \
+		    "The remote exec-file is unset, the remote has no default executable set\\."
+	    }
 	} else {
 	    set remote_exec_re \
 		"The remote exec-file is unset, the default remote executable will be used\\."
@@ -260,9 +271,35 @@ proc_with_prefix test_remote_exec_warning {} {
 # filename when starting gdbserver.
 #
 # Connect to the remote server, and check 'show remote exec-file'.
-proc_with_prefix test_server_with_no_exec { packet set_remote_exec } {
+proc_with_prefix test_server_with_no_exec { packet set_remote_exec clear_sysroot } {
+    # For remote hosts GDB copies the executable to the host, changing
+    # its filename.  We can figure out the new exec filename, but it's
+    # additional work, so just don't bother.  We only need to bail out
+    # though in the precise case that the executable filename will be
+    # used in the output.
+    if {!$set_remote_exec && $clear_sysroot && [is_remote host]} {
+	return
+    }
+
     clean_restart
 
+    set sysroot "*UNKNOWN*"
+    gdb_test_multiple "show sysroot" "" {
+	-re -wrap "^The current system root is \"(\[^\r\n\]*)\"\\." {
+	    set sysroot $expect_out(1,string)
+	    pass $gdb_test_name
+	}
+    }
+    if { $sysroot ne "target:" && $sysroot ne "" } {
+	return
+    }
+
+    if { $clear_sysroot } {
+	gdb_test_no_output "set sysroot"
+    } else {
+	gdb_test_no_output "set sysroot target:"
+    }
+
     gdb_test "disconnect" ".*"
 
     gdb_file_cmd $::binfile
@@ -277,13 +314,18 @@ proc_with_prefix test_server_with_no_exec { packet set_remote_exec } {
 	gdb_test_no_output "set remote exec-file $target_exec" \
 	    "set remote exec-file"
 	set expected_filename $target_exec
+	set auto_filename ""
+    } elseif { $clear_sysroot } {
+	set expected_filename ""
+	set auto_filename $::binfile
     } else {
 	set expected_filename ""
+	set auto_filename ""
     }
 
     gdbserver_start_extended
 
-    check_remote_exec_file $packet $expected_filename
+    check_remote_exec_file $packet $expected_filename $auto_filename
 }
 
 # This override prevents the remote exec-file from being set when
@@ -298,7 +340,10 @@ with_override extended_gdbserver_load_last_file do_nothing {
 	    test_exec_and_arg_fetch $packet
 
 	    foreach_with_prefix set_remote_exec { true false } {
-		test_server_with_no_exec $packet $set_remote_exec
+		foreach_with_prefix clear_sysroot { true false } {
+		    test_server_with_no_exec $packet $set_remote_exec \
+			$clear_sysroot
+		}
 	    }
 	}
 

base-commit: 141f3b0ce1a4141ec0bbd19f1c5713999113a7de
-- 
2.47.1


  parent reply	other threads:[~2026-01-14 20:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-06 15:07 [PATCH] gdb: use current executable for 'remote exec-file' in some cases Andrew Burgess
2025-10-06 15:43 ` Eli Zaretskii
2025-10-09 16:17 ` Simon Marchi
2025-10-11 13:34 ` [PATCH 0/2] Auto setting of 'remote exec-file' Andrew Burgess
2025-10-11 13:34   ` [PATCH 1/2] gdb/remote: replace use of std::pair with an actual struct Andrew Burgess
2025-10-11 13:46     ` Simon Marchi
2025-10-12  8:57       ` Andrew Burgess
2025-10-12 12:05         ` Simon Marchi
2025-10-12 13:13           ` Andrew Burgess
2025-11-19 10:32     ` Andrew Burgess
2025-10-11 13:34   ` [PATCH 2/2] gdb: use current executable for 'remote exec-file' in some cases Andrew Burgess
2025-10-11 14:45     ` Eli Zaretskii
2025-11-07 20:46     ` Simon Marchi
2025-11-11 15:59       ` Andrew Burgess
2026-01-14  1:17         ` Simon Marchi
2026-01-14 16:48           ` Andrew Burgess
2026-01-14 20:01           ` Andrew Burgess [this message]
2026-01-15 21:13             ` [PATCH] gdb/testsuite: fix failure in gdb.server/fetch-exec-and-args.exp Simon Marchi
2026-01-22 15:31               ` Andrew Burgess
2025-11-19 10:32     ` [PATCH 2/2] gdb: use current executable for 'remote exec-file' in some cases Andrew Burgess

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=19b4a897d945398861334de10c7c2c3367ecec3a.1768420854.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --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