Subversion Repositories or1k

This is gdb.info, produced by makeinfo version 4.1 from ./gdb.texinfo.

INFO-DIR-SECTION Programming & development tools.

START-INFO-DIR-ENTRY

* Gdb: (gdb).                     The GNU debugger.

END-INFO-DIR-ENTRY

   This file documents the GNU debugger GDB.

   This is the Ninth Edition, December 2001, of `Debugging with GDB:

the GNU Source-Level Debugger' for GDB Version 5.3.

   Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,

1998,

1999, 2000, 2001, 2002 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.1 or

any later version published by the Free Software Foundation; with the

Invariant Sections being "Free Software" and "Free Software Needs Free

Documentation", with the Front-Cover Texts being "A GNU Manual," and

with the Back-Cover Texts as in (a) below.

   (a) The Free Software Foundation's Back-Cover Text is: "You have

freedom to copy and modify this GNU Manual, like GNU software.  Copies

published by the Free Software Foundation raise funds for GNU

development."

File: gdb.info,  Node: Assignment,  Next: Jumping,  Up: Altering

Assignment to variables

=======================

   To alter the value of a variable, evaluate an assignment expression.

*Note Expressions: Expressions.  For example,

     print x=4

stores the value 4 into the variable `x', and then prints the value of

the assignment expression (which is 4).  *Note Using GDB with Different

Languages: Languages, for more information on operators in supported

languages.

   If you are not interested in seeing the value of the assignment, use

the `set' command instead of the `print' command.  `set' is really the

same as `print' except that the expression's value is not printed and

is not put in the value history (*note Value history: Value History.).

The expression is evaluated only for its effects.

   If the beginning of the argument string of the `set' command appears

identical to a `set' subcommand, use the `set variable' command instead

of just `set'.  This command is identical to `set' except for its lack

of subcommands.  For example, if your program has a variable `width',

you get an error if you try to set a new value with just `set

width=13', because GDB has the command `set width':

     (gdb) whatis width

     type = double

     (gdb) p width

     $4 = 13

     (gdb) set width=47

     Invalid syntax in expression.

The invalid expression, of course, is `=47'.  In order to actually set

the program's variable `width', use

     (gdb) set var width=47

   Because the `set' command has many subcommands that can conflict

with the names of program variables, it is a good idea to use the `set

variable' command instead of just `set'.  For example, if your program

has a variable `g', you run into problems if you try to set a new value

with just `set g=4', because GDB has the command `set gnutarget',

abbreviated `set g':

     (gdb) whatis g

     type = double

     (gdb) p g

     $1 = 1

     (gdb) set g=4

     (gdb) p g

     $2 = 1

     (gdb) r

     The program being debugged has been started already.

     Start it from the beginning? (y or n) y

     Starting program: /home/smith/cc_progs/a.out

     "/home/smith/cc_progs/a.out": can't open to read symbols:

                                      Invalid bfd target.

     (gdb) show g

     The current BFD target is "=4".

The program variable `g' did not change, and you silently set the

`gnutarget' to an invalid value.  In order to set the variable `g', use

     (gdb) set var g=4

   GDB allows more implicit conversions in assignments than C; you can

freely store an integer value into a pointer variable or vice versa,

and you can convert any structure to any other structure that is the

same length or shorter.

   To store values into arbitrary places in memory, use the `{...}'

construct to generate a value of specified type at a specified address

(*note Expressions: Expressions.).  For example, `{int}0x83040' refers

to memory location `0x83040' as an integer (which implies a certain size

and representation in memory), and

     set {int}0x83040 = 4

stores the value 4 into that memory location.

File: gdb.info,  Node: Jumping,  Next: Signaling,  Prev: Assignment,  Up: Altering

Continuing at a different address

=================================

   Ordinarily, when you continue your program, you do so at the place

where it stopped, with the `continue' command.  You can instead

continue at an address of your own choosing, with the following

commands:

`jump LINESPEC'

     Resume execution at line LINESPEC.  Execution stops again

     immediately if there is a breakpoint there.  *Note Printing source

     lines: List, for a description of the different forms of LINESPEC.

     It is common practice to use the `tbreak' command in conjunction

     with `jump'.  *Note Setting breakpoints: Set Breaks.

     The `jump' command does not change the current stack frame, or the

     stack pointer, or the contents of any memory location or any

     register other than the program counter.  If line LINESPEC is in a

     different function from the one currently executing, the results

     may be bizarre if the two functions expect different patterns of

     arguments or of local variables.  For this reason, the `jump'

     command requests confirmation if the specified line is not in the

     function currently executing.  However, even bizarre results are

     predictable if you are well acquainted with the machine-language

     code of your program.

`jump *ADDRESS'

     Resume execution at the instruction at address ADDRESS.

   On many systems, you can get much the same effect as the `jump'

command by storing a new value into the register `$pc'.  The difference

is that this does not start your program running; it only changes the

address of where it _will_ run when you continue.  For example,

     set $pc = 0x485

makes the next `continue' command or stepping command execute at

address `0x485', rather than at the address where your program stopped.

*Note Continuing and stepping: Continuing and Stepping.

   The most common occasion to use the `jump' command is to back

up--perhaps with more breakpoints set--over a portion of a program that

has already executed, in order to examine its execution in more detail.

File: gdb.info,  Node: Signaling,  Next: Returning,  Prev: Jumping,  Up: Altering

Giving your program a signal

============================

`signal SIGNAL'

     Resume execution where your program stopped, but immediately give

     it the signal SIGNAL.  SIGNAL can be the name or the number of a

     signal.  For example, on many systems `signal 2' and `signal

     SIGINT' are both ways of sending an interrupt signal.

     Alternatively, if SIGNAL is zero, continue execution without

     giving a signal.  This is useful when your program stopped on

     account of a signal and would ordinary see the signal when resumed

     with the `continue' command; `signal 0' causes it to resume

     without a signal.

     `signal' does not repeat when you press  a second time after

     executing the command.

   Invoking the `signal' command is not the same as invoking the `kill'

utility from the shell.  Sending a signal with `kill' causes GDB to

decide what to do with the signal depending on the signal handling

tables (*note Signals::).  The `signal' command passes the signal

directly to your program.

File: gdb.info,  Node: Returning,  Next: Calling,  Prev: Signaling,  Up: Altering

Returning from a function

=========================

`return'

`return EXPRESSION'

     You can cancel execution of a function call with the `return'

     command.  If you give an EXPRESSION argument, its value is used as

     the function's return value.

   When you use `return', GDB discards the selected stack frame (and

all frames within it).  You can think of this as making the discarded

frame return prematurely.  If you wish to specify a value to be

returned, give that value as the argument to `return'.

   This pops the selected stack frame (*note Selecting a frame:

Selection.), and any other frames inside of it, leaving its caller as

the innermost remaining frame.  That frame becomes selected.  The

specified value is stored in the registers used for returning values of

functions.

   The `return' command does not resume execution; it leaves the

program stopped in the state that would exist if the function had just

returned.  In contrast, the `finish' command (*note Continuing and

stepping: Continuing and Stepping.) resumes execution until the

selected stack frame returns naturally.

File: gdb.info,  Node: Calling,  Next: Patching,  Prev: Returning,  Up: Altering

Calling program functions

=========================

`call EXPR'

     Evaluate the expression EXPR without displaying `void' returned

     values.

   You can use this variant of the `print' command if you want to

execute a function from your program, but without cluttering the output

with `void' returned values.  If the result is not void, it is printed

and saved in the value history.

File: gdb.info,  Node: Patching,  Prev: Calling,  Up: Altering

Patching programs

=================

   By default, GDB opens the file containing your program's executable

code (or the corefile) read-only.  This prevents accidental alterations

to machine code; but it also prevents you from intentionally patching

your program's binary.

   If you'd like to be able to patch the binary, you can specify that

explicitly with the `set write' command.  For example, you might want

to turn on internal debugging flags, or even to make emergency repairs.

`set write on'

`set write off'

     If you specify `set write on', GDB opens executable and core files

     for both reading and writing; if you specify `set write off' (the

     default), GDB opens them read-only.

     If you have already loaded a file, you must load it again (using

     the `exec-file' or `core-file' command) after changing `set

     write', for your new setting to take effect.

`show write'

     Display whether executable files and core files are opened for

     writing as well as reading.

File: gdb.info,  Node: GDB Files,  Next: Targets,  Prev: Altering,  Up: Top

GDB Files

*********

   GDB needs to know the file name of the program to be debugged, both

in order to read its symbol table and in order to start your program.

To debug a core dump of a previous run, you must also tell GDB the name

of the core dump file.

* Menu:

* Files::                       Commands to specify files

* Symbol Errors::               Errors reading symbol files

File: gdb.info,  Node: Files,  Next: Symbol Errors,  Up: GDB Files

Commands to specify files

=========================

   You may want to specify executable and core dump file names.  The

usual way to do this is at start-up time, using the arguments to GDB's

start-up commands (*note Getting In and Out of GDB: Invocation.).

   Occasionally it is necessary to change to a different file during a

GDB session.  Or you may run GDB and forget to specify a file you want

to use.  In these situations the GDB commands to specify new files are

useful.

`file FILENAME'

     Use FILENAME as the program to be debugged.  It is read for its

     symbols and for the contents of pure memory.  It is also the

     program executed when you use the `run' command.  If you do not

     specify a directory and the file is not found in the GDB working

     directory, GDB uses the environment variable `PATH' as a list of

     directories to search, just as the shell does when looking for a

     program to run.  You can change the value of this variable, for

     both GDB and your program, using the `path' command.

     On systems with memory-mapped files, an auxiliary file named

     `FILENAME.syms' may hold symbol table information for FILENAME.

     If so, GDB maps in the symbol table from `FILENAME.syms', starting

     up more quickly.  See the descriptions of the file options

     `-mapped' and `-readnow' (available on the command line, and with

     the commands `file', `symbol-file', or `add-symbol-file',

     described below), for more information.

`file'

     `file' with no argument makes GDB discard any information it has

     on both executable file and the symbol table.

`exec-file [ FILENAME ]'

     Specify that the program to be run (but not the symbol table) is

     found in FILENAME.  GDB searches the environment variable `PATH'

     if necessary to locate your program.  Omitting FILENAME means to

     discard information on the executable file.

`symbol-file [ FILENAME ]'

     Read symbol table information from file FILENAME.  `PATH' is

     searched when necessary.  Use the `file' command to get both symbol

     table and program to run from the same file.

     `symbol-file' with no argument clears out GDB information on your

     program's symbol table.

     The `symbol-file' command causes GDB to forget the contents of its

     convenience variables, the value history, and all breakpoints and

     auto-display expressions.  This is because they may contain

     pointers to the internal data recording symbols and data types,

     which are part of the old symbol table data being discarded inside

     GDB.

     `symbol-file' does not repeat if you press  again after

     executing it once.

     When GDB is configured for a particular environment, it

     understands debugging information in whatever format is the

     standard generated for that environment; you may use either a GNU

     compiler, or other compilers that adhere to the local conventions.

     Best results are usually obtained from GNU compilers; for example,

     using `gcc' you can generate debugging information for optimized

     code.

     For most kinds of object files, with the exception of old SVR3

     systems using COFF, the `symbol-file' command does not normally

     read the symbol table in full right away.  Instead, it scans the

     symbol table quickly to find which source files and which symbols

     are present.  The details are read later, one source file at a

     time, as they are needed.

     The purpose of this two-stage reading strategy is to make GDB

     start up faster.  For the most part, it is invisible except for

     occasional pauses while the symbol table details for a particular

     source file are being read.  (The `set verbose' command can turn

     these pauses into messages if desired.  *Note Optional warnings

     and messages: Messages/Warnings.)

     We have not implemented the two-stage strategy for COFF yet.  When

     the symbol table is stored in COFF format, `symbol-file' reads the

     symbol table data in full right away.  Note that "stabs-in-COFF"

     still does the two-stage strategy, since the debug info is actually

     in stabs format.

`symbol-file FILENAME [ -readnow ] [ -mapped ]'

`file FILENAME [ -readnow ] [ -mapped ]'

     You can override the GDB two-stage strategy for reading symbol

     tables by using the `-readnow' option with any of the commands that

     load symbol table information, if you want to be sure GDB has the

     entire symbol table available.

     If memory-mapped files are available on your system through the

     `mmap' system call, you can use another option, `-mapped', to

     cause GDB to write the symbols for your program into a reusable

     file.  Future GDB debugging sessions map in symbol information

     from this auxiliary symbol file (if the program has not changed),

     rather than spending time reading the symbol table from the

     executable program.  Using the `-mapped' option has the same

     effect as starting GDB with the `-mapped' command-line option.

     You can use both options together, to make sure the auxiliary

     symbol file has all the symbol information for your program.

     The auxiliary symbol file for a program called MYPROG is called

     `MYPROG.syms'.  Once this file exists (so long as it is newer than

     the corresponding executable), GDB always attempts to use it when

     you debug MYPROG; no special options or commands are needed.

     The `.syms' file is specific to the host machine where you run

     GDB.  It holds an exact image of the internal GDB symbol table.

     It cannot be shared across multiple host platforms.

`core-file [ FILENAME ]'

     Specify the whereabouts of a core dump file to be used as the

     "contents of memory".  Traditionally, core files contain only some

     parts of the address space of the process that generated them; GDB

     can access the executable file itself for other parts.

     `core-file' with no argument specifies that no core file is to be

     used.

     Note that the core file is ignored when your program is actually

     running under GDB.  So, if you have been running your program and

     you wish to debug a core file instead, you must kill the

     subprocess in which the program is running.  To do this, use the

     `kill' command (*note Killing the child process: Kill Process.).

`add-symbol-file FILENAME ADDRESS'

`add-symbol-file FILENAME ADDRESS [ -readnow ] [ -mapped ]'

`add-symbol-file FILENAME -sSECTION ADDRESS ...'

     The `add-symbol-file' command reads additional symbol table

     information from the file FILENAME.  You would use this command

     when FILENAME has been dynamically loaded (by some other means)

     into the program that is running.  ADDRESS should be the memory

     address at which the file has been loaded; GDB cannot figure this

     out for itself.  You can additionally specify an arbitrary number

     of `-sSECTION ADDRESS' pairs, to give an explicit section name and

     base address for that section.  You can specify any ADDRESS as an

     expression.

     The symbol table of the file FILENAME is added to the symbol table

     originally read with the `symbol-file' command.  You can use the

     `add-symbol-file' command any number of times; the new symbol data

     thus read keeps adding to the old.  To discard all old symbol data

     instead, use the `symbol-file' command without any arguments.

     Although FILENAME is typically a shared library file, an

     executable file, or some other object file which has been fully

     relocated for loading into a process, you can also load symbolic

     information from relocatable `.o' files, as long as:

        * the file's symbolic information refers only to linker symbols

          defined in that file, not to symbols defined by other object

          files,

        * every section the file's symbolic information refers to has

          actually been loaded into the inferior, as it appears in the

          file, and

        * you can determine the address at which every section was

          loaded, and provide these to the `add-symbol-file' command.

     Some embedded operating systems, like Sun Chorus and VxWorks, can

     load relocatable files into an already running program; such

     systems typically make the requirements above easy to meet.

     However, it's important to recognize that many native systems use

     complex link procedures (`.linkonce' section factoring and C++

     constructor table assembly, for example) that make the

     requirements difficult to meet.  In general, one cannot assume

     that using `add-symbol-file' to read a relocatable object file's

     symbolic information will have the same effect as linking the

     relocatable object file into the program in the normal way.

     `add-symbol-file' does not repeat if you press  after using

     it.

     You can use the `-mapped' and `-readnow' options just as with the

     `symbol-file' command, to change how GDB manages the symbol table

     information for FILENAME.

`add-shared-symbol-file'

     The `add-shared-symbol-file' command can be used only under

     Harris' CXUX operating system for the Motorola 88k.  GDB

     automatically looks for shared libraries, however if GDB does not

     find yours, you can run `add-shared-symbol-file'.  It takes no

     arguments.

`section'

     The `section' command changes the base address of section SECTION

     of the exec file to ADDR.  This can be used if the exec file does

     not contain section addresses, (such as in the a.out format), or

     when the addresses specified in the file itself are wrong.  Each

     section must be changed separately.  The `info files' command,

     described below, lists all the sections and their addresses.

`info files'

`info target'

     `info files' and `info target' are synonymous; both print the

     current target (*note Specifying a Debugging Target: Targets.),

     including the names of the executable and core dump files

     currently in use by GDB, and the files from which symbols were

     loaded.  The command `help target' lists all possible targets

     rather than current ones.

`maint info sections'

     Another command that can give you extra information about program

     sections is `maint info sections'.  In addition to the section

     information displayed by `info files', this command displays the

     flags and file offset of each section in the executable and core

     dump files.  In addition, `maint info sections' provides the

     following command options (which may be arbitrarily combined):

    `ALLOBJ'

          Display sections for all loaded object files, including

          shared libraries.

    `SECTIONS'

          Display info only for named SECTIONS.

    `SECTION-FLAGS'

          Display info only for sections for which SECTION-FLAGS are

          true.  The section flags that GDB currently knows about are:

         `ALLOC'

               Section will have space allocated in the process when

               loaded.  Set for all sections except those containing

               debug information.

         `LOAD'

               Section will be loaded from the file into the child

               process memory.  Set for pre-initialized code and data,

               clear for `.bss' sections.

         `RELOC'

               Section needs to be relocated before loading.

         `READONLY'

               Section cannot be modified by the child process.

         `CODE'

               Section contains executable code only.

         `DATA'

               Section contains data only (no executable code).

         `ROM'

               Section will reside in ROM.

         `CONSTRUCTOR'

               Section contains data for constructor/destructor lists.

         `HAS_CONTENTS'

               Section is not empty.

         `NEVER_LOAD'

               An instruction to the linker to not output the section.

         `COFF_SHARED_LIBRARY'

               A notification to the linker that the section contains

               COFF shared library information.

         `IS_COMMON'

               Section contains common symbols.

`set trust-readonly-sections on'

     Tell GDB that readonly sections in your object file really are

     read-only (i.e. that their contents will not change).  In that

     case, GDB can fetch values from these sections out of the object

     file, rather than from the target program.  For some targets

     (notably embedded ones), this can be a significant enhancement to

     debugging performance.

     The default is off.

`set trust-readonly-sections off'

     Tell GDB not to trust readonly sections.  This means that the

     contents of the section might change while the program is running,

     and must therefore be fetched from the target when needed.

   All file-specifying commands allow both absolute and relative file

names as arguments.  GDB always converts the file name to an absolute

file name and remembers it that way.

   GDB supports HP-UX, SunOS, SVr4, Irix 5, and IBM RS/6000 shared

libraries.

   GDB automatically loads symbol definitions from shared libraries

when you use the `run' command, or when you examine a core file.

(Before you issue the `run' command, GDB does not understand references

to a function in a shared library, however--unless you are debugging a

core file).

   On HP-UX, if the program loads a library explicitly, GDB

automatically loads the symbols at the time of the `shl_load' call.

   There are times, however, when you may wish to not automatically load

symbol definitions from shared libraries, such as when they are

particularly large or there are many of them.

   To control the automatic loading of shared library symbols, use the

commands:

`set auto-solib-add MODE'

     If MODE is `on', symbols from all shared object libraries will be

     loaded automatically when the inferior begins execution, you

     attach to an independently started inferior, or when the dynamic

     linker informs GDB that a new library has been loaded.  If MODE is

     `off', symbols must be loaded manually, using the `sharedlibrary'

     command.  The default value is `on'.

`show auto-solib-add'

     Display the current autoloading mode.

   To explicitly load shared library symbols, use the `sharedlibrary'

command:

`info share'

`info sharedlibrary'

     Print the names of the shared libraries which are currently loaded.

`sharedlibrary REGEX'

`share REGEX'

     Load shared object library symbols for files matching a Unix

     regular expression.  As with files loaded automatically, it only

     loads shared libraries required by your program for a core file or

     after typing `run'.  If REGEX is omitted all shared libraries

     required by your program are loaded.

   On some systems, such as HP-UX systems, GDB supports autoloading

shared library symbols until a limiting threshold size is reached.

This provides the benefit of allowing autoloading to remain on by

default, but avoids autoloading excessively large shared libraries, up

to a threshold that is initially set, but which you can modify if you

wish.

   Beyond that threshold, symbols from shared libraries must be

explicitly loaded.  To load these symbols, use the command

`sharedlibrary FILENAME'.  The base address of the shared library is

determined automatically by GDB and need not be specified.

   To display or set the threshold, use the commands:

`set auto-solib-limit THRESHOLD'

     Set the autoloading size threshold, in an integral number of

     megabytes.  If THRESHOLD is nonzero and shared library autoloading

     is enabled, symbols from all shared object libraries will be

     loaded until the total size of the loaded shared library symbols

     exceeds this threshold.  Otherwise, symbols must be loaded

     manually, using the `sharedlibrary' command.  The default

     threshold is 100 (i.e. 100 Mb).

`show auto-solib-limit'

     Display the current autoloading size threshold, in megabytes.

File: gdb.info,  Node: Symbol Errors,  Prev: Files,  Up: GDB Files

Errors reading symbol files

===========================

   While reading a symbol file, GDB occasionally encounters problems,

such as symbol types it does not recognize, or known bugs in compiler

output.  By default, GDB does not notify you of such problems, since

they are relatively common and primarily of interest to people

debugging compilers.  If you are interested in seeing information about

ill-constructed symbol tables, you can either ask GDB to print only one

message about each such type of problem, no matter how many times the

problem occurs; or you can ask GDB to print more messages, to see how

many times the problems occur, with the `set complaints' command (*note

Optional warnings and messages: Messages/Warnings.).

   The messages currently printed, and their meanings, include:

`inner block not inside outer block in SYMBOL'

     The symbol information shows where symbol scopes begin and end

     (such as at the start of a function or a block of statements).

     This error indicates that an inner scope block is not fully

     contained in its outer scope blocks.

     GDB circumvents the problem by treating the inner block as if it

     had the same scope as the outer block.  In the error message,

     SYMBOL may be shown as "`(don't know)'" if the outer block is not a

     function.

`block at ADDRESS out of order'

     The symbol information for symbol scope blocks should occur in

     order of increasing addresses.  This error indicates that it does

     not do so.

     GDB does not circumvent this problem, and has trouble locating

     symbols in the source file whose symbols it is reading.  (You can

     often determine what source file is affected by specifying `set

     verbose on'.  *Note Optional warnings and messages:

     Messages/Warnings.)

`bad block start address patched'

     The symbol information for a symbol scope block has a start address

     smaller than the address of the preceding source line.  This is

     known to occur in the SunOS 4.1.1 (and earlier) C compiler.

     GDB circumvents the problem by treating the symbol scope block as

     starting on the previous source line.

`bad string table offset in symbol N'

     Symbol number N contains a pointer into the string table which is

     larger than the size of the string table.

     GDB circumvents the problem by considering the symbol to have the

     name `foo', which may cause other problems if many symbols end up

     with this name.

`unknown symbol type `0xNN''

     The symbol information contains new data types that GDB does not

     yet know how to read.  `0xNN' is the symbol type of the

     uncomprehended information, in hexadecimal.

     GDB circumvents the error by ignoring this symbol information.

     This usually allows you to debug your program, though certain

     symbols are not accessible.  If you encounter such a problem and

     feel like debugging it, you can debug `gdb' with itself, breakpoint

     on `complain', then go up to the function `read_dbx_symtab' and

     examine `*bufp' to see the symbol.

`stub type has NULL name'

     GDB could not find the full definition for a struct or class.

`const/volatile indicator missing (ok if using g++ v1.x), got...'

     The symbol information for a C++ member function is missing some

     information that recent versions of the compiler should have

     output for it.

`info mismatch between compiler and debugger'

     GDB could not parse a type specification output by the compiler.

File: gdb.info,  Node: Targets,  Next: Remote Debugging,  Prev: GDB Files,  Up: Top

Specifying a Debugging Target

*****************************

   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 (*note Commands for managing targets:

Target Commands.).

* Menu:

* Active Targets::              Active targets

* Target Commands::             Commands for managing targets

* Byte Order::                  Choosing target byte order

* Remote::                      Remote debugging

* KOD::                         Kernel Object Display

File: gdb.info,  Node: Active Targets,  Next: Target Commands,  Up: Targets

Active targets

==============

   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 (*note Commands to specify files: Files.).

To specify as a target a process that is already running, use the

`attach' command (*note Debugging an already-running process: Attach.).

File: gdb.info,  Node: Target Commands,  Next: Byte Order,  Prev: Active Targets,  Up: Targets

Commands for managing targets

=============================

`target TYPE PARAMETERS'

     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.

     The `target' command does not repeat if you press  again

     after executing the command.

`help target'

     Displays the names of all targets available.  To display targets

     currently selected, use either `info target' or `info files'

     (*note Commands to specify files: Files.).

`help target NAME'

     Describe a particular target, including any parameters necessary to

     select it.

`set gnutarget ARGS'

     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.  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.

     *Note Commands to specify files: Files.

`show gnutarget'

     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"'.

   Here are some common targets (available, or not, depending on the GDB

configuration):

`target exec PROGRAM'

     An executable file.  `target exec PROGRAM' is the same as

     `exec-file PROGRAM'.

`target core FILENAME'

     A core dump file.  `target core FILENAME' is the same as

     `core-file FILENAME'.

`target remote DEV'

     Remote serial target in GDB-specific protocol.  The argument DEV

     specifies what serial device to use for the connection (e.g.

     `/dev/ttya'). *Note Remote debugging: Remote.  `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'

     Builtin CPU simulator.  GDB includes simulators for most

     architectures.  In general,

                  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 *Note Embedded Processors: Embedded Processors.

   Some configurations may include these targets as well:

`target nrom DEV'

     NetROM ROM emulator.  This target only supports downloading.

   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'

     Depending on what remote debugging facilities are configured into

     GDB, the `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  again after using it.

File: gdb.info,  Node: Byte Order,  Next: Remote,  Prev: Target Commands,  Up: Targets

Choosing target byte order

==========================

   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'

     Instruct GDB to assume the target is big-endian.

`set endian little'

     Instruct GDB to assume the target is little-endian.

`set endian auto'

     Instruct GDB to use the byte order associated with the executable.

`show endian'

     Display GDB's current idea of the target byte order.

   Note that these commands merely adjust interpretation of symbolic

data on the host, and that they have absolutely no effect on the target

system.

File: gdb.info,  Node: Remote,  Next: KOD,  Prev: Byte Order,  Up: Targets

Remote debugging

================

   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.

File: gdb.info,  Node: KOD,  Prev: Remote,  Up: Targets

Kernel Object Display

=====================

   Some targets support kernel object display.  Using this facility,