binutils-gdb/gdb/testsuite/gdb.server/abspath.exp

68 lines
2.2 KiB
Plaintext
Raw Normal View History

Make gdbserver work with filename-only binaries Simon mentioned on IRC that, after the startup-with-shell feature has been implemented on gdbserver, it is not possible to specify a filename-only binary, like: $ gdbserver :1234 a.out /bin/bash: line 0: exec: a.out: not found During startup program exited with code 127. Exiting This happens on systems where the current directory "." is not listed in the PATH environment variable. Although including "." in the PATH variable is a possible workaround, this can be considered a regression because before startup-with-shell it was possible to use only the filename (due to reason that gdbserver used "exec*" directly). The idea of the patch is to verify if the program path provided by the user (or by the remote protocol) contains a directory separator character. If it doesn't, it means we're dealing with a filename-only binary, so we call "gdb_abspath" to properly expand it and transform it into a full path. Otherwise, we leave the program path untouched. This mimicks the behaviour seen on GDB (look at "openp" and "attach_inferior", for example). I am also submitting a testcase which exercises the scenario described above. This test requires gdbserver to be executed in a different CWD than the original, so I also created a helper function, "with_cwd" (on testsuite/lib/gdb.exp), which takes care of cd'ing into and out of the specified dir. Built and regtested on BuildBot, without regressions. gdb/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> Simon Marchi <simon.marchi@polymtl.ca> * common/common-utils.c: Include "sys/stat.h". (is_regular_file): Move here from "source.c"; change return type to "bool". * common/common-utils.h (is_regular_file): New prototype. * common/pathstuff.c (contains_dir_separator): New function. * common/pathstuff.h (contains_dir_separator): New prototype. * source.c: Don't include "sys/stat.h". (is_regular_file): Move to "common/common-utils.c". gdb/gdbserver/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> * server.c: Include "filenames.h" and "pathstuff.h". (program_name): Delete variable. (program_path): New anonymous class. (get_exec_wrapper): Use "program_path" instead of "program_name". (handle_v_run): Likewise. (captured_main): Likewise. (process_serial_event): Likewise. gdb/testsuite/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.server/abspath.exp: New file. * lib/gdb.exp (with_cwd): New procedure.
2018-02-10 07:54:41 +08:00
# This testcase is part of GDB, the GNU debugger.
# Copyright 2018-2022 Free Software Foundation, Inc.
Make gdbserver work with filename-only binaries Simon mentioned on IRC that, after the startup-with-shell feature has been implemented on gdbserver, it is not possible to specify a filename-only binary, like: $ gdbserver :1234 a.out /bin/bash: line 0: exec: a.out: not found During startup program exited with code 127. Exiting This happens on systems where the current directory "." is not listed in the PATH environment variable. Although including "." in the PATH variable is a possible workaround, this can be considered a regression because before startup-with-shell it was possible to use only the filename (due to reason that gdbserver used "exec*" directly). The idea of the patch is to verify if the program path provided by the user (or by the remote protocol) contains a directory separator character. If it doesn't, it means we're dealing with a filename-only binary, so we call "gdb_abspath" to properly expand it and transform it into a full path. Otherwise, we leave the program path untouched. This mimicks the behaviour seen on GDB (look at "openp" and "attach_inferior", for example). I am also submitting a testcase which exercises the scenario described above. This test requires gdbserver to be executed in a different CWD than the original, so I also created a helper function, "with_cwd" (on testsuite/lib/gdb.exp), which takes care of cd'ing into and out of the specified dir. Built and regtested on BuildBot, without regressions. gdb/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> Simon Marchi <simon.marchi@polymtl.ca> * common/common-utils.c: Include "sys/stat.h". (is_regular_file): Move here from "source.c"; change return type to "bool". * common/common-utils.h (is_regular_file): New prototype. * common/pathstuff.c (contains_dir_separator): New function. * common/pathstuff.h (contains_dir_separator): New prototype. * source.c: Don't include "sys/stat.h". (is_regular_file): Move to "common/common-utils.c". gdb/gdbserver/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> * server.c: Include "filenames.h" and "pathstuff.h". (program_name): Delete variable. (program_path): New anonymous class. (get_exec_wrapper): Use "program_path" instead of "program_name". (handle_v_run): Likewise. (captured_main): Likewise. (process_serial_event): Likewise. gdb/testsuite/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.server/abspath.exp: New file. * lib/gdb.exp (with_cwd): New procedure.
2018-02-10 07:54:41 +08:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Test that gdbserver performs path expansion/adjustment when we
# provide just a filename (without any path specifications) to it.
load_lib gdbserver-support.exp
standard_testfile normal.c
if { [skip_gdbserver_tests] } {
return 0
}
# Because we're relying on being able to change our CWD before
# executing gdbserver, we just run if we're not testing with a remote
# target.
if { [is_remote target] } {
return 0
}
gdb/testsuite: avoid reading files through the remote protocol in gdb.server/*.exp When I run some tests in gdb.server (fox example gdb.server/ext-attach.exp) on Ubuntu 20.04 with separate debug info for glibc installed, they often time out. This is because GDB reads the debug info through the remote protocol which is particularly slow: attach 316937 Attaching to program: /home/smarchi/build/binutils-gdb-all-targets/gdb/testsuite/outputs/gdb.server/ext-attach/ext-attach, process 316937 Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6... Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target... Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target... Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target... FAIL: gdb.server/ext-attach.exp: attach to remote program 1 (timeout) This is avoided in gdbserver boards by adding "set sysroot" to GDBFLAGS (see boards/local-board.exp), which makes GDB read files from the local filesystem. But gdb.server tests spawn GDBserver directly, so are ran even when using the default unix board, where the "set sysroot" isn't used. Modify these tests to append "set sysroot" to the GDBFLAGS, a bit like lib/local-board.exp does. One special case is gdb.server/sysroot.exp, whose intent is to test different "set sysroot" values. For this one, increase the timeout when testing the "target:" sysroot. gdb/testsuite/ChangeLog: * gdb.server/abspath.exp: Append "set sysroot" to GDBFLAGS. * gdb.server/connect-without-multi-process.exp: Likewise. * gdb.server/exit-multiple-threads.exp: Likewise. * gdb.server/ext-attach.exp: Likewise. * gdb.server/ext-restart.exp: Likewise. * gdb.server/ext-run.exp: Likewise. * gdb.server/ext-wrapper.exp: Likewise. * gdb.server/multi-ui-errors.exp: Likewise. * gdb.server/no-thread-db.exp: Likewise. * gdb.server/reconnect-ctrl-c.exp: Likewise. * gdb.server/run-without-local-binary.exp: Likewise. * gdb.server/server-kill.exp: Likewise. * gdb.server/server-run.exp: Likewise. * gdb.server/solib-list.exp: Likewise. * gdb.server/stop-reply-no-thread.exp: Likewise. * gdb.server/wrapper.exp: Likewise. * gdb.server/sysroot.exp: Increase timeout when testing the target: sysroot. Change-Id: I7451bcc737f90e2cd0b977e9f09da3710774b0bf
2021-01-05 00:43:59 +08:00
save_vars { GDBFLAGS } {
# If GDB and GDBserver are both running locally, set the sysroot to avoid
# reading files via the remote protocol (the `is_remote target` check is
# already done above).
if { ![is_remote host] } {
set GDBFLAGS "$GDBFLAGS -ex \"set sysroot\""
}
if { [prepare_for_testing "failed to prepare" $testfile $srcfile debug] } {
return -1
}
Make gdbserver work with filename-only binaries Simon mentioned on IRC that, after the startup-with-shell feature has been implemented on gdbserver, it is not possible to specify a filename-only binary, like: $ gdbserver :1234 a.out /bin/bash: line 0: exec: a.out: not found During startup program exited with code 127. Exiting This happens on systems where the current directory "." is not listed in the PATH environment variable. Although including "." in the PATH variable is a possible workaround, this can be considered a regression because before startup-with-shell it was possible to use only the filename (due to reason that gdbserver used "exec*" directly). The idea of the patch is to verify if the program path provided by the user (or by the remote protocol) contains a directory separator character. If it doesn't, it means we're dealing with a filename-only binary, so we call "gdb_abspath" to properly expand it and transform it into a full path. Otherwise, we leave the program path untouched. This mimicks the behaviour seen on GDB (look at "openp" and "attach_inferior", for example). I am also submitting a testcase which exercises the scenario described above. This test requires gdbserver to be executed in a different CWD than the original, so I also created a helper function, "with_cwd" (on testsuite/lib/gdb.exp), which takes care of cd'ing into and out of the specified dir. Built and regtested on BuildBot, without regressions. gdb/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> Simon Marchi <simon.marchi@polymtl.ca> * common/common-utils.c: Include "sys/stat.h". (is_regular_file): Move here from "source.c"; change return type to "bool". * common/common-utils.h (is_regular_file): New prototype. * common/pathstuff.c (contains_dir_separator): New function. * common/pathstuff.h (contains_dir_separator): New prototype. * source.c: Don't include "sys/stat.h". (is_regular_file): Move to "common/common-utils.c". gdb/gdbserver/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> * server.c: Include "filenames.h" and "pathstuff.h". (program_name): Delete variable. (program_path): New anonymous class. (get_exec_wrapper): Use "program_path" instead of "program_name". (handle_v_run): Likewise. (captured_main): Likewise. (process_serial_event): Likewise. gdb/testsuite/ChangeLog: 2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.server/abspath.exp: New file. * lib/gdb.exp (with_cwd): New procedure.
2018-02-10 07:54:41 +08:00
}
# Make sure we're disconnected, in case we're testing with an
# extended-remote board, therefore already connected.
gdb_test "disconnect" ".*"
set target_exec [gdbserver_download_current_prog]
# Switch to where $target_exec lives, and execute gdbserver from
# there.
with_cwd "[file dirname $target_exec]" {
set target_execname [file tail $target_exec]
set res [gdbserver_start "" $target_execname]
set gdbserver_protocol [lindex $res 0]
set gdbserver_gdbport [lindex $res 1]
gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
gdb_breakpoint main
gdb_test "continue" "Breakpoint $decimal.* main.*" "continue to main"
}