public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Tom de Vries <vries@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] [gdb/testsuite] Use remote_exec chmod instead of remote_spawn
Date: Thu, 27 Oct 2022 14:53:42 +0000 (GMT)	[thread overview]
Message-ID: <20221027145343.5F604381E718@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b253899c901fed0ff56b2746945ffc824e412b81

commit b253899c901fed0ff56b2746945ffc824e412b81
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Oct 27 16:53:12 2022 +0200

    [gdb/testsuite] Use remote_exec chmod instead of remote_spawn
    
    I build gdb using -O2, and ran the testsuite using taskset -c 0, and ran into:
    ...
    (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
      action=delete: setup: adjust sysroot
    builtin_spawn gdbserver --once localhost:2385 /connect-with-no-symbol-file^M
    /bin/bash: connect-with-no-symbol-file: Permission denied^M
    /bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \
      Permission denied^M
    During startup program exited with code 126.^M
    Exiting^M
    target remote localhost:2385^M
    `connect-with-no-symbol-file' has disappeared; keeping its symbols.^M
    localhost:2385: Connection timed out.^M
    (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
      action=delete: connection to GDBserver succeeded
    ...
    
    The expected series of events is (skipping disconnect and detach as I don't
    think they're relevant to the problem):
    - enter scenario "permission"
    - cp $exec.bak $exec
    - gdbserver start with $exec
    - chmod 000 $exec
    - connect to gdbserver
    - enter scenario "delete"
    - cp $exec.bak $exec
    - gdbserver start with $exec
    - delete $exec
    - connect to gdbserver
    
    The problem is that the chmod is executed using remote_spawn:
    ...
           } elseif { $action == "permission" } {
             remote_spawn target "chmod 000 $target_exec"
           }
    ...
    without waiting on the resulting spawn id, so we're not sure when the
    chmod will have effect.
    
    The FAIL we're seeing above is explained by the chmod having effect during the
    delete scenario, after the "cp $exec.bak $exec" and before the "gdbserver
    start with $exec".
    
    Fix this by using remote_exec instead.
    
    Likewise, fix a similar case in gdb.mi/mi-exec-run.exp.
    
    Tested on x86_64-linux.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29726

Diff:
---
 gdb/testsuite/gdb.mi/mi-exec-run.exp                     | 2 +-
 gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.mi/mi-exec-run.exp b/gdb/testsuite/gdb.mi/mi-exec-run.exp
index f8e6550850f..3b373b2c84d 100644
--- a/gdb/testsuite/gdb.mi/mi-exec-run.exp
+++ b/gdb/testsuite/gdb.mi/mi-exec-run.exp
@@ -171,7 +171,7 @@ proc test {inftty_mode mi_mode force_fail} {
 # Create a not-executable copy of the program, in order to exercise
 # vfork->exec failing.
 gdb_remote_download host $binfile $binfile.nox
-remote_spawn target "chmod \"a-x\" $binfile.nox"
+remote_exec target "chmod \"a-x\" $binfile.nox"
 
 foreach_with_prefix inferior-tty {"main" "separate"} {
     foreach_with_prefix mi {"main" "separate"} {
diff --git a/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp b/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp
index d45e958a529..0ada144a803 100644
--- a/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp
+++ b/gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp
@@ -66,7 +66,7 @@ proc connect_no_symbol_file { sysroot action } {
 	if { $action == "delete" } then {
 	  remote_file target delete $target_exec
 	} elseif { $action == "permission" } {
-	  remote_spawn target "chmod 000 $target_exec"
+	  remote_exec target "chmod 000 $target_exec"
 	}
        
 	# Connect to GDBserver.

                 reply	other threads:[~2022-10-27 14:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20221027145343.5F604381E718@sourceware.org \
    --to=vries@sourceware.org \
    --cc=gdb-cvs@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).