[PATCH 0/9] [gdb/testsuite] Fix remote target test fails

[PATCH 0/9] [gdb/testsuite] Fix remote target test fails

[Tom de Vries]

Fix testsuite failures with target board remote-gdbserver-on-localhost.

This is a follow-up on the proposed patch series
https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html by
Ivan Tetyushkin.  I started from scratch, but borrowed from the original
series, so I've marked that by using co-authored-by.

This patch series takes a different approach than the original proposal:
rather than trying to construct absolute file names that will work on the
remote target, make things work with the names as returned by remote_download.

One of the fixes is to add a REMOTE_TARGET_USERNAME parameter to the target
board, such that we can limit file permissions to get a more realistic
emulation of an actual remote target, and this allows us to reproduce the
failures reported by Ivan.

Tested on x86_64-linux, using target board remote-gdbserver-on-localhost.

Tom de Vries (9):
  [gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target
  [gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target
  [gdb/testsuite] Add REMOTE_TARGET_USERNAME in
    remote-gdbserver-on-localhost.exp
  [gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target
  [gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target
  [gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target
  [gdb/testsuite] Fix gdb.base/info-shared.exp for remote target
  [gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target
  [gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target

 .../boards/remote-gdbserver-on-localhost.exp  | 30 +++++++++++-
 .../gdb.base/exec-invalid-sysroot.exp         |  4 ++
 gdb/testsuite/gdb.base/foll-exec.exp          |  4 ++
 gdb/testsuite/gdb.base/foll-vfork.exp         |  4 ++
 gdb/testsuite/gdb.base/infcall-exec.c         | 48 ++++++++++++++++++-
 gdb/testsuite/gdb.base/infcall-exec.exp       | 10 +++-
 gdb/testsuite/gdb.base/info-shared.exp        | 11 ++++-
 gdb/testsuite/gdb.base/info_sources_2.exp     | 12 +++++
 gdb/testsuite/gdb.base/jit-elf-so.exp         | 11 +++--
 gdb/testsuite/gdb.base/jit-reader-exec.exp    | 14 ++++--
 gdb/testsuite/gdb.base/print-file-var.exp     |  6 ++-
 gdb/testsuite/gdb.base/solib-vanish.exp       | 17 +++++--
 gdb/testsuite/lib/gdb.exp                     | 40 ++++++++++------
 13 files changed, 174 insertions(+), 37 deletions(-)


base-commit: 8bfb6941c358ee2da8320125644c59bf90842f6b
-- 
2.35.3

[PATCH 1/9] [gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target

[Tom de Vries]

When running test-case gdb.base/foll-exec.exp with target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.base/foll-exec.exp: insert first exec catchpoint
continue^M
Continuing.^M
[Inferior 1 (process 4476) exited normally]^M
(gdb) FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program e\
xited)
...

The problem is that the foll-exec executable expects the exec-ed executable
execd-prog alongside it, but it's missing.

Fix this by adding the missing gdb_remote_download.

Likewise in a few other test-cases.

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.base/exec-invalid-sysroot.exp | 4 ++++
 gdb/testsuite/gdb.base/foll-exec.exp            | 4 ++++
 gdb/testsuite/gdb.base/foll-vfork.exp           | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/gdb/testsuite/gdb.base/exec-invalid-sysroot.exp b/gdb/testsuite/gdb.base/exec-invalid-sysroot.exp
index cacd5a092a2..7f7599cbf86 100644
--- a/gdb/testsuite/gdb.base/exec-invalid-sysroot.exp
+++ b/gdb/testsuite/gdb.base/exec-invalid-sysroot.exp
@@ -33,6 +33,10 @@ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${binfile2}" executable $c
     return -1
 }
 
+if { [is_remote target] } {
+    gdb_remote_download target $binfile2
+}
+
 if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable $compile_options] != "" } {
     untested "failed to compile main testcase"
     return -1
diff --git a/gdb/testsuite/gdb.base/foll-exec.exp b/gdb/testsuite/gdb.base/foll-exec.exp
index 8cddfa52c3b..a3d1a8781e9 100644
--- a/gdb/testsuite/gdb.base/foll-exec.exp
+++ b/gdb/testsuite/gdb.base/foll-exec.exp
@@ -36,6 +36,10 @@ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${binfile2}" executable $c
      return -1
 }
 
+if { [is_remote target] } {
+    gdb_remote_download target $binfile2
+}
+
 if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable $compile_options] != "" } {
      untested "failed to compile"
      return -1
diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp
index e4f75728600..9627a177896 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -42,6 +42,10 @@ if {[build_executable $testfile.exp $testfile2 $srcfile2 $compile_options] == -1
     return -1
 }
 
+if { [is_remote target] } {
+    gdb_remote_download target [standard_output_file $testfile2]
+}
+
 # A few of these tests require a little more time than the standard
 # timeout allows.
 set oldtimeout $timeout
-- 
2.35.3

[PATCH 2/9] [gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target

[Tom de Vries]

With test-case gdb.base/info_sources_2.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.base/info_sources_2.exp | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/gdb/testsuite/gdb.base/info_sources_2.exp b/gdb/testsuite/gdb.base/info_sources_2.exp
index f9246b8fa96..9fe3d479018 100644
--- a/gdb/testsuite/gdb.base/info_sources_2.exp
+++ b/gdb/testsuite/gdb.base/info_sources_2.exp
@@ -20,6 +20,8 @@ if { [skip_shlib_tests] } {
     return 0
 }
 
+set is_remote_target [is_remote target]
+
 standard_testfile -test.c -lib.c
 set solib_name [standard_output_file ${testfile}-lib.so]
 
@@ -37,6 +39,8 @@ if {[gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile} executable \
 
 clean_restart ${binfile}
 
+set solib_name [gdb_load_shlib $solib_name]
+
 if ![runto foo] {
     untested "failed to run to function foo"
     return -1
@@ -55,6 +59,7 @@ if ![runto foo] {
 # file is NOT listed for the given object file.
 proc run_info_sources { extra_args args } {
     global gdb_prompt srcdir subdir
+    global is_remote_target
 
     with_test_prefix "args: ${extra_args}" {
 
@@ -76,6 +81,9 @@ proc run_info_sources { extra_args args } {
 
 	    -re "^(\[^\r\n\]+):\r\n" {
 		set objfile_name $expect_out(1,string)
+		if { $is_remote_target } {
+		    set objfile_name [file tail $objfile_name]
+		}
 		exp_continue
 	    }
 
@@ -129,6 +137,10 @@ proc run_info_sources { extra_args args } {
 	    # Figure out the path for SOURCEFILE that we're looking for.
 	    set sourcepath [file normalize ${srcdir}/${subdir}/${sourcefile}]
 
+	    if { $is_remote_target } {
+		set objfile [file tail $objfile]
+	    }
+
 	    # Make sure we handle the case where there are no source files
 	    # associated with a particular objfile.
 	    set source_list {}
-- 
2.35.3

[PATCH 3/9] [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

[Tom de Vries]

As reported here
( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
number of test-cases fails with a remote target setup, for instance test-case
gdb.base/print-file-var.exp.

So, why don't we see these fails with our remote target boards in
gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?

The problem is that the target board uses the same machine and user for
both (by-definition-local) build and remote target, and when using absolute
pathnames to refer to files on build, we can access those files on target,
which in a real remote target setup wouldn't be the case: we'd have to
download them to target first, and then the filename would also be different.

For aforementioned test-case, this happens when the name of a shared library is
passed as absolute file name to gcc:
...
gcc ...  -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
  print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
...

Make these problems visible with remote-gdbserver-on-localhost.exp by
adding an option to specify a test account (still on the same machine)
using REMOTE_TARGET_USERNAME.

We make sure by restricting file permissions, that the test account cannot see
the build files on the $USER account, and that the $USER account cannot see
the target files on the test account.

And so we can reproduce the reported fails:
...
$ cd build/gdb
$ tc="gdb.base/print-file-var.exp"
$ tb="--target_board remote-gdbserver-on-localhost"
$ tbu="REMOTE_TARGET_USERNAME=remote-target"
$ make check RUNTESTFLAGS="$tb $tbu $tc"
   ...
FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
  version_id_main=0: continue to STOP marker
...

Tested on x86_64-linux.

Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 .../boards/remote-gdbserver-on-localhost.exp  | 30 +++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
index dacbbfb6f28..f74b549f28f 100644
--- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
+++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
@@ -18,7 +18,8 @@
 #
 # To use this file:
 # bash$ cd ${build_dir}/gdb
-# bash$ make check RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
+# bash$ make check RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost
+#   [ REMOTE_TARGET_USERNAME=<remote_target_username> ]"
 
 load_generic_config "gdbserver"
 load_board_description "gdbserver-base"
@@ -29,9 +30,34 @@ load_board_description "gdbserver-base"
 set_board_info rcp_prog "/usr/bin/scp"
 set_board_info rsh_prog "/usr/bin/ssh"
 set_board_info protocol standard
-set_board_info username $env(USER)
+if { [info exists REMOTE_TARGET_USERNAME] } {
+    set_board_info username $REMOTE_TARGET_USERNAME
+} else {
+    set_board_info username $env(USER)
+}
 set_board_info hostname localhost
 
+# Handle separate test account.
+if { [board_info $board username] != $env(USER) } {
+    # We're pretending that some local user account is remote target.
+    # Make things a bit more realistic by restricting file permissions.
+
+    # Make sure remote target can't see files on build.  Note that we're
+    # currently using $objdir/output instead of $objdir because of gdbserver
+    # being accessed on the target using $objdir/../../gdbserver/gdbserver.
+    remote_exec build "chmod go-rx $objdir/outputs"
+
+    # Make sure build can't see files on remote target.  We can't use
+    # remote_exec target, because we're in the middle of parsing the
+    # target board.
+    remote_exec build \
+	"[board_info $board rsh_prog] \
+		     -l [board_info $board username] \
+			[board_info $board hostname] \
+	chmod go-rx ."
+}
+
+
 proc ${board}_spawn { board cmd } {
     global board_info
 
-- 
2.35.3

Re: [PATCH 3/9] [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

On 11/7/22 17:13, Tom de Vries via Gdb-patches wrote:
> +    # Make sure remote target can't see files on build.  Note that we're
> +    # currently using $objdir/output instead of $objdir because of gdbserver
> +    # being accessed on the target using $objdir/../../gdbserver/gdbserver.
> +    remote_exec build "chmod go-rx $objdir/outputs"

And this follow-up patch fixes that limitation.

Thanks,
- Tom

[-- Attachment #2: 0010-gdb-testsuite-Use-remote-gdbserver-in-remote-gdbserv.patch --]
[-- Type: text/x-patch, Size: 2207 bytes --]

From e89845987beaf9a448e24de213e7446a0c539b27 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Tue, 8 Nov 2022 09:44:31 +0100
Subject: [PATCH 10/11] [gdb/testsuite] Use remote gdbserver in
 remote-gdbserver-on-localhost.exp

Currently for the remote target remote-gdbserver-on-localhost we use the
gdbserver file on build, even though it's a target executable.

Fix this by using a remote copy of gdbserver instead.

This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
can access:
...
-    remote_exec build "chmod go-rx $objdir/outputs"
+    remote_exec build "chmod go-rx $objdir"
...

Tested on x86_64-linux.
---
 .../boards/remote-gdbserver-on-localhost.exp          | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
index f74b549f28f..ded73c67cfb 100644
--- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
+++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
@@ -42,10 +42,8 @@ if { [board_info $board username] != $env(USER) } {
     # We're pretending that some local user account is remote target.
     # Make things a bit more realistic by restricting file permissions.
 
-    # Make sure remote target can't see files on build.  Note that we're
-    # currently using $objdir/output instead of $objdir because of gdbserver
-    # being accessed on the target using $objdir/../../gdbserver/gdbserver.
-    remote_exec build "chmod go-rx $objdir/outputs"
+    # Make sure remote target can't see files on build.
+    remote_exec build "chmod go-rx $objdir"
 
     # Make sure build can't see files on remote target.  We can't use
     # remote_exec target, because we're in the middle of parsing the
@@ -57,6 +55,11 @@ if { [board_info $board username] != $env(USER) } {
 	chmod go-rx ."
 }
 
+set gdb_server_prog [board_info $board gdb_server_prog]
+set gdb_server_prog [remote_download $board $gdb_server_prog]
+unset_board_info gdb_server_prog
+set_board_info gdb_server_prog $gdb_server_prog
+unset gdb_server_prog
 
 proc ${board}_spawn { board cmd } {
     global board_info
-- 
2.35.3

Re: [PATCH 3/9] [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On 11/8/22 10:18, Tom de Vries wrote:
> On 11/7/22 17:13, Tom de Vries via Gdb-patches wrote:
>> +    # Make sure remote target can't see files on build.  Note that we're
>> +    # currently using $objdir/output instead of $objdir because of 
>> gdbserver
>> +    # being accessed on the target using 
>> $objdir/../../gdbserver/gdbserver.
>> +    remote_exec build "chmod go-rx $objdir/outputs"
> 
> And this follow-up patch fixes that limitation.

But suffers from the fact that it picks up /usr/bin/gdbserver instead of 
~$remote_user_name/gdbserver.

So, fix this more simply, with this patch.

Thanks,
- Tom

[-- Attachment #2: 0010-gdb-testsuite-Normalize-gdbserver-path-name.patch --]
[-- Type: text/x-patch, Size: 2466 bytes --]

From c66a25f241bb954dcedb28f401e6a9075f2e787f Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Tue, 8 Nov 2022 09:44:31 +0100
Subject: [PATCH 10/19] [gdb/testsuite] Normalize gdbserver path name

Currently for the target board remote-gdbserver-on-localhost we use the
gdbserver file on build, using a file name which includes "/../".

Fix this by using a normalized file name instead.

This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
can access:
...
-    remote_exec build "chmod go-rx $objdir/outputs"
+    remote_exec build "chmod go-rx $objdir"
...

Tested on x86_64-linux.
---
 gdb/testsuite/boards/gdbserver-base.exp                | 3 ++-
 gdb/testsuite/boards/remote-gdbserver-on-localhost.exp | 6 ++----
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/boards/gdbserver-base.exp b/gdb/testsuite/boards/gdbserver-base.exp
index 20ee90d6116..633ac7e2342 100644
--- a/gdb/testsuite/boards/gdbserver-base.exp
+++ b/gdb/testsuite/boards/gdbserver-base.exp
@@ -22,7 +22,8 @@ process_multilib_options ""
 set_board_info compiler "[find_gcc]"
 
 # Test the copy of gdbserver in the build directory.
-set_board_info gdb_server_prog "[pwd]/../../gdbserver/gdbserver"
+set_board_info gdb_server_prog \
+    "[file normalize [pwd]/../../gdbserver/gdbserver]"
 
 # gdbserver does not intercept target file operations and perform them
 # on the host.
diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
index 931fba7fa26..af23eaad083 100644
--- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
+++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
@@ -42,10 +42,8 @@ if { [board_info $board username] != $env(USER) } {
     # We're pretending that some local user account is remote target.
     # Make things a bit more realistic by restricting file permissions.
 
-    # Make sure remote target can't see files on build.  Note that we're
-    # currently using $objdir/output instead of $objdir because of gdbserver
-    # being accessed on the target using $objdir/../../gdbserver/gdbserver.
-    remote_exec build "chmod go-rx $objdir/outputs"
+    # Make sure remote target can't see files on build.
+    remote_exec build "chmod go-rx $objdir"
 
     # Make sure build can't see files on remote target.  We can't use
     # remote_exec target, because we're in the middle of parsing the
-- 
2.35.3

Re: [PATCH 3/9] [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

[Tom de Vries]

On 11/9/22 21:49, Tom de Vries via Gdb-patches wrote:
> On 11/8/22 10:18, Tom de Vries wrote:
>> On 11/7/22 17:13, Tom de Vries via Gdb-patches wrote:
>>> +    # Make sure remote target can't see files on build.  Note that 
>>> we're
>>> +    # currently using $objdir/output instead of $objdir because of 
>>> gdbserver
>>> +    # being accessed on the target using 
>>> $objdir/../../gdbserver/gdbserver.
>>> +    remote_exec build "chmod go-rx $objdir/outputs"
>>
>> And this follow-up patch fixes that limitation.
> 
> But suffers from the fact that it picks up /usr/bin/gdbserver instead of 
> ~$remote_user_name/gdbserver.
> 
> So, fix this more simply, with this patch.

After pushing the series, also pushed this follow-up patch.

Thanks,
- Tom

[PATCH 4/9] [gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target

[Tom de Vries]

When running test-case gdb.base/print-file-var.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by using the name of a shared lib as returned by gdb_load_shlib.

This required splitting up the gdb_load_shlib functionality, which is now
defined as:
...
proc gdb_load_shlib { file } {
    set dest [gdb_download_shlib $file]
    gdb_locate_shlib $file
    return $dest
}
...
such that we can do gdb_download_shlib before gdb is started.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 gdb/testsuite/gdb.base/print-file-var.exp |  6 ++--
 gdb/testsuite/lib/gdb.exp                 | 40 ++++++++++++++---------
 2 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/gdb/testsuite/gdb.base/print-file-var.exp b/gdb/testsuite/gdb.base/print-file-var.exp
index 9abe87d7758..841eb22d957 100644
--- a/gdb/testsuite/gdb.base/print-file-var.exp
+++ b/gdb/testsuite/gdb.base/print-file-var.exp
@@ -59,8 +59,10 @@ proc test {hidden dlopen version_id_main lang} {
     set main_opts [list debug $lang]
     set link_opts [list debug shlib=${libobj1}]
 
+    set target_libobj2 [gdb_download_shlib $libobj2]
+
     if {$dlopen} {
-	lappend main_opts "additional_flags=-DSHLIB_NAME=\"$libobj2\""
+	lappend main_opts "additional_flags=-DSHLIB_NAME=\"$target_libobj2\""
 	lappend link_opts "shlib_load"
     } else {
 	lappend link_opts "shlib=${libobj2}"
@@ -79,7 +81,7 @@ proc test {hidden dlopen version_id_main lang} {
 
     clean_restart $executable
     gdb_load_shlib $libobj1
-    gdb_load_shlib $libobj2
+    gdb_locate_shlib $libobj2
 
     if ![runto_main] {
 	return -1
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index e2cda30b95a..ef609e6e37e 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5869,30 +5869,40 @@ proc gdb_remote_download {dest fromfile {tofile {}}} {
     }
 }
 
-# gdb_load_shlib LIB...
-#
-# Copy the listed library to the target.
+# Copy shlib FILE to the target.
 
-proc gdb_load_shlib { file } {
+proc gdb_download_shlib { file } {
+    return [gdb_remote_download target [shlib_target_file $file]]
+}
+
+# Set solib-search-path to allow gdb to locate shlib FILE.
+
+proc gdb_locate_shlib { file } {
     global gdb_spawn_id
 
     if ![info exists gdb_spawn_id] {
 	perror "gdb_load_shlib: GDB is not running"
     }
 
-    set dest [gdb_remote_download target [shlib_target_file $file]]
-
-    if {[is_remote target]} {
-	# If the target is remote, we need to tell gdb where to find the
-	# libraries.
-	#
-	# We could set this even when not testing remotely, but a user
-	# generally won't set it unless necessary.  In order to make the tests
-	# more like the real-life scenarios, we don't set it for local testing.
-	gdb_test "set solib-search-path [file dirname $file]" "" \
-	    "set solib-search-path for [file tail $file]"
+    # If the target is remote, we need to tell gdb where to find the
+    # libraries.
+    if { ![is_remote target] } {
+	return
     }
 
+    # We could set this even when not testing remotely, but a user
+    # generally won't set it unless necessary.  In order to make the tests
+    # more like the real-life scenarios, we don't set it for local testing.
+    gdb_test "set solib-search-path [file dirname $file]" "" \
+	"set solib-search-path for [file tail $file]"
+}
+
+# Copy shlib FILE to the target and set solib-search-path to allow gdb to
+# locate it.
+
+proc gdb_load_shlib { file } {
+    set dest [gdb_download_shlib $file]
+    gdb_locate_shlib $file
     return $dest
 }
 
-- 
2.35.3

[PATCH 5/9] [gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target

[Tom de Vries]

When running test-case gdb.base/infcall-exec.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into:
...
(gdb) call (int) execlp ("$outputs/gdb.base/infcall-exec/infcall-exec2", \
  "$outputs/gdb.base/infcall-exec/infcall-exec2", (char *)0)^M
$1 = -1^M
(gdb) FAIL: gdb.base/infcall-exec.exp: call execlp
...

Fix this by using just:
...
(gdb) call (int) execlp ("infcall-exec2", "infcall-exec2", (char *)0)^M
...
and using putenv ("PATH=...") to allow infcall-exec to exec infcall-exec2
if it's available alongside.

Also fix the exec name in the test-case, such that we can successfully
run the test-case:
...
$ ./outputs/gdb.base/infcall-exec/infcall-exec
PATH SETTING: 'PATH=./outputs/gdb.base/infcall-exec'
$
...

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 gdb/testsuite/gdb.base/infcall-exec.c   | 48 +++++++++++++++++++++++--
 gdb/testsuite/gdb.base/infcall-exec.exp | 10 +++++-
 2 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.base/infcall-exec.c b/gdb/testsuite/gdb.base/infcall-exec.c
index 75b629872d0..49c1f40a8d9 100644
--- a/gdb/testsuite/gdb.base/infcall-exec.c
+++ b/gdb/testsuite/gdb.base/infcall-exec.c
@@ -16,13 +16,57 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include <unistd.h>
+#include <stdlib.h>
+#include <limits.h>
+#include <string.h>
+#include <stdio.h>
+#include <assert.h>
+
+static void
+set_path (int argc, char ** argv)
+{
+  if (argc < 1)
+    return;
+
+  char path[PATH_MAX];
+  strcpy (path, argv[0]);
+  int len = strlen (path);
+
+  /* Make a path name out of an exec name.  */
+  int i;
+  for (i = len - 1; i >= 0; i--)
+    {
+      char c = path[i];
+      if (c == '/' || c == '\\')
+	{
+	  path[i] = '\0';
+	  break;
+	}
+    }
+  len = i;
+
+  if (len == 0)
+    return;
+
+  /* Prefix with "PATH=".  */
+  const char *prefix = "PATH=";
+  int prefix_len = strlen (prefix);
+  memmove (path + prefix_len, path, len);
+  path[prefix_len + len] = '\0';
+  memcpy (path, prefix, prefix_len);
+
+  printf ("PATH SETTING: '%s'\n", path);
+  putenv (path);
+}
 
 int
 main (int argc, char ** argv)
 {
-  const char *prog = "inf-exec2";
+  set_path (argc, argv);
+  const char *prog = "infcall-exec2";
 
-  execlp (prog, prog, (char *) 0);
+  int res = execlp (prog, prog, (char *) 0); /* break here */
+  assert (res != -1);
 
   return 0;
 }
diff --git a/gdb/testsuite/gdb.base/infcall-exec.exp b/gdb/testsuite/gdb.base/infcall-exec.exp
index e8f6a218c36..033dacb5e88 100644
--- a/gdb/testsuite/gdb.base/infcall-exec.exp
+++ b/gdb/testsuite/gdb.base/infcall-exec.exp
@@ -32,13 +32,21 @@ if {[gdb_compile $srcdir/$subdir/$srcfile2 $binfile2 executable debug] != ""} {
     return -1
 }
 
+if { [is_remote target] } {
+    set binfile2 [gdb_remote_download target $binfile2]
+}
+
 clean_restart $binfile
 
 if {![runto_main]} {
     return -1
 }
 
-set expected_result "process $decimal is executing new program: $binfile2"
+set linenr [gdb_get_line_number "break here"]
+gdb_breakpoint $linenr
+gdb_continue_to_breakpoint "Ensure PATH is set" ".* break here .*"
+
+set expected_result "process $decimal is executing new program: \[^\r\n\]*$binfile2"
 append expected_result "\[\r\n\]+.*"
 append expected_result "Breakpoint 1, main .*at .*$srcfile2:$decimal"
 append expected_result ".*"
-- 
2.35.3

[PATCH 6/9] [gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target

[Tom de Vries]

When running test-case gdb.base/solib-vanish.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 gdb/testsuite/gdb.base/solib-vanish.exp | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/gdb.base/solib-vanish.exp b/gdb/testsuite/gdb.base/solib-vanish.exp
index 5f47f2a80fd..6dfcd6f8bca 100644
--- a/gdb/testsuite/gdb.base/solib-vanish.exp
+++ b/gdb/testsuite/gdb.base/solib-vanish.exp
@@ -69,22 +69,31 @@ set srcfile_lib1 ${srcdir}/${subdir}/${lib1name}.c
 set binfile_lib1 [standard_output_file ${lib1name}.so]
 set lib1_flags [list debug shlib=${binfile_lib2}]
 
+if { [gdb_compile_shlib ${srcfile_lib2} ${binfile_lib2} $lib2_flags] != ""
+     || [gdb_compile_shlib ${srcfile_lib1} ${binfile_lib1} $lib1_flags] != "" } {
+    untested "failed to compile"
+    return -1
+}
+
 # Main program
 set testfile "solib-vanish-main"
 set srcfile ${srcdir}/${subdir}/${testfile}.c
 set executable ${testfile}
 set binfile [standard_output_file ${executable}]
-set bin_flags [list debug shlib_load additional_flags=-DVANISH_LIB=\"${binfile_lib1}\"]
+set bin_flags [list debug shlib_load]
+set binfile_lib1_target [gdb_download_shlib $binfile_lib1]
+lappend bin_flags additional_flags=-DVANISH_LIB=\"$binfile_lib1_target\"
 
-if { [gdb_compile_shlib ${srcfile_lib2} ${binfile_lib2} $lib2_flags] != ""
-     || [gdb_compile_shlib ${srcfile_lib1} ${binfile_lib1} $lib1_flags] != ""
-     || [gdb_compile ${srcfile} ${binfile} executable $bin_flags] != "" } {
+if { [gdb_compile ${srcfile} ${binfile} executable $bin_flags] != "" } {
     untested "failed to compile"
     return -1
 }
 
 clean_restart $testfile
 
+gdb_locate_shlib $binfile_lib1
+gdb_load_shlib $binfile_lib2
+
 if { ![runto_main] } {
     return
 }
-- 
2.35.3

[PATCH 7/9] [gdb/testsuite] Fix gdb.base/info-shared.exp for remote target

[Tom de Vries]

With test-case gdb.base/info-shared.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 gdb/testsuite/gdb.base/info-shared.exp | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.base/info-shared.exp b/gdb/testsuite/gdb.base/info-shared.exp
index 290ae5793dc..8d3484b186c 100644
--- a/gdb/testsuite/gdb.base/info-shared.exp
+++ b/gdb/testsuite/gdb.base/info-shared.exp
@@ -22,12 +22,10 @@ standard_testfile
 set lib1name $testfile-solib1
 set srcfile_lib1 $srcdir/$subdir/$lib1name.c
 set binfile_lib1 [standard_output_file $lib1name.so]
-set define1 -DSHLIB1_NAME=\"$binfile_lib1\"
 
 set lib2name $testfile-solib2
 set srcfile_lib2 $srcdir/$subdir/$lib2name.c
 set binfile_lib2 [standard_output_file $lib2name.so]
-set define2 -DSHLIB2_NAME=\"$binfile_lib2\"
 
 if { [gdb_compile_shlib $srcfile_lib1 $binfile_lib1 {}] != "" } {
     untested "failed to compile shared library 1"
@@ -39,12 +37,21 @@ if { [gdb_compile_shlib $srcfile_lib2 $binfile_lib2 {}] != "" } {
     return -1
 }
 
+set binfile_lib1_target [gdb_download_shlib $binfile_lib1]
+set binfile_lib2_target [gdb_download_shlib $binfile_lib2]
+
+set define2 -DSHLIB2_NAME=\"$binfile_lib2_target\"
+set define1 -DSHLIB1_NAME=\"$binfile_lib1_target\"
+
 set cflags "$define1 $define2"
 if { [prepare_for_testing "failed to prepare" $testfile $srcfile \
 	  [list additional_flags=$cflags shlib_load]] } {
     return -1
 }
 
+gdb_locate_shlib $binfile_lib1
+gdb_locate_shlib $binfile_lib2
+
 # Run "info sharedlibrary" and check for the presence or absence of
 # our libraries.
 proc check_info_shared { test expect1 expect2 } {
-- 
2.35.3

[PATCH 8/9] [gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target

[Tom de Vries]

With test-case gdb.base/jit-reader-exec.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix this by adding the missing gdb_remote_download.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 gdb/testsuite/gdb.base/jit-reader-exec.exp | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/jit-reader-exec.exp b/gdb/testsuite/gdb.base/jit-reader-exec.exp
index c5ee8ef89a3..ad47c5a9610 100644
--- a/gdb/testsuite/gdb.base/jit-reader-exec.exp
+++ b/gdb/testsuite/gdb.base/jit-reader-exec.exp
@@ -27,15 +27,19 @@ set testfile2 "jit-reader-execd"
 set srcfile2 ${testfile2}.c
 set binfile2 [standard_output_file ${testfile2}]
 
-set compile_options [list debug additional_flags=-DPROGRAM=\"$binfile2\"]
-
-if {[gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
-	 executable $compile_options] != ""} {
+if {[gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${binfile2}" \
+	 executable {debug}] != ""} {
     untested "failed to compile"
     return -1
 }
 
-if {[gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${binfile2}" \
+if { [is_remote target] } {
+    set binfile2 [gdb_remote_download target $binfile2]
+}
+
+set compile_options [list debug additional_flags=-DPROGRAM=\"$binfile2\"]
+
+if {[gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
 	 executable $compile_options] != ""} {
     untested "failed to compile"
     return -1
-- 
2.35.3

[PATCH 9/9] [gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target

[Tom de Vries]

With test-case gdb.base/jit-elf-so.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by:
- setting jit_libname with the name as returned by gdb_load_shlib
- allowing the libraries to be prefixed with the remote target directory.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
---
 gdb/testsuite/gdb.base/jit-elf-so.exp | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/gdb.base/jit-elf-so.exp b/gdb/testsuite/gdb.base/jit-elf-so.exp
index dcc9afc36b9..d5f56600701 100644
--- a/gdb/testsuite/gdb.base/jit-elf-so.exp
+++ b/gdb/testsuite/gdb.base/jit-elf-so.exp
@@ -73,10 +73,10 @@ proc one_jit_test {solib_binfiles_target match_str} {
     with_test_prefix "one_jit_test-$count" {
 	global test_verbose
 	global main_loader_binfile main_loader_srcfile
-	global main_solib_binfile main_solib_srcfile
+	global main_solib_binfile main_solib_binfile_target main_solib_srcfile
 
 	clean_restart $main_loader_binfile
-	gdb_load_shlib $main_solib_binfile
+	gdb_locate_shlib $main_solib_binfile
 
 	# This is just to help debugging when things fail
 	if {$test_verbose > 0} {
@@ -90,7 +90,7 @@ proc one_jit_test {solib_binfiles_target match_str} {
 	gdb_breakpoint [gdb_get_line_number "break here before-dlopen" \
 			    $main_loader_srcfile]
 	gdb_continue_to_breakpoint "break here before-dlopen"
-	gdb_test_no_output "set var jit_libname = \"$main_solib_binfile\"" \
+	gdb_test_no_output "set var jit_libname = \"$main_solib_binfile_target\"" \
 	    "setting library name"
 
 	gdb_breakpoint [gdb_get_line_number "break here after-dlopen" \
@@ -140,6 +140,9 @@ if { [compile_jit_elf_main_as_so $main_solib_srcfile $main_solib_binfile \
     return
 }
 
+set main_solib_binfile_target \
+    [gdb_download_shlib $main_solib_binfile]
+
 # Compile the "real" main for this test.
 if { [compile_jit_dlmain {shlib_load}] < 0 } {
     return
@@ -161,6 +164,6 @@ foreach solib $jit_solibs_target {
     set input [string range $solib 0 [expr { [string length $solib] - 2 }]]
     gdb_test \
 	"complete jit-reader-load [standard_output_file $input]" \
-	"jit-reader-load $solib" \
+	"jit-reader-load \[^\r\n\]*$solib" \
 	"test jit-reader-load filename completion [file tail $solib]"
 }
-- 
2.35.3

Re: [PATCH 0/9] [gdb/testsuite] Fix remote target test fails

[Tom de Vries]

On 11/7/22 17:13, Tom de Vries via Gdb-patches wrote:
> Fix testsuite failures with target board remote-gdbserver-on-localhost.
> 
> This is a follow-up on the proposed patch series
> https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html by
> Ivan Tetyushkin.  I started from scratch, but borrowed from the original
> series, so I've marked that by using co-authored-by.
> 
> This patch series takes a different approach than the original proposal:
> rather than trying to construct absolute file names that will work on the
> remote target, make things work with the names as returned by remote_download.
> 
> One of the fixes is to add a REMOTE_TARGET_USERNAME parameter to the target
> board, such that we can limit file permissions to get a more realistic
> emulation of an actual remote target, and this allows us to reproduce the
> failures reported by Ivan.
> 
> Tested on x86_64-linux, using target board remote-gdbserver-on-localhost.
> 

Pushed.

Thanks,
- Tom

> Tom de Vries (9):
>    [gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target
>    [gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target
>    [gdb/testsuite] Add REMOTE_TARGET_USERNAME in
>      remote-gdbserver-on-localhost.exp
>    [gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target
>    [gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target
>    [gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target
>    [gdb/testsuite] Fix gdb.base/info-shared.exp for remote target
>    [gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target
>    [gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target
> 
>   .../boards/remote-gdbserver-on-localhost.exp  | 30 +++++++++++-
>   .../gdb.base/exec-invalid-sysroot.exp         |  4 ++
>   gdb/testsuite/gdb.base/foll-exec.exp          |  4 ++
>   gdb/testsuite/gdb.base/foll-vfork.exp         |  4 ++
>   gdb/testsuite/gdb.base/infcall-exec.c         | 48 ++++++++++++++++++-
>   gdb/testsuite/gdb.base/infcall-exec.exp       | 10 +++-
>   gdb/testsuite/gdb.base/info-shared.exp        | 11 ++++-
>   gdb/testsuite/gdb.base/info_sources_2.exp     | 12 +++++
>   gdb/testsuite/gdb.base/jit-elf-so.exp         | 11 +++--
>   gdb/testsuite/gdb.base/jit-reader-exec.exp    | 14 ++++--
>   gdb/testsuite/gdb.base/print-file-var.exp     |  6 ++-
>   gdb/testsuite/gdb.base/solib-vanish.exp       | 17 +++++--
>   gdb/testsuite/lib/gdb.exp                     | 40 ++++++++++------
>   13 files changed, 174 insertions(+), 37 deletions(-)
> 
> 
> base-commit: 8bfb6941c358ee2da8320125644c59bf90842f6b