19.2 Commands for Managing Targets
- Connects the gdb host environment to a target machine or
process. A target is typically a protocol for talking to debugging
facilities. You use the argument type to specify the type or
protocol of the target machine.
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.
targetcommand does not repeat if you press <RET> again after executing the command.
- Displays the names of all targets available. To display targets
currently selected, use either
info files(see Commands to Specify Files).
- Describe a particular target, including any parameters necessary to select it.
- gdb uses its own library BFD to read your files. gdb
knows whether it is reading an executable,
a core, or a .o file; however, you can specify the file format
set gnutargetcommand. Unlike most
targetrefers to a program, not a machine.
Warning: To specify a file format with
set gnutarget, you must know the actual BFD name.
- Use the
show gnutargetcommand to display what file format
gnutargetis set to read. If you have not set
gnutarget, gdb will determine the file format for each file automatically, and
show gnutargetdisplays The current BDF target is "auto".
- An executable file. target exec program is the same as
- A core dump file. target core filename is the same as
- A remote system connected to gdb via a serial line or network
connection. This command tells gdb to use its own remote
protocol over medium for debugging. See Remote Debugging.
For example, if you have a board connected to /dev/ttya on the machine running gdb, you could say:
target remote /dev/ttya
target remotesupports the
loadcommand. 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.
- Builtin CPU simulator. gdb includes simulators for most architectures.
target sim load run
works; however, you cannot assume that a specific memory map, device drivers, or even basic I/O is available, although some simulators do provide these. For info about any processor-specific simulator details, see the appropriate section in Embedded Processors.
Some configurations may include these targets as well:
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. You may wish to control various aspects of this process.
- This command controls whether a hash mark # is displayed while
downloading a file to the remote monitor. If on, a hash mark is
displayed after each S-record is successfully downloaded to the
- Show the current status of displaying the hash mark.
set debug monitor
- Enable or disable display of communications messages between
gdb and the remote monitor.
show debug monitor
- Show the current status of displaying communications between gdb and the remote monitor.
Depending on what remote debugging facilities are configured into
loadcommand 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.
loadalso records the filename symbol table in gdb, like the
If your gdb does not have a
loadcommand, 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.
Depending on the remote side capabilities, gdb may be able to load programs into flash memory.
loaddoes not repeat if you press <RET> again after using it.