Commands for managing targets
Further
The
Unlike most
Warning:
The following are some common targets (available, or not, depending on the GDB
configuration).
Different targets are available on different configurations of GDB; your
configuration may have more or fewer 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.
Displays the names of all targets available. To display targets currently
selected, use either info target or 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 with the set gnutarget command.
To specify a file format with
Use the 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".”
An executable file. ‘target exec program’ is the same as ‘exec-file program’.
A core dump file. ‘target core filename’ is the same as ‘core-file filename’.
Remote serial target in GDB-specific protocol. The argument, dev, specifies what serial device to use for the connection (e.g., ‘/dev/ttya’). See Remote debugging. target remote now 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.
CPU simulator. See Simulated CPU Target.
Remote AMD29K target, using the AMD UDI protocol. The keyword argument specifies which 29K board or simulator to use. See The UDI protocol for AMD29K.
Remote PC-resident AMD EB29K board, attached over serial lines. dev is the serial device, as for target remote; speed allows you to specify the linespeed; and PROG is the name of the program to be debugged, as it appears to DOS on the PC.
See The EBMON protocol for AMD29K.
A Hitachi SH, H8/300, or H8/500 board, attached via serial line to your host. Use special commands, device and speed, to control the serial line and the communications speed used. See GDB and Hitachi Microprocessors.
An Intel 960 board controlled by a Nindy Monitor. device-name is the name of the serial device to use for the connection, e.g. ‘/dev/ttya’. See GDB with a remote i960 (Nindy).
A Tandem ST2000 phone switch, running Tandem’s STD-BUG protocol. dev is the name of the device attached to the ST2000 serial line; speed is the communication line speed. The arguments are not used if GDB is
configured to connect to the ST2000 using TCP or Telnet. See GDB with a Tandem ST2000.
A VxWorks system, attached via TCP/IP. The argument, machinename, is the target system’s machine name or IP address. See GDB and VxWorks.
CPU32BUG monitor, running on a CPU32 (M68K) board.
OP50N monitor, running on an OKI HPPA board.
W89K monitor, running on a Winbond HPPA board.
EST-300 ICE monitor, running on a CPU32 (M68K) board.
ROM 68K monitor, running on an IDP board.
Array Tech LSI33K RAID controller board.
Fujitsu sparclite boards, used only for the purpose of loading. You must use
an additional command to debug the program. For example: target remote dev using GDB standard remote protocol.