aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2025-08-06 15:28:16 -0400
committerSimon Marchi <simon.marchi@efficios.com>2025-08-27 15:57:29 -0400
commit15b3c1756339dfc00c61a8ad1390222ce4bbca4f (patch)
tree0348714f0d0310fcb1ff2154b601cce0d84ede9d
parent2f339e5ca03c5a89cf333d0cf090e3718d76f113 (diff)
downloadbinutils-15b3c1756339dfc00c61a8ad1390222ce4bbca4f.zip
binutils-15b3c1756339dfc00c61a8ad1390222ce4bbca4f.tar.gz
binutils-15b3c1756339dfc00c61a8ad1390222ce4bbca4f.tar.bz2
gdb/testsuite: do not copy gdb executable in self tests
In the ROCm-GDB testing process, we hit a problem that is a combination of these 3 factors: 1. In the downstream ROCm-GDB packages, the gdb executable is built with a relative RUNPATH: 0x000000000000001d (RUNPATH) Library runpath: [${ORIGIN}/../lib] This is done so that the installation is relocatable (the whole ROCm directory can be copied around) and things still work. For instance, the rocgdb executable needs to be able to find the libraries it needs, such as `librocm-dbgapi.so.0`. The relative runpath allows that. 2. For testing, we run the testsuite against the gdb executable installed from one of those packages. It is possible to ./configure the testsuite directory on its own, and then do: $ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb" 3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test to the standard output directory, before trying to debug it. The problem is that the gdb executable under test that has been copied can't find the libraries it needs. With this patch, I propose that we don't copy the gdb executable, but debug it in place instead. The comment removed in this patch says "in case this OS doesn't like to edit its own text space", and has been there since forever in some form. But it's not clear if there is a host OS (where we intend to run this test) that needs this nowadays. I would bet that there isn't. If there is in fact a GDB host OS (where we intend to run this test) that needs it, we can reinstate the copying, but as an opt-in operation. Another situation where this change helps is on Windows, where gdb/gdb.exe is a libtool wrapper (the real executable is at gdb/.libs/gdb.exe). Copying gdb/gdb.exe doesn't accomplish anything useful. The next patch does further changes to account for the libtool wrapper case. I tested on Linux and Cygwin, more testing would be welcome. Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d Reviewed-By: Keith Seitz <keiths@redhat.com>
-rw-r--r--gdb/testsuite/lib/selftest-support.exp23
1 files changed, 2 insertions, 21 deletions
diff --git a/gdb/testsuite/lib/selftest-support.exp b/gdb/testsuite/lib/selftest-support.exp
index 1a042e1..eb31b55 100644
--- a/gdb/testsuite/lib/selftest-support.exp
+++ b/gdb/testsuite/lib/selftest-support.exp
@@ -109,9 +109,7 @@ proc _selftest_setup { executable } {
return 0
}
-# Prepare for running a self-test by moving the GDB executable to a
-# location where we can use it as the inferior. Return the filename
-# of the new location.
+# Return the location of the gdb executable to test.
#
# If the current testing setup is not suitable for running a
# self-test, then return an empty string.
@@ -136,23 +134,7 @@ proc selftest_prepare {} {
return
}
- # Run the test with self. Copy the file executable file in case
- # this OS doesn't like to edit its own text space.
-
- set gdb_fullpath [_selftest_find_gdb $::GDB]
-
- if {[is_remote host]} {
- set xgdb x$::tool
- } else {
- set xgdb [standard_output_file x$::tool]
- }
-
- # Remove any old copy lying around.
- remote_file host delete $xgdb
-
- set filename [remote_download host $gdb_fullpath $xgdb]
-
- return $filename
+ return [_selftest_find_gdb $::GDB]
}
# A simple way to run some self-tests.
@@ -176,7 +158,6 @@ proc do_self_tests {body} {
}
gdb_exit
- catch "remote_file host delete $file"
if {$result == -1} {
warning "Couldn't test self"