]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target
authorTom de Vries <tdevries@suse.de>
Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)
committerTom de Vries <tdevries@suse.de>
Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)
commit3581f5e4f7c903b53e25c5b8840fa4771ca139aa
treee547ba3c3739b495be71f7848966f56096979c15
parentbf0e35375461ef2a17e2872e7f5c1446a5924b64
[gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target

Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
remote-gdbserver-on-localhost.

The problem is here:
...
       set target_exec [gdb_remote_download target $binfile.bak $binfile]
...
A "gdb_remote_download target" copies from build to target.  So $binfile is
assumed to be a target path, but it's actually a build path.

Fix this by:
- fist copying $binfile.bak to $binfile, and
- simply doing [gdb_remote_download target $binfile].

Then, $binfile.bak is created here:
...
 # Make sure we have the original symbol file in a safe place to copy from.
 gdb_remote_download host $binfile $binfile.bak
...
and since "gdb_remote_download host" copies from build to host, $binfile.bak
is assumed to be a host path, but it's actually a build path.  This happens to
cause no problems in this configuration (because build == host), but it would
for a remote host configuration.

So let's fix this by making build rather than host the "safe place to copy
from".

Tested on x86_64-linux.
gdb/testsuite/gdb.server/connect-with-no-symbol-file.exp