From: Simon Marchi <simon.marchi@polymtl.ca>
Date: Wed, 6 Aug 2025 19:28:16 +0000 (-0400)
Subject: gdb/testsuite: do not copy gdb executable in self tests
X-Git-Tag: gdb-17-branchpoint~154
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=15b3c1756339dfc00c61a8ad1390222ce4bbca4f;p=thirdparty%2Fbinutils-gdb.git

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>
---

diff --git a/gdb/testsuite/lib/selftest-support.exp b/gdb/testsuite/lib/selftest-support.exp
index 1a042e13110..eb31b55b6ec 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"