diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2025-08-06 15:28:16 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2025-08-27 15:57:29 -0400 |
commit | 15b3c1756339dfc00c61a8ad1390222ce4bbca4f (patch) | |
tree | 0348714f0d0310fcb1ff2154b601cce0d84ede9d | |
parent | 2f339e5ca03c5a89cf333d0cf090e3718d76f113 (diff) | |
download | binutils-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.exp | 23 |
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" |