1. Summary

1.1 Requirements
1.2 Contributors

1.1 Requirements

Before diving into the internals, you should understand the formal requirements and other expectations for GDB. Although some of these may seem obvious, there have been proposals for GDB that have run counter to these requirements.

First of all, GDB is a debugger. It's not designed to be a front panel for embedded systems. It's not a text editor. It's not a shell. It's not a programming environment.

GDB is an interactive tool. Although a batch mode is available, GDB's primary role is to interact with a human programmer.

GDB should be responsive to the user. A programmer hot on the trail of a nasty bug, and operating under a looming deadline, is going to be very impatient of everything, including the response time to debugger commands.

GDB should be relatively permissive, such as for expressions. While the compiler should be picky (or have the option to be made picky), since source code lives for a long time usually, the programmer doing debugging shouldn't be spending time figuring out to mollify the debugger.

GDB will be called upon to deal with really large programs. Executable sizes of 50 to 100 megabytes occur regularly, and we've heard reports of programs approaching 1 gigabyte in size.

GDB should be able to run everywhere. No other debugger is available for even half as many configurations as GDB supports.

1.2 Contributors

The first edition of this document was written by John Gilmore of Cygnus Solutions. The current second edition was written by Stan Shebs of Cygnus Solutions, who continues to update the manual.

Over the years, many others have made additions and changes to this document. This section attempts to record the significant contributors to that effort. One of the virtues of free software is that everyone is free to contribute to it; with regret, we cannot actually acknowledge everyone here.

Plea: This section has only been added relatively recently (four years after publication of the second edition). Additions to this section are particularly welcome. If you or your friends (or enemies, to be evenhanded) have been unfairly omitted from this list, we would like to add your names!

A document such as this relies on being kept up to date by numerous small updates by contributing engineers as they make changes to the code base. The file `ChangeLog' in the GDB distribution approximates a blow-by-blow account. The most prolific contributors to this important, but low profile task are Andrew Cagney (responsible for over half the entries), Daniel Jacobowitz, Mark Kettenis, Jim Blandy and Eli Zaretskii.

Eli Zaretskii and Daniel Jacobowitz wrote the sections documenting watchpoints.

Jeremy Bennett updated the sections on initializing a new architecture and register representation, and added the section on Frame Interpretation.