<HTML> <HEAD> <!-- This HTML file has been created by texi2html 1.51 from /mnt/apple/gdb/source/gdb.apple/source/gdb/gdb/doc/gdb.texinfo on 23 November 1999 --> <TITLE>Debugging with GDB - GDB Files</TITLE> </HEAD> <BODY> Go to the <A HREF="gdb_1.html">first</A>, <A HREF="gdb_12.html">previous</A>, <A HREF="gdb_14.html">next</A>, <A HREF="gdb_21.html">last</A> section, <A HREF="gdb_toc.html">table of contents</A>. <P><HR><P> <H1><A NAME="SEC109" HREF="gdb_toc.html#TOC109">GDB Files</A></H1> <P> 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. </P> <H2><A NAME="SEC110" HREF="gdb_toc.html#TOC110">Commands to specify files</A></H2> <P> <A NAME="IDX453"></A> <A NAME="IDX454"></A> </P> <P> 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 (see section <A HREF="gdb_3.html#SEC5">Getting In and Out of GDB</A>). </P> <P> 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. </P> <DL COMPACT> <DT><CODE>file <VAR>filename</VAR></CODE> <DD> <A NAME="IDX455"></A> <A NAME="IDX456"></A> Use <VAR>filename</VAR> 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 <CODE>run</CODE> command. If you do not specify a directory and the file is not found in the GDB working directory, GDB uses the environment variable <CODE>PATH</CODE> 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 <CODE>path</CODE> command. On systems with memory-mapped files, an auxiliary file <TT>`<VAR>filename</VAR>.syms'</TT> may hold symbol table information for <VAR>filename</VAR>. If so, GDB maps in the symbol table from <TT>`<VAR>filename</VAR>.syms'</TT>, starting up more quickly. See the descriptions of the file options <SAMP>`-mapped'</SAMP> and <SAMP>`-readnow'</SAMP> (available on the command line, and with the commands <CODE>file</CODE>, <CODE>symbol-file</CODE>, or <CODE>add-symbol-file</CODE>, described below), for more information. <DT><CODE>file</CODE> <DD> <CODE>file</CODE> with no argument makes GDB discard any information it has on both executable file and the symbol table. <A NAME="IDX457"></A> <DT><CODE>exec-file [ <VAR>filename</VAR> ]</CODE> <DD> Specify that the program to be run (but not the symbol table) is found in <VAR>filename</VAR>. GDB searches the environment variable <CODE>PATH</CODE> if necessary to locate your program. Omitting <VAR>filename</VAR> means to discard information on the executable file. <A NAME="IDX458"></A> <DT><CODE>symbol-file [ <VAR>filename</VAR> ]</CODE> <DD> Read symbol table information from file <VAR>filename</VAR>. <CODE>PATH</CODE> is searched when necessary. Use the <CODE>file</CODE> command to get both symbol table and program to run from the same file. <CODE>symbol-file</CODE> with no argument clears out GDB information on your program's symbol table. The <CODE>symbol-file</CODE> 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. <CODE>symbol-file</CODE> does not repeat if you press <KBD>RET</KBD> 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 <CODE>gcc</CODE> you can generate debugging information for optimized code. For most kinds of object files, with the exception of old SVR3 systems using COFF, the <CODE>symbol-file</CODE> 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 <CODE>set verbose</CODE> command can turn these pauses into messages if desired. See section <A HREF="gdb_15.html#SEC155">Optional warnings and messages</A>.) We have not implemented the two-stage strategy for COFF yet. When the symbol table is stored in COFF format, <CODE>symbol-file</CODE> 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. <A NAME="IDX459"></A> <A NAME="IDX460"></A> <A NAME="IDX461"></A> <A NAME="IDX462"></A> <A NAME="IDX463"></A> <A NAME="IDX464"></A> <DT><CODE>symbol-file <VAR>filename</VAR> [ -readnow ] [ -mapped ]</CODE> <DD> <DT><CODE>file <VAR>filename</VAR> [ -readnow ] [ -mapped ]</CODE> <DD> You can override the GDB two-stage strategy for reading symbol tables by using the <SAMP>`-readnow'</SAMP> 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 <CODE>mmap</CODE> system call, you can use another option, <SAMP>`-mapped'</SAMP>, 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 <SAMP>`-mapped'</SAMP> option has the same effect as starting GDB with the <SAMP>`-mapped'</SAMP> 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 <VAR>myprog</VAR> is called <SAMP>`<VAR>myprog</VAR>.syms'</SAMP>. Once this file exists (so long as it is newer than the corresponding executable), GDB always attempts to use it when you debug <VAR>myprog</VAR>; no special options or commands are needed. The <TT>`.syms'</TT> 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. <A NAME="IDX465"></A> <A NAME="IDX466"></A> <DT><CODE>core-file [ <VAR>filename</VAR> ]</CODE> <DD> 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. <CODE>core-file</CODE> 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 <CODE>kill</CODE> command (see section <A HREF="gdb_5.html#SEC23">Killing the child process</A>). <A NAME="IDX467"></A> <A NAME="IDX468"></A> <DT><CODE>add-symbol-file <VAR>filename</VAR> <VAR>address</VAR></CODE> <DD> <DT><CODE>add-symbol-file <VAR>filename</VAR> <VAR>address</VAR> [ -readnow ] [ -mapped ]</CODE> <DD> The <CODE>add-symbol-file</CODE> command reads additional symbol table information from the file <VAR>filename</VAR>. You would use this command when <VAR>filename</VAR> has been dynamically loaded (by some other means) into the program that is running. <VAR>address</VAR> should be the memory address at which the file has been loaded; GDB cannot figure this out for itself. You can specify <VAR>address</VAR> as an expression. The symbol table of the file <VAR>filename</VAR> is added to the symbol table originally read with the <CODE>symbol-file</CODE> command. You can use the <CODE>add-symbol-file</CODE> 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 <CODE>symbol-file</CODE> command. <CODE>add-symbol-file</CODE> does not repeat if you press <KBD>RET</KBD> after using it. You can use the <SAMP>`-mapped'</SAMP> and <SAMP>`-readnow'</SAMP> options just as with the <CODE>symbol-file</CODE> command, to change how GDB manages the symbol table information for <VAR>filename</VAR>. <A NAME="IDX469"></A> <DT><CODE>add-shared-symbol-file</CODE> <DD> The <CODE>add-shared-symbol-file</CODE> 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 <CODE>add-shared-symbol-file</CODE>. It takes no arguments. <A NAME="IDX470"></A> <DT><CODE>section</CODE> <DD> The <CODE>section</CODE> 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 lists all the sections and their addresses. <A NAME="IDX471"></A> <A NAME="IDX472"></A> <DT><CODE>info files</CODE> <DD> <DT><CODE>info target</CODE> <DD> <CODE>info files</CODE> and <CODE>info target</CODE> are synonymous; both print the current target (see section <A HREF="gdb_14.html#SEC112">Specifying a Debugging Target</A>), 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 <CODE>help target</CODE> lists all possible targets rather than current ones. </DL> <P> 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. </P> <P> <A NAME="IDX473"></A> 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 <CODE>run</CODE> command, or when you examine a core file. (Before you issue the <CODE>run</CODE> command, GDB does not understand references to a function in a shared library, however--unless you are debugging a core file). </P> <DL COMPACT> <DT><CODE>info share</CODE> <DD> <A NAME="IDX474"></A> <A NAME="IDX475"></A> <DT><CODE>info sharedlibrary</CODE> <DD> Print the names of the shared libraries which are currently loaded. <A NAME="IDX476"></A> <A NAME="IDX477"></A> <DT><CODE>sharedlibrary <VAR>regex</VAR></CODE> <DD> <DT><CODE>share <VAR>regex</VAR></CODE> <DD> 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 <CODE>run</CODE>. If <VAR>regex</VAR> is omitted all shared libraries required by your program are loaded. </DL> <H2><A NAME="SEC111" HREF="gdb_toc.html#TOC111">Errors reading symbol files</A></H2> <P> 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 <CODE>set complaints</CODE> command (see section <A HREF="gdb_15.html#SEC155">Optional warnings and messages</A>). </P> <P> The messages currently printed, and their meanings, include: </P> <DL COMPACT> <DT><CODE>inner block not inside outer block in <VAR>symbol</VAR></CODE> <DD> 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, <VAR>symbol</VAR> may be shown as "<CODE>(don't know)</CODE>" if the outer block is not a function. <DT><CODE>block at <VAR>address</VAR> out of order</CODE> <DD> 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 <CODE>set verbose on</CODE>. See section <A HREF="gdb_15.html#SEC155">Optional warnings and messages</A>.) <DT><CODE>bad block start address patched</CODE> <DD> 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. <DT><CODE>bad string table offset in symbol <VAR>n</VAR></CODE> <DD> <A NAME="IDX478"></A> Symbol number <VAR>n</VAR> 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 <CODE>foo</CODE>, which may cause other problems if many symbols end up with this name. <DT><CODE>unknown symbol type <CODE>0x<VAR>nn</VAR></CODE></CODE> <DD> The symbol information contains new data types that GDB does not yet know how to read. <CODE>0x<VAR>nn</VAR></CODE> is the symbol type of the misunderstood 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 <CODE>gdb</CODE> with itself, breakpoint on <CODE>complain</CODE>, then go up to the function <CODE>read_dbx_symtab</CODE> and examine <CODE>*bufp</CODE> to see the symbol. <DT><CODE>stub type has NULL name</CODE> <DD> GDB could not find the full definition for a struct or class. <DT><CODE>const/volatile indicator missing (ok if using g++ v1.x), got...</CODE> <DD> The symbol information for a C++ member function is missing some information that recent versions of the compiler should have output for it. <DT><CODE>info mismatch between compiler and debugger</CODE> <DD> GDB could not parse a type specification output by the compiler. </DL> <P><HR><P> Go to the <A HREF="gdb_1.html">first</A>, <A HREF="gdb_12.html">previous</A>, <A HREF="gdb_14.html">next</A>, <A HREF="gdb_21.html">last</A> section, <A HREF="gdb_toc.html">table of contents</A>. </BODY> </HTML>