[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A target is the execution environment occupied by your program.
Often, GDB runs in the same host environment as your program;
in that case, the debugging target is specified as a side effect when
you use the file
or core
commands. When you need more
flexibility--for example, running GDB on a physically separate
host, or controlling a standalone system over a serial port or a
realtime system over a TCP/IP connection--you can use the target
command to specify one of the target types configured for GDB
(see section Commands for managing targets).
15.1 Active targets 15.2 Commands for managing targets 15.3 Choosing target byte order 15.4 Remote debugging 15.5 Kernel Object Display
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are three classes of targets: processes, core files, and executable files. GDB can work concurrently on up to three active targets, one in each class. This allows you to (for example) start a process and inspect its activity without abandoning your work on a core file.
For example, if you execute `gdb a.out', then the executable file
a.out
is the only active target. If you designate a core file as
well--presumably from a prior run that crashed and coredumped--then
GDB has two active targets and uses them in tandem, looking
first in the corefile target, then in the executable file, to satisfy
requests for memory addresses. (Typically, these two classes of target
are complementary, since core files contain only a program's
read-write memory--variables and so on--plus machine status, while
executable files contain only the program text and initialized data.)
When you type run
, your executable file becomes an active process
target as well. When a process target is active, all GDB
commands requesting memory addresses refer to that target; addresses in
an active core file or executable file target are obscured while the
process target is active.
Use the core-file
and exec-file
commands to select a new
core file or executable target (see section Commands to specify files). To specify as a target a process that is already running, use
the attach
command (see section Debugging an already-running process).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
target type parameters
Further parameters are interpreted by the target protocol, but typically include things like device names or host names to connect with, process numbers, and baud rates.
The target
command does not repeat if you press RET again
after executing the command.
help target
info target
or info files
(see section Commands to specify files).
help target name
set gnutarget args
set gnutarget
command. Unlike most target
commands,
with gnutarget
the target
refers to a program, not a machine.
Warning: To specify a file format with set gnutarget
,
you must know the actual BFD name.
See section Commands to specify files.
show gnutarget
show gnutarget
command to display what file format
gnutarget
is set to read. If you have not set gnutarget
,
GDB will determine the file format for each file automatically,
and show gnutarget
displays `The current BDF target is "auto"'.
Here are some common targets (available, or not, depending on the GDB configuration):
target exec program
target core filename
target remote dev
target remote
supports the load
command. This is only useful if you have
some other way of getting the stub to the target system, and you can put
it somewhere in memory where it won't get clobbered by the download.
target sim
target sim load run |
Some configurations may include these targets as well:
target nrom dev
Different targets are available on different configurations of GDB; your configuration may have more or fewer targets.
Many remote targets require you to download the executable's code once you've successfully established a connection.
load filename
load
command may be available. Where it exists, it
is meant to make filename (an executable) available for debugging
on the remote system--by downloading, or dynamic linking, for example.
load
also records the filename symbol table in GDB, like
the add-symbol-file
command.
If your GDB does not have a load
command, attempting to
execute it gets the error message "You can't do that when your
target is ...
"
The file is loaded at whatever address is specified in the executable. For some object file formats, you can specify the load address when you link the program; for other formats, like a.out, the object file format specifies a fixed address.
load
does not repeat if you press RET again after using it.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some types of processors, such as the MIPS, PowerPC, and Hitachi SH, offer the ability to run either big-endian or little-endian byte orders. Usually the executable or symbol will include a bit to designate the endian-ness, and you will not need to worry about which to use. However, you may still find it useful to adjust GDB's idea of processor endian-ness manually.
set endian big
set endian little
set endian auto
show endian
Note that these commands merely adjust interpretation of symbolic data on the host, and that they have absolutely no effect on the target system.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you are trying to debug a program running on a machine that cannot run GDB in the usual way, it is often useful to use remote debugging. For example, you might use remote debugging on an operating system kernel, or on a small system which does not have a general purpose operating system powerful enough to run a full-featured debugger.
Some configurations of GDB have special serial or TCP/IP interfaces to make this work with particular debugging targets. In addition, GDB comes with a generic serial protocol (specific to GDB, but not specific to any particular target system) which you can use if you write the remote stubs--the code that runs on the remote system to communicate with GDB.
Other remote targets may be available in your
configuration of GDB; use help target
to list them.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some targets support kernel object display. Using this facility, GDB communicates specially with the underlying operating system and can display information about operating system-level objects such as mutexes and other synchronization objects. Exactly which objects can be displayed is determined on a per-OS basis.
Use the set os
command to set the operating system. This tells
GDB which kernel object display module to initialize:
(gdb) set os cisco |
If set os
succeeds, GDB will display some information
about the operating system, and will create a new info
command
which can be used to query the target. The info
command is named
after the operating system:
(gdb) info cisco List of Cisco Kernel Objects Object Description any Any and all objects |
Further subcommands can be used to query about particular objects known by the kernel.
There is currently no way to determine whether a given operating system is supported other than to try it.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Please send FSF & GNU inquiries & questions to [email protected]. There are also other ways to contact the FSF.
These pages are maintained by the GDB developers.
Copyright Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
This document was generated by GDB Administrator on March, 29 2002 using texi2html