Go to the first, previous, next, last section, table of contents.


Invoking

Invoke by running the program . Once started, reads commands from the terminal until you tell it to exit.

You can also run with a variety of arguments and options, to specify more of your debugging environment at the outset.

The most usual way to start is with one argument, specifying an executable program:

 program

You can also start with both an executable program and a core file specified:

 program core

You can, instead, specify a process ID as a second argument, if you want to debug a running process:

 program 1234

would attach to process 1234 (unless you also have a file named `1234'; does check for a core file first).

Taking advantage of the second command-line argument requires a fairly complete operating system; when you use as a remote debugger attached to a bare board, there may not be any notion of "process", and there is often no way to get a core dump.

You can run gdb without printing the front material, which describes 's non-warranty, by specifying -silent:

 -silent

You can further control how starts up by using command-line options. itself can remind you of the options available.

Type

 -help

to display all available options and briefly describe their use (` -h' is a shorter equivalent).

All options and command line arguments you give are processed in sequential order. The order makes a difference when the `-x' option is used.

The debugging stub is specific to the architecture of the remote machine; for example, use `sparc-stub.c' to debug programs on SPARC boards. These working remote stubs are distributed with :
sparc-stub.c
For SPARC architectures.
m68k-stub.c
For Motorola 680x0 architectures.
i386-stub.c
For Intel 386 and compatible architectures.
The `README' file in the distribution may list other recently added stubs.


Go to the first, previous, next, last section, table of contents.