• R/O
  • HTTP
  • SSH
  • HTTPS

Commit

Tags
No Tags

Frequently used words (click to add to your profile)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

Commit MetaInfo

Revisãob253899c901fed0ff56b2746945ffc824e412b81 (tree)
Hora2022-10-27 23:53:12
AutorTom de Vries <tdevries@suse...>
CommiterTom de Vries

Mensagem de Log

[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-fileM
/bin/bash: connect-with-no-symbol-file: Permission denied
M
/bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \

Permission deniedM

During startup program exited with code 126.M
Exiting
M
target remote localhost:2385M
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

Mudança Sumário

Diff

--- 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} {
171171 # Create a not-executable copy of the program, in order to exercise
172172 # vfork->exec failing.
173173 gdb_remote_download host $binfile $binfile.nox
174-remote_spawn target "chmod \"a-x\" $binfile.nox"
174+remote_exec target "chmod \"a-x\" $binfile.nox"
175175
176176 foreach_with_prefix inferior-tty {"main" "separate"} {
177177 foreach_with_prefix mi {"main" "separate"} {
--- 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 } {
6666 if { $action == "delete" } then {
6767 remote_file target delete $target_exec
6868 } elseif { $action == "permission" } {
69- remote_spawn target "chmod 000 $target_exec"
69+ remote_exec target "chmod 000 $target_exec"
7070 }
7171
7272 # Connect to GDBserver.