2 @setfilename gdbint.info
8 * Gdb-Internals: (gdbint). The GNU debugger internals.
14 This file documents the internals of the GNU debugger GDB.
16 Copyright (C) 1990, 1991, 1992 Free Software Foundation, Inc.
17 Contributed by Cygnus Support. Written by John Gilmore.
19 Permission is granted to make and distribute verbatim copies of
20 this manual provided the copyright notice and this permission notice
21 are preserved on all copies.
24 Permission is granted to process this file through Tex and print the
25 results, provided the printed document carries copying permission
26 notice identical to this one except for the removal of this paragraph
27 (this paragraph not being relevant to the printed manual).
30 Permission is granted to copy or distribute modified versions of this
31 manual under the terms of the GPL (for which purpose this text may be
32 regarded as a program in the language TeX).
35 @setchapternewpage off
36 @settitle GDB Internals
38 @title{Working in GDB}
39 @subtitle{A guide to the internals of the GNU debugger}
41 @author Cygnus Support
44 \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
45 \xdef\manvers{\$Revision$} % For use in headers, footers too
47 \hfill Cygnus Support\par
49 \hfill \TeX{}info \texinfoversion\par
53 @vskip 0pt plus 1filll
54 Copyright @copyright{} 1990, 1991, 1992 Free Software Foundation, Inc.
56 Permission is granted to make and distribute verbatim copies of
57 this manual provided the copyright notice and this permission notice
58 are preserved on all copies.
62 @node Top, README, (dir), (dir)
64 This file documents the internals of the GNU debugger GDB. It is a
65 collection of miscellaneous information with little form at this point.
66 Mostly, it is a repository into which you can put information about
67 GDB as you discover it (or as you design changes to GDB).
70 * README:: The README File
71 * New Architectures:: Defining a New Host or Target Architecture
72 * Config:: Adding a New Configuration
73 * Host:: Adding a New Host
74 * Target:: Adding a New Target
75 * Languages:: Defining New Source Languages
76 * Releases:: Configuring GDB for Release
77 * Partial Symbol Tables:: How GDB reads symbols quickly at startup
78 * BFD support for GDB:: How BFD and GDB interface
79 * Symbol Reading:: Defining New Symbol Readers
81 * Wrapping:: Wrapping Output Lines
82 * Frames:: Keeping track of function calls
83 * Host Conditionals:: Controlling what features exist in the host
84 * Target Conditionals:: Controlling what features exist in the target
88 @node README, New Architectures, Top, Top
89 @chapter The @file{README} File
91 Check the @file{README} file, it often has useful information that does not
92 appear anywhere else in the directory.
95 @node New Architectures, Config, README, Top
96 @chapter Defining a New Host or Target Architecture
98 When building support for a new host and/or target, much of the work you
99 need to do is handled by specifying configuration files;
100 @pxref{Config,,Adding a New Configuration}. Further work can be
101 divided into ``host-dependent'' (@pxref{Host,,Adding a New Host}) and
102 ``target-dependent'' (@pxref{Target,,Adding a New Target}). The
103 following discussion is meant to explain the difference between hosts
106 @heading What is considered ``host-dependent'' versus ``target-dependent''?
108 @dfn{Host} refers to attributes of the system where GDB runs.
109 @dfn{Target} refers to the system where the program being debugged
110 executes. In most cases they are the same machine; unfortunately, that
111 means you must add @emph{both} host and target support for new machines
114 The @file{config/mh-*}, @file{xm-*.h} and @file{*-xdep.c} files are for
115 host support. Similarly, the @file{config/mt-*}, @file{tm-*.h} and
116 @file{*-tdep.c} files are for target support. The question is, what
117 features or aspects of a debugging or cross-debugging environment are
118 considered to be ``host'' support?
120 Defines and include files needed to build on the host are host support.
121 Examples are tty support, system defined types, host byte order, host
124 Unix child process support is considered an aspect of the host. Since
125 when you fork on the host you are still on the host, the various macros
126 needed for finding the registers in the upage, running @code{ptrace}, and such
127 are all in the host-dependent files.
129 @c FIXME so what kinds of things are target support?
131 This is still somewhat of a grey area; I (John Gilmore) didn't do the
132 @file{xm-*} and @file{tm-*} split for gdb (it was done by Jim Kingdon)
133 so I have had to figure out the grounds on which it was split, and make
134 my own choices as I evolve it. I have moved many things out of the xdep
135 files actually, partly as a result of BFD and partly by removing
139 @node Config, Host, New Architectures, Top
140 @chapter Adding a New Configuration
142 Most of the work in making GDB compile on a new machine is in specifying
143 the configuration of the machine. This is done in a dizzying variety of
144 header files and configuration scripts, which we hope to make more
145 sensible soon. Let's say your new host is called an @var{xxx} (e.g.
146 @samp{sun4}), and its full three-part configuration name is
147 @code{@var{xarch}-@var{xvend}-@var{xos}} (e.g. @samp{sparc-sun-sunos4}). In
150 In the top level directory, edit @file{config.sub} and add @var{xarch},
151 @var{xvend}, and @var{xos} to the lists of supported architectures,
152 vendors, and operating systems near the bottom of the file. Also, add
153 @var{xxx} as an alias that maps to
154 @code{@var{xarch}-@var{xvend}-@var{xos}}. You can test your changes by
158 ./config.sub @var{xxx}
163 ./config.sub @code{@var{xarch}-@var{xvend}-@var{xos}}
166 which should both respond with @code{@var{xarch}-@var{xvend}-@var{xos}}
167 and no error messages.
169 Now, go to the @file{bfd} directory and
170 create a new file @file{bfd/hosts/h-@var{xxx}.h}. Examine the
171 other @file{h-*.h} files as templates, and create one that brings in the
172 right include files for your system, and defines any host-specific
173 macros needed by GDB.
175 Then edit @file{bfd/configure.in}. Add shell script code to recognize your
176 @code{@var{xarch}-@var{xvend}-@var{xos}} configuration, and set
177 @code{my_host} to @var{xxx} when you recognize it. This will cause your
178 file @file{h-@var{xxx}.h} to be linked to @file{sysdep.h} at configuration
181 Also, if this host requires any changes to the Makefile, create a file
182 @file{bfd/config/mh-@var{xxx}}, which includes the required lines.
184 (If you have the binary utilities and/or GNU ld in the same tree,
185 you'll also have to edit @file{binutils/configure.in} or
186 @file{ld/configure.in} to match what you've done in the @file{bfd}
189 It's possible that the @file{libiberty} and @file{readline} directories
190 won't need any changes for your configuration, but if they do, you can
191 change the @file{configure.in} file there to recognize your system and
192 map to an @file{mh-@var{xxx}} file. Then add @file{mh-@var{xxx}}
193 to the @file{config/} subdirectory, to set any makefile variables you
194 need. The only current options in there are things like @samp{-DSYSV}.
196 Aha! Now to configure GDB itself! Edit
197 @file{gdb/configure.in} to recognize your system and set @code{gdb_host}
198 to @var{xxx}, and (unless your desired target is already available) also
199 set @code{gdb_target} to something appropriate (for instance,
200 @var{xxx}). To handle new hosts, modify the segment after the comment
201 @samp{# per-host}; to handle new targets, modify after @samp{#
203 @c Would it be simpler to just use different per-host and per-target
204 @c *scripts*, and call them from {configure} ?
206 Finally, you'll need to specify and define GDB's host- and
207 target-dependent @file{.h} and @file{.c} files used for your
208 configuration; the next two chapters discuss those.
211 @node Host, Target, Config, Top
212 @chapter Adding a New Host
214 Once you have specified a new configuration for your host
215 (@pxref{Config,,Adding a New Configuration}), there are two remaining
216 pieces to making GDB work on a new machine. First, you have to make it
217 host on the new machine (compile there, handle that machine's terminals
218 properly, etc). If you will be cross-debugging to some other kind of
219 system that's already supported, you are done.
221 If you want to use GDB to debug programs that run on the new machine,
222 you have to get it to understand the machine's object files, symbol
223 files, and interfaces to processes. @pxref{Target,,Adding a New Target}
225 Several files control GDB's configuration for host systems:
228 @item gdb/config/mh-@var{xxx}
229 Specifies Makefile fragments needed when hosting on machine @var{xxx}.
230 In particular, this lists the required machine-dependent object files,
231 by defining @samp{XDEPFILES=@dots{}}. Also
232 specifies the header file which describes host @var{xxx}, by defining
233 @samp{XM_FILE= xm-@var{xxx}.h}. You can also define @samp{CC},
234 @samp{REGEX} and @samp{REGEX1}, @samp{SYSV_DEFINE}, @samp{XM_CFLAGS},
235 @samp{XM_ADD_FILES}, @samp{XM_CLIBS}, @samp{XM_CDEPS},
236 etc.; see @file{Makefile.in}.
238 @item gdb/xm-@var{xxx}.h
239 (@file{xm.h} is a link to this file, created by configure).
240 Contains C macro definitions describing the host system environment,
241 such as byte order, host C compiler and library, ptrace support,
242 and core file structure. Crib from existing @file{xm-*.h} files
245 @item gdb/@var{xxx}-xdep.c
246 Contains any miscellaneous C code required for this machine
247 as a host. On some machines it doesn't exist at all.
250 There are some ``generic'' versions of routines that can be used by
251 various host systems. These can be customized in various ways by macros
252 defined in your @file{xm-@var{xxx}.h} file. If these routines work for
253 the @var{xxx} host, you can just include the generic file's name (with
254 @samp{.o}, not @samp{.c}) in @code{XDEPFILES}.
256 Otherwise, if your machine needs custom support routines, you will need
257 to write routines that perform the same functions as the generic file.
258 Put them into @code{@var{xxx}-xdep.c}, and put @code{@var{xxx}-xdep.o}
259 into @code{XDEPFILES}.
261 @subheading Generic Host Support Files
266 This is the low level interface to inferior processes for systems
267 using the Unix @code{ptrace} call in a vanilla way.
269 @item coredep.c::fetch_core_registers()
270 Support for reading registers out of a core file. This routine calls
271 @code{register_addr()}, see below.
272 Now that BFD is used to read core files, virtually all machines should
273 use @code{coredep.c}, and should just provide @code{fetch_core_registers} in
274 @code{@var{xxx}-xdep.c} (or @code{REGISTER_U_ADDR} in @code{xm-@var{xxx}.h}).
276 @item coredep.c::register_addr()
277 If your @code{xm-@var{xxx}.h} file defines the macro
278 @code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to
279 set @code{addr} to the offset within the @samp{user}
280 struct of GDB register number @code{regno}. @code{blockend} is the
281 offset within the ``upage'' of @code{u.u_ar0}.
282 If @code{REGISTER_U_ADDR} is defined,
283 @file{coredep.c} will define the @code{register_addr()} function and use
284 the macro in it. If you do not define @code{REGISTER_U_ADDR}, but you
285 are using the standard @code{fetch_core_registers()}, you will need to
286 define your own version of @code{register_addr()}, put it into your
287 @code{@var{xxx}-xdep.c} file, and be sure @code{@var{xxx}-xdep.o} is in
288 the @code{XDEPFILES} list. If you have your own
289 @code{fetch_core_registers()}, you may not need a separate
290 @code{register_addr()}. Many custom @code{fetch_core_registers()}
291 implementations simply locate the registers themselves.@refill
294 Object files needed when the target system is an @var{xxx} are listed
295 in the file @file{config/mt-@var{xxx}}, in the makefile macro
296 @samp{TDEPFILES = }@dots{}. The header file that defines the target
297 system should be called @file{tm-@var{xxx}.h}, and should be specified
298 as the value of @samp{TM_FILE} in @file{config/mt-@var{xxx}}. You can
299 also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, and @samp{TM_CDEPS} in
300 there; see @file{Makefile.in}.
302 Now, you are now ready to try configuring GDB to compile for your system.
303 From the top level (above @file{bfd}, @file{gdb}, etc), do:
306 ./configure @var{xxx} +target=vxworks960
309 This will configure your system to cross-compile for VxWorks on
310 the Intel 960, which is probably not what you really want, but it's
311 a test case that works at this stage. (You haven't set up to be
312 able to debug programs that run @emph{on} @var{xxx} yet.)
314 If this succeeds, you can try building it all with:
320 Good luck! Comments and suggestions about this section are particularly
321 welcome; send them to @samp{bug-gdb@@prep.ai.mit.edu}.
323 When hosting GDB on a new operating system, to make it possible to debug
324 core files, you will need to either write specific code for parsing your
325 OS's core files, or customize @file{bfd/trad-core.c}. First, use
326 whatever @code{#include} files your machine uses to define the struct of
327 registers that is accessible (possibly in the u-area) in a core file
328 (rather than @file{machine/reg.h}), and an include file that defines whatever
329 header exists on a core file (e.g. the u-area or a @samp{struct core}). Then
330 modify @code{trad_unix_core_file_p()} to use these values to set up the
331 section information for the data segment, stack segment, any other
332 segments in the core file (perhaps shared library contents or control
333 information), ``registers'' segment, and if there are two discontiguous
334 sets of registers (e.g. integer and float), the ``reg2'' segment. This
335 section information basically delimits areas in the core file in a
336 standard way, which the section-reading routines in BFD know how to seek
339 Then back in GDB, you need a matching routine called
340 @code{fetch_core_registers()}. If you can use the generic one, it's in
341 @file{core-dep.c}; if not, it's in your @file{@var{xxx}-xdep.c} file.
342 It will be passed a char pointer to the entire ``registers'' segment,
343 its length, and a zero; or a char pointer to the entire ``regs2''
344 segment, its length, and a 2. The routine should suck out the supplied
345 register values and install them into GDB's ``registers'' array.
346 (@xref{New Architectures,,Defining a New Host or Target Architecture},
347 for more info about this.)
350 @node Target, Languages, Host, Top
351 @chapter Adding a New Target
353 For a new target called @var{ttt}, first specify the configuration as
354 described in @ref{Config,,Adding a New Configuration}. If your new
355 target is the same as your new host, you've probably already done that.
357 A variety of files specify attributes of the GDB target environment:
360 @item gdb/config/mt-@var{ttt}
361 Contains a Makefile fragment specific to this target.
362 Specifies what object files are needed for target @var{ttt}, by
363 defining @samp{TDEPFILES=@dots{}}.
364 Also specifies the header file which describes @var{ttt}, by defining
365 @samp{TM_FILE= tm-@var{ttt}.h}. You can also define @samp{TM_CFLAGS},
366 and other Makefile variables here; see @file{Makefile.in}.
368 @item gdb/tm-@var{ttt}.h
369 (@file{tm.h} is a link to this file, created by configure).
370 Contains macro definitions about the target machine's
371 registers, stack frame format and instructions.
372 Crib from existing @file{tm-*.h} files when building a new one.
374 @item gdb/@var{ttt}-tdep.c
375 Contains any miscellaneous code required for this target machine.
376 On some machines it doesn't exist at all. Sometimes the macros
377 in @file{tm-@var{ttt}.h} become very complicated, so they are
378 implemented as functions here instead, and the macro is simply
379 defined to call the function.
382 Defines functions for accessing files that are
383 executable on the target system. These functions open and examine an
384 exec file, extract data from one, write data to one, print information
385 about one, etc. Now that executable files are handled with BFD, every
386 target should be able to use the generic exec.c rather than its
389 @item gdb/@var{arch}-pinsn.c
390 Prints (disassembles) the target machine's instructions.
391 This file is usually shared with other target machines which use the
392 same processor, which is why it is @file{@var{arch}-pinsn.c} rather
393 than @file{@var{ttt}-pinsn.c}.
395 @item gdb/@var{arch}-opcode.h
396 Contains some large initialized
397 data structures describing the target machine's instructions.
398 This is a bit strange for a @file{.h} file, but it's OK since
399 it is only included in one place. @file{@var{arch}-opcode.h} is shared
400 between the debugger and the assembler, if the GNU assembler has been
401 ported to the target machine.
403 @item gdb/tm-@var{arch}.h
404 This often exists to describe the basic layout of the target machine's
405 processor chip (registers, stack, etc).
406 If used, it is included by @file{tm-@var{xxx}.h}. It can
407 be shared among many targets that use the same processor.
409 @item gdb/@var{arch}-tdep.c
410 Similarly, there are often common subroutines that are shared by all
411 target machines that use this particular architecture.
414 When adding support for a new target machine, there are various areas
415 of support that might need change, or might be OK.
417 If you are using an existing object file format (a.out or COFF),
418 there is probably little to be done. See @file{bfd/doc/bfd.texinfo}
419 for more information on writing new a.out or COFF versions.
421 If you need to add a new object file format, you are beyond the scope
422 of this document right now. Look at the structure of the a.out
423 and COFF support, build a transfer vector (@code{xvec}) for your new format,
424 and start populating it with routines. Add it to the list in
425 @file{bfd/targets.c}.
427 If you are adding a new operating system for an existing CPU chip, add a
428 @file{tm-@var{xos}.h} file that describes the operating system
429 facilities that are unusual (extra symbol table info; the breakpoint
430 instruction needed; etc). Then write a
431 @file{tm-@var{xarch}-@var{xos}.h} that just @code{#include}s
432 @file{tm-@var{xarch}.h} and @file{tm-@var{xos}.h}. (Now that we have
433 three-part configuration names, this will probably get revised to
434 separate the @var{xos} configuration from the @var{xarch}
438 @node Languages, Releases, Target, Top
439 @chapter Adding a Source Language to GDB
441 To add other languages to GDB's expression parser, follow the following steps:
444 @item Create the expression parser.
446 This should reside in a file @file{@var{lang}-exp.y}. Routines for building
447 parsed expressions into a @samp{union exp_element} list are in @file{parse.c}.
449 Since we can't depend upon everyone having Bison, and YACC produces
450 parsers that define a bunch of global names, the following lines
451 @emph{must} be included at the top of the YACC parser, to prevent
452 the various parsers from defining the same global names:
455 #define yyparse @var{lang}_parse
456 #define yylex @var{lang}_lex
457 #define yyerror @var{lang}_error
458 #define yylval @var{lang}_lval
459 #define yychar @var{lang}_char
460 #define yydebug @var{lang}_debug
461 #define yypact @var{lang}_pact
462 #define yyr1 @var{lang}_r1
463 #define yyr2 @var{lang}_r2
464 #define yydef @var{lang}_def
465 #define yychk @var{lang}_chk
466 #define yypgo @var{lang}_pgo
467 #define yyact @var{lang}_act
468 #define yyexca @var{lang}_exca
469 #define yyerrflag @var{lang}_errflag
470 #define yynerrs @var{lang}_nerrs
473 At the bottom of your parser, define a @code{struct language_defn} and
474 initialize it with the right values for your language. Define an
475 @code{initialize_@var{lang}} routine and have it call
476 @samp{add_language(@var{lang}_language_defn)} to tell the rest of GDB
477 that your language exists. You'll need some other supporting variables
478 and functions, which will be used via pointers from your
479 @code{@var{lang}_language_defn}. See the declaration of @code{struct
480 language_defn} in @file{language.h}, and the other @file{*-exp.y} files,
481 for more information.
483 @item Add any evaluation routines, if necessary
485 If you need new opcodes (that represent the operations of the language),
486 add them to the enumerated type in @file{expression.h}. Add support
487 code for these operations in @code{eval.c:evaluate_subexp()}. Add cases
488 for new opcodes in two functions from @file{parse.c}:
489 @code{prefixify_subexp()} and @code{length_of_subexp()}. These compute
490 the number of @code{exp_element}s that a given operation takes up.
492 @item Update some existing code
494 Add an enumerated identifier for your language to the enumerated type
495 @code{enum language} in @file{defs.h}.
497 Update the routines in @file{language.c} so your language is included. These
498 routines include type predicates and such, which (in some cases) are
499 language dependent. If your language does not appear in the switch
500 statement, an error is reported.
502 Also included in @file{language.c} is the code that updates the variable
503 @code{current_language}, and the routines that translate the
504 @code{language_@var{lang}} enumerated identifier into a printable
507 Update the function @code{_initialize_language} to include your language. This
508 function picks the default language upon startup, so is dependent upon
509 which languages that GDB is built for.
511 Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading
512 code so that the language of each symtab (source file) is set properly.
513 This is used to determine the language to use at each stack frame level.
514 Currently, the language is set based upon the extension of the source
515 file. If the language can be better inferred from the symbol
516 information, please set the language of the symtab in the symbol-reading
519 Add helper code to @code{expprint.c:print_subexp()} to handle any new
520 expression opcodes you have added to @file{expression.h}. Also, add the
521 printed representations of your operators to @code{op_print_tab}.
523 @item Add a place of call
525 Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in
526 @code{parse.c:parse_exp_1()}.
528 @item Use macros to trim code
530 The user has the option of building GDB for some or all of the
531 languages. If the user decides to build GDB for the language
532 @var{lang}, then every file dependent on @file{language.h} will have the
533 macro @code{_LANG_@var{lang}} defined in it. Use @code{#ifdef}s to
534 leave out large routines that the user won't need if he or she is not
537 Note that you do not need to do this in your YACC parser, since if GDB
538 is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the
539 compiled form of your parser) is not linked into GDB at all.
541 See the file @file{configure.in} for how GDB is configured for different
544 @item Edit @file{Makefile.in}
546 Add dependencies in @file{Makefile.in}. Make sure you update the macro
547 variables such as @code{HFILES} and @code{OBJS}, otherwise your code may
548 not get linked in, or, worse yet, it may not get @code{tar}red into the
553 @node Releases, Partial Symbol Tables, Languages, Top
554 @chapter Configuring GDB for Release
556 From the top level directory (containing @file{gdb}, @file{bfd},
557 @file{libiberty}, and so on):
559 make -f Makefile.in gdb.tar.Z
562 This will properly configure, clean, rebuild any files that are
563 distributed pre-built (e.g. @file{c-exp.tab.c} or @file{refcard.ps}),
564 and will then make a tarfile. (If the top level directory has already
565 beenn configured, you can just do @code{make gdb.tar.Z} instead.)
567 This procedure requires:
570 @item @code{makeinfo} (texinfo2 level)
573 @item @code{yacc} or @code{bison}
576 @dots{} and the usual slew of utilities (@code{sed}, @code{tar}, etc.).
578 @subheading TEMPORARY RELEASE PROCEDURE FOR DOCUMENTATION
580 @file{gdb.texinfo} is currently marked up using the texinfo-2 macros,
581 which are not yet a default for anything (but we have to start using
584 For making paper, the only thing this implies is the right generation of
585 @file{texinfo.tex} needs to be included in the distribution.
587 For making info files, however, rather than duplicating the texinfo2
588 distribution, generate @file{gdb-all.texinfo} locally, and include the files
589 @file{gdb.info*} in the distribution. Note the plural; @code{makeinfo} will
590 split the document into one overall file and five or so included files.
593 @node Partial Symbol Tables, BFD support for GDB, Releases, Top
594 @chapter Partial Symbol Tables
596 GDB has three types of symbol tables.
599 @item full symbol tables (symtabs). These contain the main
600 information about symbols and addresses.
601 @item partial symbol tables (psymtabs). These contain enough
602 information to know when to read the corresponding
603 part of the full symbol table.
604 @item minimal symbol tables (msymtabs). These contain information
605 gleaned from non-debugging symbols.
608 This section describes partial symbol tables.
610 A psymtab is constructed by doing a very quick pass over an executable
611 file's debugging information. Small amounts of information are
612 extracted -- enough to identify which parts of the symbol table will
613 need to be re-read and fully digested later, when the user needs the
614 information. The speed of this pass causes GDB to start up very
615 quickly. Later, as the detailed rereading occurs, it occurs in small
616 pieces, at various times, and the delay therefrom is mostly invisible to
617 the user. (@xref{Symbol Reading}.)
619 The symbols that show up in a file's psymtab should be, roughly, those
620 visible to the debugger's user when the program is not running code from
621 that file. These include external symbols and types, static
622 symbols and types, and enum values declared at file scope.
624 The psymtab also contains the range of instruction addresses that the
625 full symbol table would represent.
627 The idea is that there are only two ways for the user (or much of
628 the code in the debugger) to reference a symbol:
633 (e.g. execution stops at some address which is inside a function
634 in this file). The address will be noticed to be in the
635 range of this psymtab, and the full symtab will be read in.
636 @code{find_pc_function}, @code{find_pc_line}, and other @code{find_pc_@dots{}}
637 functions handle this.
640 (e.g. the user asks to print a variable, or set a breakpoint on a
641 function). Global names and file-scope names will be found in the
642 psymtab, which will cause the symtab to be pulled in. Local names will
643 have to be qualified by a global name, or a file-scope name, in which
644 case we will have already read in the symtab as we evaluated the
645 qualifier. Or, a local symbol can be referenced when
646 we are "in" a local scope, in which case the first case applies.
647 @code{lookup_symbol} does most of the work here.
651 The only reason that psymtabs exist is to cause a symtab to be read in
652 at the right moment. Any symbol that can be elided from a psymtab,
653 while still causing that to happen, should not appear in it. Since
654 psymtabs don't have the idea of scope, you can't put local symbols in
655 them anyway. Psymtabs don't have the idea of the type of a symbol,
656 either, so types need not appear, unless they will be referenced by
659 It is a bug for GDB to behave one way when only a psymtab has been read,
660 and another way if the corresponding symtab has been read in. Such
661 bugs are typically caused by a psymtab that does not contain all the
662 visible symbols, or which has the wrong instruction address ranges.
664 The psymtab for a particular section of a symbol-file (objfile)
665 could be thrown away after the symtab has been read in. The symtab
666 should always be searched before the psymtab, so the psymtab will
667 never be used (in a bug-free environment). Currently,
668 psymtabs are allocated on an obstack, and all the psymbols themselves
669 are allocated in a pair of large arrays on an obstack, so there is
670 little to be gained by trying to free them unless you want to do a lot
673 @node BFD support for GDB, Symbol Reading, Partial Symbol Tables, Top
674 @chapter Binary File Descriptor Library Support for GDB
676 BFD provides support for GDB in several ways:
679 @item identifying executable and core files
680 BFD will identify a variety of file types, including a.out, coff, and
681 several variants thereof, as well as several kinds of core files.
683 @item access to sections of files
684 BFD parses the file headers to determine the names, virtual addresses,
685 sizes, and file locations of all the various named sections in files
686 (such as the text section or the data section). GDB simply calls
687 BFD to read or write section X at byte offset Y for length Z.
689 @item specialized core file support
690 BFD provides routines to determine the failing command name stored
691 in a core file, the signal with which the program failed, and whether
692 a core file matches (i.e. could be a core dump of) a particular executable
695 @item locating the symbol information
696 GDB uses an internal interface of BFD to determine where to find the
697 symbol information in an executable file or symbol-file. GDB itself
698 handles the reading of symbols, since BFD does not ``understand'' debug
699 symbols, but GDB uses BFD's cached information to find the symbols,
703 @c The interface for symbol reading is described in @ref{Symbol
704 @c Reading,,Symbol Reading}.
707 @node Symbol Reading, Cleanups, BFD support for GDB, Top
708 @chapter Symbol Reading
710 GDB reads symbols from "symbol files". The usual symbol file is the
711 file containing the program which gdb is debugging. GDB can be directed
712 to use a different file for symbols (with the ``symbol-file''
713 command), and it can also read more symbols via the ``add-file'' and ``load''
714 commands, or while reading symbols from shared libraries.
716 Symbol files are initially opened by @file{symfile.c} using the BFD
717 library. BFD identifies the type of the file by examining its header.
718 @code{symfile_init} then uses this identification to locate a
719 set of symbol-reading functions.
721 Symbol reading modules identify themselves to GDB by calling
722 @code{add_symtab_fns} during their module initialization. The argument
723 to @code{add_symtab_fns} is a @code{struct sym_fns} which contains
724 the name (or name prefix) of the symbol format, the length of the prefix,
725 and pointers to four functions. These functions are called at various
726 times to process symbol-files whose identification matches the specified
729 The functions supplied by each module are:
732 @item @var{xxx}_symfile_init(struct sym_fns *sf)
734 Called from @code{symbol_file_add} when we are about to read a new
735 symbol file. This function should clean up any internal state
736 (possibly resulting from half-read previous files, for example)
737 and prepare to read a new symbol file. Note that the symbol file
738 which we are reading might be a new "main" symbol file, or might
739 be a secondary symbol file whose symbols are being added to the
740 existing symbol table.
742 The argument to @code{@var{xxx}_symfile_init} is a newly allocated
743 @code{struct sym_fns} whose @code{bfd} field contains the BFD
744 for the new symbol file being read. Its @code{private} field
745 has been zeroed, and can be modified as desired. Typically,
746 a struct of private information will be @code{malloc}'d, and
747 a pointer to it will be placed in the @code{private} field.
749 There is no result from @code{@var{xxx}_symfile_init}, but it can call
750 @code{error} if it detects an unavoidable problem.
752 @item @var{xxx}_new_init()
754 Called from @code{symbol_file_add} when discarding existing symbols.
755 This function need only handle
756 the symbol-reading module's internal state; the symbol table data
757 structures visible to the rest of GDB will be discarded by
758 @code{symbol_file_add}. It has no arguments and no result.
759 It may be called after @code{@var{xxx}_symfile_init}, if a new symbol
760 table is being read, or may be called alone if all symbols are
761 simply being discarded.
763 @item @var{xxx}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)
765 Called from @code{symbol_file_add} to actually read the symbols from a
766 symbol-file into a set of psymtabs or symtabs.
768 @code{sf} points to the struct sym_fns originally passed to
769 @code{@var{xxx}_sym_init} for possible initialization. @code{addr} is the
770 offset between the file's specified start address and its true address
771 in memory. @code{mainline} is 1 if this is the main symbol table being
772 read, and 0 if a secondary symbol file (e.g. shared library or
773 dynamically loaded file) is being read.@refill
776 In addition, if a symbol-reading module creates psymtabs when
777 @var{xxx}_symfile_read is called, these psymtabs will contain a pointer to
778 a function @code{@var{xxx}_psymtab_to_symtab}, which can be called from
779 any point in the GDB symbol-handling code.
782 @item @var{xxx}_psymtab_to_symtab (struct partial_symtab *pst)
784 Called from @code{psymtab_to_symtab} (or the PSYMTAB_TO_SYMTAB
785 macro) if the psymtab has not already been read in and had its
786 @code{pst->symtab} pointer set. The argument is the psymtab
787 to be fleshed-out into a symtab. Upon return, pst->readin
788 should have been set to 1, and pst->symtab should contain a
789 pointer to the new corresponding symtab, or zero if there
790 were no symbols in that part of the symbol file.
794 @node Cleanups, Wrapping, Symbol Reading, Top
797 Cleanups are a structured way to deal with things that need to be done
798 later. When your code does something (like @code{malloc} some memory, or open
799 a file) that needs to be undone later (e.g. free the memory or close
800 the file), it can make a cleanup. The cleanup will be done at some
801 future point: when the command is finished, when an error occurs, or
802 when your code decides it's time to do cleanups.
804 You can also discard cleanups, that is, throw them away without doing
805 what they say. This is only done if you ask that it be done.
810 @item @var{old_chain} = make_cleanup (@var{function}, @var{arg});
811 Make a cleanup which will cause @var{function} to be called with @var{arg}
812 (a @code{char *}) later. The result, @var{old_chain}, is a handle that can be
813 passed to @code{do_cleanups} or @code{discard_cleanups} later. Unless you are
814 going to call @code{do_cleanups} or @code{discard_cleanups} yourself,
815 you can ignore the result from @code{make_cleanup}.
818 @item do_cleanups (@var{old_chain});
819 Perform all cleanups done since @code{make_cleanup} returned @var{old_chain}.
823 old = make_cleanup (b, 0);
827 will call @code{b()} but will not call @code{a()}. The cleanup that calls @code{a()} will remain
828 in the cleanup chain, and will be done later unless otherwise discarded.@refill
830 @item discard_cleanups (@var{old_chain});
831 Same as @code{do_cleanups} except that it just removes the cleanups from the
832 chain and does not call the specified functions.
836 Some functions, e.g. @code{fputs_filtered()} or @code{error()}, specify that they
837 ``should not be called when cleanups are not in place''. This means
838 that any actions you need to reverse in the case of an error or
839 interruption must be on the cleanup chain before you call these functions,
840 since they might never return to your code (they @samp{longjmp} instead).
843 @node Wrapping, Frames, Cleanups, Top
844 @chapter Wrapping Output Lines
846 Output that goes through @code{printf_filtered} or @code{fputs_filtered} or
847 @code{fputs_demangled} needs only to have calls to @code{wrap_here} added
848 in places that would be good breaking points. The utility routines
849 will take care of actually wrapping if the line width is exceeded.
851 The argument to @code{wrap_here} is an indentation string which is printed
852 @emph{only} if the line breaks there. This argument is saved away and used
853 later. It must remain valid until the next call to @code{wrap_here} or
854 until a newline has been printed through the @code{*_filtered} functions.
855 Don't pass in a local variable and then return!
857 It is usually best to call @code{wrap_here()} after printing a comma or space.
858 If you call it before printing a space, make sure that your indentation
859 properly accounts for the leading space that will print if the line wraps
862 Any function or set of functions that produce filtered output must finish
863 by printing a newline, to flush the wrap buffer, before switching to
864 unfiltered (``@code{printf}'') output. Symbol reading routines that print
865 warnings are a good example.
868 @node Frames, , Wrapping, Top
871 A frame is a construct that GDB uses to keep track of calling and called
876 in the machine description has no meaning to the machine-independent
877 part of GDB, except that it is used when setting up a new frame from
881 create_new_frame (read_register (FP_REGNUM), read_pc ()));
884 Other than that, all the meaning imparted to @code{FP_REGNUM} is imparted by
885 the machine-dependent code. So, @code{FP_REGNUM} can have any value that
886 is convenient for the code that creates new frames. (@code{create_new_frame}
887 calls @code{INIT_EXTRA_FRAME_INFO} if it is defined; that is where you should
888 use the @code{FP_REGNUM} value, if your frames are nonstandard.)
891 Given a GDB frame, determine the address of the calling function's
892 frame. This will be used to create a new GDB frame struct, and then
893 @code{INIT_EXTRA_FRAME_INFO} and @code{INIT_FRAME_PC} will be called for
897 @node Host Conditionals, , , Top
898 @chapter Host Conditionals
900 When GDB is configured and compiled, various macros are defined or left
901 undefined, to control compilation based on the attributes of the host
902 system. These macros and their meanings are:
904 @emph{NOTE: For now, both host and target conditionals are here.
905 Eliminate target conditionals from this list as they are identified.}
910 @item BLOCK_ADDRESS_FUNCTION_RELATIVE
912 @item GDBINIT_FILENAME
916 @item MEM_FNS_DECLARED
922 @item PYRAMID_CONTROL_FRAME_DEBUGGING
924 @item SIGWINCH_HANDLER_BODY
942 @item ADDITIONAL_OPTIONS
944 @item ADDITIONAL_OPTION_CASES
946 @item ADDITIONAL_OPTION_HANDLER
948 @item ADDITIONAL_OPTION_HELP
950 @item ADDR_BITS_REMOVE
952 @item AIX_BUGGY_PTRACE_CONTINUE
954 @item ALIGN_STACK_ON_STARTUP
968 @item BEFORE_MAIN_LOOP_HOOK
970 @item BELIEVE_PCC_PROMOTION
972 @item BELIEVE_PCC_PROMOTION_TYPE
976 @item BITS_BIG_ENDIAN
980 @item BLOCK_ADDRESS_ABSOLUTE
986 @item BREAKPOINT_DEBUG
988 @item BROKEN_LARGE_ALLOCA
994 @item CALL_DUMMY_LOCATION
996 @item CALL_DUMMY_STACK_ADJUST
998 @item CANNOT_FETCH_REGISTER
1000 @item CANNOT_STORE_REGISTER
1002 @item CFRONT_PRODUCER
1004 @item CHILD_PREPARE_TO_STORE
1006 @item CLEAR_DEFERRED_STORES
1010 @item COFF_ENCAPSULATE
1014 @item COFF_NO_LONG_FILE_NAMES
1016 @item CORE_NEEDS_RELOCATION
1020 @item CREATE_INFERIOR_HOOK
1030 @item DBX_PARM_SYMBOL_CLASS
1038 @item DECR_PC_AFTER_BREAK
1040 @item DEFAULT_PROMPT
1048 @item DISABLE_UNSETTABLE_BREAK
1050 @item DONT_USE_REMOTE
1052 @item DO_DEFERRED_STORES
1054 @item DO_REGISTERS_INFO
1056 @item END_OF_TEXT_DEFAULT
1060 @item EXTRACT_RETURN_VALUE
1062 @item EXTRACT_STRUCT_VALUE_ADDRESS
1064 @item EXTRA_FRAME_INFO
1066 @item EXTRA_SYMTAB_INFO
1068 @item FETCH_INFERIOR_REGISTERS
1069 Define this if the native-dependent code will provide its
1071 @code{fetch_inferior_registers} and @code{store_inferior_registers}.
1072 If this symbol is @emph{not} defined, the default routines in
1073 @file{infptrace.c} are used for these functions.
1074 @item FILES_INFO_HOOK
1088 @item FRAMELESS_FUNCTION_INVOCATION
1090 @item FRAME_ARGS_ADDRESS_CORRECT
1092 @item FRAME_CHAIN_COMBINE
1094 @item FRAME_CHAIN_VALID
1096 @item FRAME_CHAIN_VALID_ALTERNATE
1098 @item FRAME_FIND_SAVED_REGS
1100 @item FRAME_GET_BASEREG_VALUE
1102 @item FRAME_NUM_ARGS
1104 @item FRAME_SPECIFICATION_DYADIC
1106 @item FUNCTION_EPILOGUE_SIZE
1110 @item GCC2_COMPILED_FLAG_SYMBOL
1112 @item GCC_COMPILED_FLAG_SYMBOL
1114 @item GCC_MANGLE_BUG
1118 @item GDB_TARGET_IS_MACH386
1120 @item GDB_TARGET_IS_SUN3
1122 @item GDB_TARGET_IS_SUN386
1124 @item GET_LONGJMP_TARGET
1126 @item GET_SAVED_REGISTER
1128 @item GPLUS_PRODUCER
1140 @item HAVE_REGISTER_WINDOWS
1142 @item HAVE_SIGSETMASK
1146 @item HEADER_SEEK_FD
1150 @item HOST_BYTE_ORDER
1154 @item HPUX_VERSION_5
1162 @item IBM6000_TARGET
1170 @item INIT_EXTRA_FRAME_INFO
1172 @item INIT_EXTRA_SYMTAB_INFO
1186 @item IN_SOLIB_TRAMPOLINE
1190 @item IS_TRAPPED_INTERNALVAR
1194 @item KERNEL_DEBUGGING
1197 Define this to the address of the @code{u} structure (the ``user struct'',
1198 also known as the ``u-page'') in kernel virtual memory. GDB needs to know
1199 this so that it can subtract this address from absolute addresses in
1200 the upage, that are obtained via ptrace or from core files. On systems
1201 that don't need this value, set it to zero.
1202 @item KERNEL_U_ADDR_BSD
1203 Define this to cause GDB to determine the address of @code{u} at runtime,
1204 by using Berkeley-style @code{nlist} on the kernel's image in the root
1206 @item KERNEL_U_ADDR_HPUX
1207 Define this to cause GDB to determine the address of @code{u} at runtime,
1208 by using HP-style @code{nlist} on the kernel's image in the root
1224 @item LSEEK_NOT_LINEAR
1230 @item MACHKERNELDEBUG
1236 @item MAINTENANCE_CMDS
1238 @item MAINTENANCE_CMDS
1240 @item MALLOC_INCOMPATIBLE
1244 @item MMAP_BASE_ADDRESS
1250 @item NAMES_HAVE_UNDERSCORE
1254 @item NEED_POSIX_SETPGID
1256 @item NEED_TEXT_START_END
1270 @item NOTICE_SIGNAL_HANDLING_CHANGE
1272 @item NO_DEFINE_SYMBOL
1274 @item NO_HIF_SUPPORT
1276 @item NO_JOB_CONTROL
1278 @item NO_MALLOC_CHECK
1286 @item NO_SIGINTERRUPT
1288 @item NO_SINGLE_STEP
1296 @item NS32K_SVC_IMMED_OPERANDS
1298 @item NUMERIC_REG_NAMES
1306 @item ONE_PROCESS_WRITETEXT
1314 @item PCC_SOL_BROKEN
1316 @item PC_IN_CALL_DUMMY
1318 @item PC_LOAD_SEGMENT
1322 @item PRINT_RANDOM_SIGNAL
1324 @item PRINT_REGISTER_HOOK
1326 @item PRINT_TYPELESS_INTEGER
1328 @item PROCESS_LINENUMBER_HOOK
1330 @item PROLOGUE_FIRSTLINE_OVERLAP
1332 @item PSIGNAL_IN_SIGNAL_H
1336 @item PTRACE_ARG3_TYPE
1346 @item PUSH_ARGUMENTS
1348 @item PYRAMID_CONTROL_FRAME_DEBUGGING
1352 @item PYRAMID_PTRACE
1354 @item REGISTER_BYTES
1356 @item REGISTER_NAMES
1358 @item REGISTER_U_ADDR
1359 Defines the offset of the registers in the ``u area''; @pxref{Host}.
1360 @item REG_STACK_SEGMENT
1362 @item REG_STRUCT_HAS_ADDR
1370 @item SDB_REG_TO_REGNUM
1378 @item SET_STACK_LIMIT_HUGE
1380 @item SHELL_COMMAND_CONCAT
1384 @item SHIFT_INST_REGS
1386 @item SIGN_EXTEND_CHAR
1388 @item SIGTRAP_STOP_AFTER_LOAD
1392 @item SKIP_PROLOGUE_FRAMELESS_P
1394 @item SKIP_TRAMPOLINE_CODE
1398 @item SOLIB_CREATE_INFERIOR_HOOK
1400 @item SOME_NAMES_HAVE_DOT
1404 @item STAB_REG_TO_REGNUM
1408 @item STACK_DIRECTION
1410 @item START_INFERIOR_TRAPS_EXPECTED
1414 @item STORE_RETURN_VALUE
1416 @item SUN4_COMPILER_FEATURE
1418 @item SUN_FIXED_LBRAC_BUG
1420 @item SVR4_SHARED_LIBS
1422 @item SWITCH_ENUM_BUG
1426 @item SYMBOL_RELOADING_DEFAULT
1446 @item TM_FILE_OVERRIDE
1464 @item USE_STRUCT_CONVENTION
1467 Means that System V (prior to SVR4) include files are in use.
1468 (FIXME: This symbol is abused in @file{infrun.c}, @file{regex.c},
1469 @file{remote-nindy.c}, and @file{utils.c} for other things, at the moment.)
1475 This is the offset of the registers in the upage. It need only be defined
1476 if the generic ptrace register access routines in @file{infptrace.c}
1478 (that is, @code{FETCH_INFERIOR_REGISTERS} is not defined). If the default
1479 value from @file{infptrace.c} is good enough, leave it undefined.
1481 The default value means that u.u_ar0 @emph{points to} the location of the
1482 registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means that
1483 u.u_ar0 @emph{is} the location of the registers.
1484 @item VARIABLES_INSIDE_BLOCK
1496 @item __HAVE_68881__
1500 @item __INT_VARARGS_H
1502 @item __not_on_pyr_yet
1520 @item longest_to_int
1550 @node Target Conditionals, , , Top
1551 @chapter Target Conditionals
1553 When GDB is configured and compiled, various macros are defined or left
1554 undefined, to control compilation based on the attributes of the target
1555 system. These macros and their meanings are:
1557 @emph{NOTE: For now, both host and target conditionals are here.
1558 Eliminate host conditionals from this list as they are identified.}
1563 @item BLOCK_ADDRESS_FUNCTION_RELATIVE
1565 @item GDBINIT_FILENAME
1569 @item MEM_FNS_DECLARED
1575 @item PYRAMID_CONTROL_FRAME_DEBUGGING
1577 @item SIGWINCH_HANDLER_BODY
1579 @item ADDITIONAL_OPTIONS
1581 @item ADDITIONAL_OPTION_CASES
1583 @item ADDITIONAL_OPTION_HANDLER
1585 @item ADDITIONAL_OPTION_HELP
1587 @item ADDR_BITS_REMOVE
1589 @item ALIGN_STACK_ON_STARTUP
1603 @item BEFORE_MAIN_LOOP_HOOK
1605 @item BELIEVE_PCC_PROMOTION
1607 @item BELIEVE_PCC_PROMOTION_TYPE
1611 @item BITS_BIG_ENDIAN
1615 @item BLOCK_ADDRESS_ABSOLUTE
1621 @item BREAKPOINT_DEBUG
1623 @item BROKEN_LARGE_ALLOCA
1629 @item CALL_DUMMY_LOCATION
1631 @item CALL_DUMMY_STACK_ADJUST
1633 @item CANNOT_FETCH_REGISTER
1635 @item CANNOT_STORE_REGISTER
1637 @item CFRONT_PRODUCER
1639 @item CHILD_PREPARE_TO_STORE
1641 @item CLEAR_DEFERRED_STORES
1645 @item COFF_ENCAPSULATE
1649 @item COFF_NO_LONG_FILE_NAMES
1651 @item CORE_NEEDS_RELOCATION
1655 @item CREATE_INFERIOR_HOOK
1665 @item DBX_PARM_SYMBOL_CLASS
1673 @item DECR_PC_AFTER_BREAK
1675 @item DEFAULT_PROMPT
1683 @item DISABLE_UNSETTABLE_BREAK
1685 @item DONT_USE_REMOTE
1687 @item DO_DEFERRED_STORES
1689 @item DO_REGISTERS_INFO
1691 @item END_OF_TEXT_DEFAULT
1695 @item EXTRACT_RETURN_VALUE
1697 @item EXTRACT_STRUCT_VALUE_ADDRESS
1699 @item EXTRA_FRAME_INFO
1701 @item EXTRA_SYMTAB_INFO
1703 @item FILES_INFO_HOOK
1717 @item FRAMELESS_FUNCTION_INVOCATION
1719 @item FRAME_ARGS_ADDRESS_CORRECT
1721 @item FRAME_CHAIN_COMBINE
1723 @item FRAME_CHAIN_VALID
1725 @item FRAME_CHAIN_VALID_ALTERNATE
1727 @item FRAME_FIND_SAVED_REGS
1729 @item FRAME_GET_BASEREG_VALUE
1731 @item FRAME_NUM_ARGS
1733 @item FRAME_SPECIFICATION_DYADIC
1735 @item FUNCTION_EPILOGUE_SIZE
1739 @item GCC2_COMPILED_FLAG_SYMBOL
1741 @item GCC_COMPILED_FLAG_SYMBOL
1743 @item GCC_MANGLE_BUG
1747 @item GDB_TARGET_IS_MACH386
1749 @item GDB_TARGET_IS_SUN3
1751 @item GDB_TARGET_IS_SUN386
1753 @item GET_LONGJMP_TARGET
1755 @item GET_SAVED_REGISTER
1757 @item GPLUS_PRODUCER
1769 @item HAVE_REGISTER_WINDOWS
1771 @item HAVE_SIGSETMASK
1775 @item HEADER_SEEK_FD
1779 @item HOST_BYTE_ORDER
1783 @item HPUX_VERSION_5
1791 @item IBM6000_TARGET
1799 @item INIT_EXTRA_FRAME_INFO
1801 @item INIT_EXTRA_SYMTAB_INFO
1815 @item IN_SOLIB_TRAMPOLINE
1819 @item IS_TRAPPED_INTERNALVAR
1823 @item KERNEL_DEBUGGING
1839 @item LSEEK_NOT_LINEAR
1845 @item MACHKERNELDEBUG
1851 @item MAINTENANCE_CMDS
1853 @item MAINTENANCE_CMDS
1857 @item MMAP_BASE_ADDRESS
1861 @item NAMES_HAVE_UNDERSCORE
1865 @item NEED_POSIX_SETPGID
1867 @item NEED_TEXT_START_END
1881 @item NOTICE_SIGNAL_HANDLING_CHANGE
1883 @item NO_DEFINE_SYMBOL
1885 @item NO_HIF_SUPPORT
1887 @item NO_JOB_CONTROL
1889 @item NO_MALLOC_CHECK
1897 @item NO_SIGINTERRUPT
1899 @item NO_SINGLE_STEP
1907 @item NS32K_SVC_IMMED_OPERANDS
1909 @item NUMERIC_REG_NAMES
1917 @item ONE_PROCESS_WRITETEXT
1921 @item PCC_SOL_BROKEN
1923 @item PC_IN_CALL_DUMMY
1925 @item PC_LOAD_SEGMENT
1929 @item PRINT_RANDOM_SIGNAL
1931 @item PRINT_REGISTER_HOOK
1933 @item PRINT_TYPELESS_INTEGER
1935 @item PROCESS_LINENUMBER_HOOK
1937 @item PROLOGUE_FIRSTLINE_OVERLAP
1939 @item PSIGNAL_IN_SIGNAL_H
1943 @item PTRACE_ARG3_TYPE
1947 @item PUSH_ARGUMENTS
1949 @item REGISTER_BYTES
1951 @item REGISTER_NAMES
1953 @item REG_STACK_SEGMENT
1955 @item REG_STRUCT_HAS_ADDR
1963 @item SDB_REG_TO_REGNUM
1971 @item SET_STACK_LIMIT_HUGE
1973 @item SHELL_COMMAND_CONCAT
1977 @item SHIFT_INST_REGS
1979 @item SIGN_EXTEND_CHAR
1981 @item SIGTRAP_STOP_AFTER_LOAD
1985 @item SKIP_PROLOGUE_FRAMELESS_P
1987 @item SKIP_TRAMPOLINE_CODE
1991 @item SOLIB_CREATE_INFERIOR_HOOK
1993 @item SOME_NAMES_HAVE_DOT
1997 @item STAB_REG_TO_REGNUM
2001 @item STACK_DIRECTION
2003 @item START_INFERIOR_TRAPS_EXPECTED
2007 @item STORE_RETURN_VALUE
2009 @item SUN4_COMPILER_FEATURE
2011 @item SUN_FIXED_LBRAC_BUG
2013 @item SVR4_SHARED_LIBS
2015 @item SWITCH_ENUM_BUG
2019 @item SYMBOL_RELOADING_DEFAULT
2025 @item TARGET_BYTE_ORDER
2027 @item TARGET_CHAR_BIT
2029 @item TARGET_COMPLEX_BIT
2031 @item TARGET_DOUBLE_BIT
2033 @item TARGET_DOUBLE_COMPLEX_BIT
2035 @item TARGET_FLOAT_BIT
2037 @item TARGET_INT_BIT
2039 @item TARGET_LONG_BIT
2041 @item TARGET_LONG_DOUBLE_BIT
2043 @item TARGET_LONG_LONG_BIT
2045 @item TARGET_PTR_BIT
2047 @item TARGET_SHORT_BIT
2051 @item TM_FILE_OVERRIDE
2063 @item USE_STRUCT_CONVENTION
2069 @item VARIABLES_INSIDE_BLOCK
2079 @item __HAVE_68881__
2083 @item __INT_VARARGS_H
2085 @item __not_on_pyr_yet
2097 @item longest_to_int