\input texinfo
-@setfilename gdb-internals
+@setfilename gdbint.info
@c $Id$
@ifinfo
This file documents the internals of the GNU debugger GDB.
regarded as a program in the language TeX).
@end ifinfo
-@setchapternewpage odd
+@setchapternewpage off
@settitle GDB Internals
@titlepage
@title{Working in GDB}
* Releases:: Configuring GDB for release
* README:: The README file
* New Architectures:: Defining a new host or target architecture
+* Host:: Adding a New Host
+* Target:: Adding a New Target
+* Config:: Extending @code{configure}
* BFD support for GDB:: How BFD and GDB interface
* Host versus Target:: What features are in which files
* Symbol Reading:: Defining new symbol readers
+* Languages:: Defining new source languages
+
@end menu
@node Cleanups, Wrapping, Top, Top
@chapter Cleanups
Cleanups are a structured way to deal with things that need to be done
-later. When your code does something (like malloc some memory, or open
+later. When your code does something (like @code{malloc} some memory, or open
a file) that needs to be undone later (e.g. free the memory or close
the file), it can make a cleanup. The cleanup will be done at some
future point: when the command is finished, when an error occurs, or
@node Wrapping, Releases, Cleanups, Top
@chapter Wrapping output lines
-Output that goes through printf_filtered or fputs_filtered or
-fputs_demangled needs only to have calls to wrap_here() added
+Output that goes through @code{printf_filtered} or @code{fputs_filtered} or
+@code{fputs_demangled} needs only to have calls to @code{wrap_here} added
in places that would be good breaking points. The utility routines
will take care of actually wrapping if the line width is exceeded.
-The argument to wrap_here() is an indentation string which is printed
-ONLY if the line breaks there. This argument is saved away and used
-later. It must remain valid until the next call to wrap_here() or
-until a newline has been printed through the *_filtered functions.
+The argument to @code{wrap_here} is an indentation string which is printed
+@emph{only} if the line breaks there. This argument is saved away and used
+later. It must remain valid until the next call to @code{wrap_here} or
+until a newline has been printed through the @code{*_filtered} functions.
Don't pass in a local variable and then return!
It is usually best to call wrap_here() after printing a comma or space.
-@node New Architectures, BFD support for GDB, README, Top
+@node New Architectures, Host, README, Top
@chapter Defining a new host or target architecture
etc. Now that executable files are handled with BFD, every architecture
should be able to use the generic exec.c rather than its own custom code.
-@node BFD support for GDB, Host versus Target, New Architectures, Top
-@chapter Binary File Descriptor library support for GDB
-
-BFD provides support for GDB in several ways:
-
-@table @emph
-@item identifying executable and core files
-BFD will identify a variety of file types, including a.out, coff, and
-several variants thereof, as well as several kinds of core files.
-
-@item access to sections of files
-BFD parses the file headers to determine the names, virtual addresses,
-sizes, and file locations of all the various named sections in files
-(such as the text section or the data section). GDB simply calls
-BFD to read or write section X at byte offset Y for length Z.
-
-@item specialized core file support
-BFD provides routines to determine the failing command name stored
-in a core file, the signal with which the program failed, and whether
-a core file matches (i.e. could be a core dump of) a particular executable
-file.
-
-@item locating the symbol information
-GDB uses an internal interface of BFD to determine where to find the
-symbol information in an executable file or symbol-file. GDB itself
-handles the reading of symbols, since BFD does not ``understand'' debug
-symbols, but GDB uses BFD's cached information to find the symbols,
-string table, etc.
-@end table
-
-The interface for symbol reading is described in @xref{Symbol Reading}.
-
-@node Host versus Target, Symbol Reading, BFD support for GDB, Top
-@chapter What is considered ``host-dependent'' versus ``target-dependent''?
-
-The xconfig/*, xm-*.h and *-xdep.c files are for host support. The
-question is, what features or aspects of a debugging or cross-debugging
-environment are considered to be ``host'' support.
-
-Defines and include files needed to build on the host are host support.
-Examples are tty support, system defined types, host byte order, host
-float format.
-
-Unix child process support is considered an aspect of the host. Since
-when you fork on the host you are still on the host, the various macros
-needed for finding the registers in the upage, running ptrace, and such
-are all in the host-dependent files.
-
-This is still somewhat of a grey area; I (John Gilmore) didn't do the
-xm- and tm- split for gdb (it was done by Jim Kingdon) so I have had to
-figure out the grounds on which it was split, and make my own choices
-as I evolve it. I have moved many things out of the xdep files
-actually, partly as a result of BFD and partly by removing duplicated
-code.
-
-@menu
-* New Host:: Adding a New Host
-* New Target:: Adding a New Target
-* New Config:: Extending @code{configure}
-@end menu
-
-@node New Host, New Target, Host versus Target, Host versus Target
-@section Adding a New Host
+@node Host, Target, New Architectures, Top
+@chapter Adding a New Host
There are two halves to making GDB work on a new machine. First,
you have to make it host on the new machine (compile there, handle
(If you want to use GDB to debug programs that run on the new machine,
you have to get it to understand the machine's object files, symbol
-files, and interfaces to processes. @pxref{New Target}.)
+files, and interfaces to processes. @pxref{Target}.)
Most of the work in making GDB compile on a new machine is in specifying
the configuration of the machine. This is done in a dizzying variety
near the bottom of the file. Also, add XXX as an alias that maps to
XARCH-XVEND-XOS. You can test your changes by running
- ./config.sub XXX
-and ./config.sub XARCH-XVEND-XOS
-
+@example
+./config.sub XXX
+@end example
+@noindent
+and
+@example
+./config.sub XARCH-XVEND-XOS
+@end example
+@noindent
which should both respond with XARCH-XVEND-XOS and no error messages.
Then edit @file{include/sysdep.h}. Add a new #define for XXX_SYS, with
a numeric value not already in use. Add a new section that says
- #if HOST_SYS==XXX_SYS
- #include <sys/h-XXX.h>
- #endif
+@example
+#if HOST_SYS==XXX_SYS
+#include <sys/h-XXX.h>
+#endif
+@end example
Now create a new file @file{include/sys/h-XXX.h}. Examine the other
h-*.h files as templates, and create one that brings in the right include
bfd_host to XXX when you recognize it. Now create a file
@file{bfd/config/hmake-XXX}, which includes the line:
- HDEFINES=-DHOST_SYS=XXX_SYS
+@example
+HDEFINES=-DHOST_SYS=XXX_SYS
+@end example
(If you have the binutils in the same tree, you'll have to do the same
thing to in the binutils directory as you've done in the bfd directory.)
Now, from the top level (above bfd, gdb, etc), run:
- ./configure -template=./configure
+@example
+./configure -template=./configure
+@end example
This will rebuild all your configure scripts, using the new
configure.in files that you modified. (You can also run this command
at any subdirectory level.) You are now ready to try configuring
GDB to compile for your system. Do:
- ./configure XXX +target=vxworks960
+@example
+./configure XXX +target=vxworks960
+@end example
This will configure your system to cross-compile for VxWorks on
the Intel 960, which is probably not what you really want, but it's
If this succeeds, you can try building it all with:
- make
+@example
+make
+@end example
Good luck! Comments and suggestions about this section are particularly
welcome; send them to bug-gdb@@prep.ai.mit.edu.
gdb's "registers" array. (@xref{New Architectures}
for more info about this.)
-@node New Target, New Config, New Host, Host versus Target
-@section Adding a New Target
+@node Target, Config, Host, Top
+@chapter Adding a New Target
When adding support for a new target machine, there are various areas
of support that might need change, or might be OK.
three-part configuration names, this will probably get revised to
separate the OS configuration from the ARCH configuration. FIXME.)
-@node New Config, , New Target, Host versus Target
-@section Extending @code{configure}
+@node Config, BFD support for GDB, Target, Top
+@chapter Extending @code{configure}
Once you have added a new host, target, or both, you'll also need to
extend the @code{configure} script to recognize the new configuration
possibilities.
@c kind of silly to insist that it be provided. If it isn't, somebody
@c please fill in here what are others... (then delete this comment!)
-@node Symbol Reading, , Host versus Target, Top
+@node BFD support for GDB, Host versus Target, Config, Top
+@chapter Binary File Descriptor library support for GDB
+
+BFD provides support for GDB in several ways:
+
+@table @emph
+@item identifying executable and core files
+BFD will identify a variety of file types, including a.out, coff, and
+several variants thereof, as well as several kinds of core files.
+
+@item access to sections of files
+BFD parses the file headers to determine the names, virtual addresses,
+sizes, and file locations of all the various named sections in files
+(such as the text section or the data section). GDB simply calls
+BFD to read or write section X at byte offset Y for length Z.
+
+@item specialized core file support
+BFD provides routines to determine the failing command name stored
+in a core file, the signal with which the program failed, and whether
+a core file matches (i.e. could be a core dump of) a particular executable
+file.
+
+@item locating the symbol information
+GDB uses an internal interface of BFD to determine where to find the
+symbol information in an executable file or symbol-file. GDB itself
+handles the reading of symbols, since BFD does not ``understand'' debug
+symbols, but GDB uses BFD's cached information to find the symbols,
+string table, etc.
+@end table
+
+The interface for symbol reading is described in @xref{Symbol Reading}.
+
+@node Host versus Target, Symbol Reading, BFD support for GDB, Top
+@chapter What is considered ``host-dependent'' versus ``target-dependent''?
+
+The xconfig/*, xm-*.h and *-xdep.c files are for host support. The
+question is, what features or aspects of a debugging or cross-debugging
+environment are considered to be ``host'' support.
+
+Defines and include files needed to build on the host are host support.
+Examples are tty support, system defined types, host byte order, host
+float format.
+
+Unix child process support is considered an aspect of the host. Since
+when you fork on the host you are still on the host, the various macros
+needed for finding the registers in the upage, running ptrace, and such
+are all in the host-dependent files.
+
+This is still somewhat of a grey area; I (John Gilmore) didn't do the
+xm- and tm- split for gdb (it was done by Jim Kingdon) so I have had to
+figure out the grounds on which it was split, and make my own choices
+as I evolve it. I have moved many things out of the xdep files
+actually, partly as a result of BFD and partly by removing duplicated
+code.
+
+
+@node Symbol Reading, Languages, Host versus Target, Top
@chapter Symbol Reading
GDB reads symbols from "symbol files". The usual symbol file is the
were no symbols in that part of the symbol file.
@end table
+@node Languages, , Host versus Target, Top
+@chapter Adding a Source Language to GDB
+
+To add other languages to GDB's expression parser, follow the following steps:
+
+@table @emph
+@item Create the expression parser.
+
+This should reside in a file called <lang>-exp.y. Routines for building
+parsed expressions into a (struct exp_elt) list are in parser-code.c.
+
+Since we can't depend upon everyone having Bison, the following lines
+@emph{musg} be included at the top of the YACC parser:
+
+@example
+#define yyparse <lang>_parse
+#define yylex <lang>_lex
+#define yyerror <lang>_error
+#define yylval <lang>_lval
+#define yychar <lang>_char
+#define yydebug <lang>_debug
+#define yypact <lang>_pact
+#define yyr1 <lang>_r1
+#define yyr2 <lang>_r2
+#define yydef <lang>_def
+#define yychk <lang>_chk
+#define yypgo <lang>_pgo
+#define yyact <lang>_act
+#define yyexca <lang>_exca
+@end example
+
+This will prevent name conflicts between the various parsers.
+
+@item Add any evaluation routines, if necessary
+
+If you need new opcodes (that represent the operations of the language),
+add them to the ennumerated type in expression.h.
+Add support code for these operations in eval.c:evaluate_subexp()
+Add cases for new opcodes in parser-code.c:prefixify_subexp() and
+parser-code.c:length_of_subexp(). These compute the number of
+exp_elements that a given operation takes up.
+
+@item Update some existing code
+
+Add an ennumerated identifier for your language to the ennumerated type
+enum language in symtab.h.
+
+Update the routines in language.c so your language is included. These
+routines include type predicates and such, which (in some cases) are
+language dependent. If your language does not appear in the switch
+statement, an error is reported.
+
+Also included in language.c is the code that updates the variable
+working_lang, and the routines that translate the language_<lang>
+ennumerated identifier into a printable string.
+
+Update the function _intitialize_language to include your language. This
+function picks the default language upon startup, so is dependent upon
+which languages that GDB is built for.
+
+Update symfile.c and/or symbol-reading code so that the language of
+each symtab (source file) is set properly. This is used to determine the
+language to use at each stack frame level. Currently, the language
+is set based upon the extension of the source file. If the language
+can be better inferred from the symbol information, please set the
+language of the symtab in the symbol-reading code.
+
+Add helper code to expprint.c:print_subexp() to handle any new expression
+opcodes you have added to expression.h. Also, add the printed
+representations of your operators to op_print_tab.
+
+@item Add a place of call
+
+Add a call to <lang>_parse() and <lang>_error in parse.c:parse_exp_1().
+
+@item Use macros to trim code
+
+The user has the option of building GDB for some or all of the languages.
+If the user decides to build GDB for the language <lang>, then every file
+dependent on language.h will have the macro _LANG_<lang> defined in it.
+Use #ifdefs to leave out large routines that the user won't need if
+he/she is not using your language.
+
+Note that you do not need to do this in your YACC parser, since if GDB is
+not build for <lang>, then <lang>-exp.tab.o (the compiled form of your
+parser) is not linked into GDB at all.
+
+See the file configure.in for how GDB is configured for different languages.
+
+@item Edit Makefile.in
+
+Add dependencies in Makefile.in. Make sure you update the macro
+variables such as HFILES and OBJS, otherwise your code may not get linked
+in, or, worse yet, it may not get tarred into the distribution!
+
@contents
@bye
projects / binutils-gdb.git / commitdiff