Debugger (GNU)
gdb_variant [options] [executable] [ core_file | pid ]
QNX Neutrino, Linux, Microsoft Windows
The gdb_variant depends on the target platform, as follows:
Target platform: | gdb_variant: |
---|---|
ARM | ntoarm-gdb |
MIPS | ntomips-gdb |
PowerPC | ntoppc-gdb |
SH4 | ntosh-gdb |
x86 | ntox86-gdb |
The options are:
Batch mode may be useful for running gdb as a filter, for example to download and run a program on another computer. To make this more useful, the message:
Program exited normally.
(which is ordinarily issued whenever a program running under gdb control terminates) isn't issued when running in batch mode.
This option depends on operating system facilities that aren't supported on all systems. |
If memory-mapped files are available on your system through the mmap() system call, you can use this option to have gdb write the symbols from your program into a reusable file in the current directory.
For example, if the program you're debugging is called /tmp/fred, the mapped symbol file is ./fred.syms. Future gdb debugging sessions notice the presence of this file, and can quickly map in symbol information from it, rather than read the symbol table from the executable program.
The .syms file is specific to the host machine where gdb is run. It holds an exact image of the internal gdb symbol table. It can't be shared across multiple host platforms.
For more information on initialization files, see “Command files” in the full online GNU documentation.
The -mapped and -readnow options are typically combined in order to build a .syms file that contains complete symbol information. (For more information, see “Commands to specify files” in the full online GNU documentation.)
Here's how you can build a .syms file for future use:
gdb -batch -nx -mapped -readnow programname
Invoke the GNU Debugger by running gdb. Once started, gdb reads commands from the terminal until you tell it to exit.
If you start gdb from the command line on a self-hosted QNX Neutrino system, gdb sets the LD_BIND_NOW to 1 to force all binding to be done immediately instead of lazily. For more information, see “Optimizing the runtime linker” in the Compiling and Debugging chapter of the QNX Neutrino Programmer's Guide. |
You can abbreviate a gdb command to the first few letters of the command name, if that abbreviation is unambiguous; and you can repeat certain gdb commands by typing just Enter. You can also use the Tab key to get gdb to fill out the rest of a word in a command (or to show you the alternatives available, if there's more than one possibility).
You can also run gdb with a variety of arguments and options, to specify more of your debugging environment at the outset.
Unless you specify the -nx option, this utility runs commands in an initialization file before running any command-line options. This file may be specific to the gdb_variant invoked, for instance, if you invoke ntoppc-gdb, the utility runs the commands in the ${HOME}/.ntoppc-gdbinit file. If no such gdb_variant initialization file exists, the utility runs commands found in the generic ${HOME}/.gdbinit file instead. If you specify -command, file overrides these default files.
The command-line options described here are designed to cover a variety of situations; in some environments, some of these options might not work.
You can start with both an executable program and a core file specified:
gdb program core
GNU
Using GDB in the QNX Neutrino Programmer's Guide