Next: Releases Prev: Target Up: Top
Adding a Source Language to GDB
To add other languages to GDB's expression parser, follow the
*Create the expression parser.*
This should reside in a file `LANG-exp.y'. Routines for building
parsed expressions into a `union exp_element' list are in
Since we can't depend upon everyone having Bison, and YACC produces
parsers that define a bunch of global names, the following lines
*must* be included at the top of the YACC parser, to prevent the
various parsers from defining the same global names:
#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
#define yyerrflag LANG_errflag
#define yynerrs LANG_nerrs
At the bottom of your parser, define a `struct language_defn' and
initialize it with the right values for your language. Define an
`initialize_LANG' routine and have it call
`add_language(LANG_language_defn)' to tell the rest of GDB that
your language exists. You'll need some other supporting variables
and functions, which will be used via pointers from your
`LANG_language_defn'. See the declaration of `struct
language_defn' in `language.h', and the other `*-exp.y' files, for
*Add any evaluation routines, if necessary*
If you need new opcodes (that represent the operations of the
language), add them to the enumerated type in `expression.h'. Add
support code for these operations in `eval.c:evaluate_subexp()'.
Add cases for new opcodes in two functions from `parse.c':
`prefixify_subexp()' and `length_of_subexp()'. These compute the
number of `exp_element's that a given operation takes up.
*Update some existing code*
Add an enumerated identifier for your language to the enumerated
type `enum language' in `defs.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
`current_language', and the routines that translate the
`language_LANG' enumerated identifier into a printable string.
Update the function `_initialize_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 `allocate_symtab' in `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
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'.
*Add a place of call*
Add a call to `LANG_parse()' and `LANG_error' in
*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 `#ifdef's to leave out
large routines that the user won't need if he or she is not using
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
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 `tar'red into the
automatically generated by info2www