<HTML> <HEAD> <!-- This HTML file has been created by texi2html 1.51 from /mnt/apple/gdb/source/gdb.apple/source/gdb/gdb/doc/gdbint.texinfo on 23 November 1999 --> <TITLE>GDB Internals - Requirements</TITLE> </HEAD> <BODY> Go to the first, previous, <A HREF="gdbint_2.html">next</A>, <A HREF="gdbint_16.html">last</A> section, <A HREF="gdbint_toc.html">table of contents</A>. <P><HR><P> <H1><A NAME="SEC1" HREF="gdbint_toc.html#TOC1">Requirements</A></H1> <P> 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. </P> <P> 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. </P> <P> GDB is an interactive tool. Although a batch mode is available, GDB's primary role is to interact with a human programmer. </P> <P> 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. </P> <P> 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. </P> <P> 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. </P> <P> GDB should be able to run everywhere. No other debugger is available for even half as many configurations as GDB supports. </P> <P><HR><P> Go to the first, previous, <A HREF="gdbint_2.html">next</A>, <A HREF="gdbint_16.html">last</A> section, <A HREF="gdbint_toc.html">table of contents</A>. </BODY> </HTML>