riscv
/
binutils-gdb
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Browse Source

Doc how to add a language.

gdb-4_18-branch
John Gilmore 35 years ago
parent
7b3a018e32
commit
7f09f15fcb
1 changed files with 200 additions and 89 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 289
      gdb/doc/gdbint.texinfo

289
gdb/doc/gdbint.texinfo
View File

@ -1,5 +1,5 @@
\input texinfo
@setfilename gdb-internals
@setfilename gdbint.info
@c $Id$
@ifinfo
This file documents the internals of the GNU debugger GDB.
@ -23,7 +23,7 @@ manual under the terms of the GPL (for which purpose this text may be
regarded as a program in the language TeX).
@end ifinfo
@setchapternewpage odd
@setchapternewpage off
@settitle GDB Internals
@titlepage
@title{Working in GDB}
@ -58,16 +58,21 @@ are preserved on all copies.
* 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
@ -115,15 +120,15 @@ since they might never return to your code (they @samp{longjmp} instead).
@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.
@ -175,7 +180,7 @@ appear anywhere else in the directory.
@node New Architectures, BFD support for GDB, README, Top
@node New Architectures, Host, README, Top
@chapter Defining a new host or target architecture
@ -244,69 +249,8 @@ extract data from one, write data to one, print information about one,
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
@ -315,7 +259,7 @@ to some other kind of system, you are done.
(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
@ -329,17 +273,25 @@ XOS to the lists of supported architectures, vendors, and operating systems
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
@ -351,7 +303,9 @@ script code to recognize your XARCH-XVEND-XOS configuration, and set
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.)
@ -376,14 +330,18 @@ in various ways by macros defined in your @file{xm-XXX.h} file.
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
@ -392,7 +350,9 @@ able to debug programs that run @emph{on} XXX yet.)
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.
@ -422,8 +382,8 @@ routine should suck out the supplied register values and install them into
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.
@ -451,8 +411,8 @@ that just #include's tm-XARCH.h and tm-XOS.h. (Now that we have
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.
@ -475,7 +435,63 @@ configure +template=configure
@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
@ -561,6 +577,101 @@ pointer to the new corresponding symtab, or zero if there
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

Write Preview
Loading…
Cancel
Save