mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-11-16 12:34:43 +00:00
0a91f1a8aa
This commit allows GDB to make use of the file set with the 'file'
command when starting a new inferior on an extended-remote target.
There are however some restrictions.
If the user has used 'set remote exec-file', then this setting is
always used in preference to the file set with the 'file' command.
Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
that the remote target has an executable set, then this will be used
in preference to the file set with the 'file' command; this preserves
GDB's existing behaviour. In effect, when GDB connects to the remote
target, the remote sets the 'remote exec-file' and this prevents GDB
from using the 'file' filename.
And, GDB can only use the file set with the 'file' command if it
believes that both GDB and the remote target will both be able to
access this file. This means that one of these is true:
+ the the remote_target::filesystem_is_local function returns
true (see the implementation of that function for details of when
this can happen). This means GDB and the remote target can see
the same file system, GDB can just use the current executable's
filename as is, or
+ the user has set the 'file' to something with a 'target:' prefix,
e.g. 'file target:/path/to/exec'. In this last case, GDB will use
the exec filename without the 'target:' prefix, this filename is,
by definition, something the remote target can see, or
+ the sysroot has been updated by the user and no longer contains a
'target:' prefix. In this case, if the 'file' filename is within
the sysroot, then it is assumed the remote will also be able to
see a file with the same filename. For example, if the sysroot is
'/aa/', and the current executable is '/aa/bb/cc', then GDB will
tell the remote to run '/bb/cc'. One common case here is when the
sysroot is set to the empty string, which is usually done when GDB
and the remote target can see the same filesystem, in this case
GDB will use the current executable's filename unmodified.
If one of these conditions is met, then GDB will use the current
executable's filename (with possible modifications as mentioned
above), when starting a new extended-remote inferior, in all other
cases, GDB will use the file name set with 'set remote exec-file'.
This change could be useful any time a user is running a remote target
on the same machine as GDB, but I am specifically thinking of the case
where GDB is using a tool other than gdbserver, e.g. valgrind, as this
saves one additional step that a user must remember. The current
steps to start valgrind with GDB, as given on the valgrind
website (https://valgrind.org/docs/manual/manual-core-adv.html) are:
$ gdb prog
(gdb) set remote exec-file prog
(gdb) set sysroot /
(gdb) target extended-remote | vgdb --multi --vargs -q
(gdb) start
With this GDB work, and once support for the qExecAndArgs packet is
added to valgrind, then the 'set remote exec-file' line can be dropped
from those instructions.
This commit also extends the 'show remote exec-file' command so that
GDB will display the automatic value that it plans to use. Here's an
example of the new output:
$ gdb -q /tmp/hello
Reading symbols from /tmp/hello...
(gdb) set sysroot
(gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
Remote debugging using | ./gdbserver/gdbserver --multi --once -
Remote debugging using stdio
(gdb) show remote exec-file
The remote exec-file is unset, using automatic value "/tmp/hello".
The last line shows the new output.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README, and so on. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.