diff mbox series

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

Message ID 20221107161333.16999-4-tdevries@suse.de
State Committed
Headers
Series Fix remote target test fails |

Commit Message

Tom de Vries Nov. 7, 2022, 4:13 p.m. UTC 
  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(-)

Comments

Tom de Vries Nov. 8, 2022, 9:18 a.m. UTC | #1 
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
Tom de Vries Nov. 9, 2022, 8:49 p.m. UTC | #2 
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
Tom de Vries Nov. 15, 2022, 2:31 p.m. UTC | #3 
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
diff mbox series

Patch

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