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 * Coding Style:: Strunk and White for GDB maintainers
84 * Host Conditionals:: Controlling what features exist in the host
85 * Target Conditionals:: Controlling what features exist in the target
86 * Native Conditionals:: Native Conditionals
90 @node README, New Architectures, Top, Top
91 @chapter The @file{README} File
93 Check the @file{README} file, it often has useful information that does not
94 appear anywhere else in the directory.
97 @node New Architectures, Config, README, Top
98 @chapter Defining a New Host or Target Architecture
100 When building support for a new host and/or target, much of the work you
101 need to do is handled by specifying configuration files;
102 @pxref{Config,,Adding a New Configuration}. Further work can be
103 divided into ``host-dependent'' (@pxref{Host,,Adding a New Host}) and
104 ``target-dependent'' (@pxref{Target,,Adding a New Target}). The
105 following discussion is meant to explain the difference between hosts
108 @heading What is considered ``host-dependent'' versus ``target-dependent''?
110 @dfn{Host} refers to attributes of the system where GDB runs.
111 @dfn{Target} refers to the system where the program being debugged
112 executes. In most cases they are the same machine; unfortunately, that
113 means you must add @emph{both} host and target support for new machines
116 The @file{config/mh-*}, @file{xm-*.h} and @file{*-xdep.c} files are for
117 host support. Similarly, the @file{config/mt-*}, @file{tm-*.h} and
118 @file{*-tdep.c} files are for target support. The question is, what
119 features or aspects of a debugging or cross-debugging environment are
120 considered to be ``host'' support?
122 Defines and include files needed to build on the host are host support.
123 Examples are tty support, system defined types, host byte order, host
126 Unix child process support is considered an aspect of the host. Since
127 when you fork on the host you are still on the host, the various macros
128 needed for finding the registers in the upage, running @code{ptrace}, and such
129 are all in the host-dependent files.
131 @c FIXME so what kinds of things are target support?
133 This is still somewhat of a grey area; I (John Gilmore) didn't do the
134 @file{xm-*} and @file{tm-*} split for gdb (it was done by Jim Kingdon)
135 so I have had to figure out the grounds on which it was split, and make
136 my own choices as I evolve it. I have moved many things out of the xdep
137 files actually, partly as a result of BFD and partly by removing
141 @node Config, Host, New Architectures, Top
142 @chapter Adding a New Configuration
144 Most of the work in making GDB compile on a new machine is in specifying
145 the configuration of the machine. This is done in a dizzying variety of
146 header files and configuration scripts, which we hope to make more
147 sensible soon. Let's say your new host is called an @var{xxx} (e.g.
148 @samp{sun4}), and its full three-part configuration name is
149 @code{@var{xarch}-@var{xvend}-@var{xos}} (e.g. @samp{sparc-sun-sunos4}). In
152 In the top level directory, edit @file{config.sub} and add @var{xarch},
153 @var{xvend}, and @var{xos} to the lists of supported architectures,
154 vendors, and operating systems near the bottom of the file. Also, add
155 @var{xxx} as an alias that maps to
156 @code{@var{xarch}-@var{xvend}-@var{xos}}. You can test your changes by
160 ./config.sub @var{xxx}
165 ./config.sub @code{@var{xarch}-@var{xvend}-@var{xos}}
168 which should both respond with @code{@var{xarch}-@var{xvend}-@var{xos}}
169 and no error messages.
171 Now, go to the @file{bfd} directory and
172 create a new file @file{bfd/hosts/h-@var{xxx}.h}. Examine the
173 other @file{h-*.h} files as templates, and create one that brings in the
174 right include files for your system, and defines any host-specific
175 macros needed by GDB.
177 Then edit @file{bfd/configure.in}. Add shell script code to recognize your
178 @code{@var{xarch}-@var{xvend}-@var{xos}} configuration, and set
179 @code{my_host} to @var{xxx} when you recognize it. This will cause your
180 file @file{h-@var{xxx}.h} to be linked to @file{sysdep.h} at configuration
183 Also, if this host requires any changes to the Makefile, create a file
184 @file{bfd/config/mh-@var{xxx}}, which includes the required lines.
186 (If you have the binary utilities and/or GNU ld in the same tree,
187 you'll also have to edit @file{binutils/configure.in} or
188 @file{ld/configure.in} to match what you've done in the @file{bfd}
191 It's possible that the @file{libiberty} and @file{readline} directories
192 won't need any changes for your configuration, but if they do, you can
193 change the @file{configure.in} file there to recognize your system and
194 map to an @file{mh-@var{xxx}} file. Then add @file{mh-@var{xxx}}
195 to the @file{config/} subdirectory, to set any makefile variables you
196 need. The only current options in there are things like @samp{-DSYSV}.
198 Aha! Now to configure GDB itself! Edit
199 @file{gdb/configure.in} to recognize your system and set @code{gdb_host}
200 to @var{xxx}, and (unless your desired target is already available) also
201 set @code{gdb_target} to something appropriate (for instance,
202 @var{xxx}). To handle new hosts, modify the segment after the comment
203 @samp{# per-host}; to handle new targets, modify after @samp{#
205 @c Would it be simpler to just use different per-host and per-target
206 @c *scripts*, and call them from {configure} ?
208 Finally, you'll need to specify and define GDB's host- and
209 target-dependent @file{.h} and @file{.c} files used for your
210 configuration; the next two chapters discuss those.
213 @node Host, Target, Config, Top
214 @chapter Adding a New Host
216 Once you have specified a new configuration for your host
217 (@pxref{Config,,Adding a New Configuration}), there are two remaining
218 pieces to making GDB work on a new machine. First, you have to make it
219 host on the new machine (compile there, handle that machine's terminals
220 properly, etc). If you will be cross-debugging to some other kind of
221 system that's already supported, you are done.
223 If you want to use GDB to debug programs that run on the new machine,
224 you have to get it to understand the machine's object files, symbol
225 files, and interfaces to processes. @pxref{Target,,Adding a New Target}
227 Several files control GDB's configuration for host systems:
230 @item gdb/config/mh-@var{xxx}
231 Specifies Makefile fragments needed when hosting on machine @var{xxx}.
232 In particular, this lists the required machine-dependent object files,
233 by defining @samp{XDEPFILES=@dots{}}. Also
234 specifies the header file which describes host @var{xxx}, by defining
235 @samp{XM_FILE= xm-@var{xxx}.h}. You can also define @samp{CC},
236 @samp{REGEX} and @samp{REGEX1}, @samp{SYSV_DEFINE}, @samp{XM_CFLAGS},
237 @samp{XM_ADD_FILES}, @samp{XM_CLIBS}, @samp{XM_CDEPS},
238 etc.; see @file{Makefile.in}.
240 @item gdb/xm-@var{xxx}.h
241 (@file{xm.h} is a link to this file, created by configure).
242 Contains C macro definitions describing the host system environment,
243 such as byte order, host C compiler and library, ptrace support,
244 and core file structure. Crib from existing @file{xm-*.h} files
247 @item gdb/@var{xxx}-xdep.c
248 Contains any miscellaneous C code required for this machine
249 as a host. On some machines it doesn't exist at all.
252 There are some ``generic'' versions of routines that can be used by
253 various host systems. These can be customized in various ways by macros
254 defined in your @file{xm-@var{xxx}.h} file. If these routines work for
255 the @var{xxx} host, you can just include the generic file's name (with
256 @samp{.o}, not @samp{.c}) in @code{XDEPFILES}.
258 Otherwise, if your machine needs custom support routines, you will need
259 to write routines that perform the same functions as the generic file.
260 Put them into @code{@var{xxx}-xdep.c}, and put @code{@var{xxx}-xdep.o}
261 into @code{XDEPFILES}.
263 @subheading Generic Host Support Files
268 This is the low level interface to inferior processes for systems
269 using the Unix @code{ptrace} call in a vanilla way.
271 @item coredep.c::fetch_core_registers()
272 Support for reading registers out of a core file. This routine calls
273 @code{register_addr()}, see below.
274 Now that BFD is used to read core files, virtually all machines should
275 use @code{coredep.c}, and should just provide @code{fetch_core_registers} in
276 @code{@var{xxx}-xdep.c} (or @code{REGISTER_U_ADDR} in @code{xm-@var{xxx}.h}).
278 @item coredep.c::register_addr()
279 If your @code{xm-@var{xxx}.h} file defines the macro
280 @code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to
281 set @code{addr} to the offset within the @samp{user}
282 struct of GDB register number @code{regno}. @code{blockend} is the
283 offset within the ``upage'' of @code{u.u_ar0}.
284 If @code{REGISTER_U_ADDR} is defined,
285 @file{coredep.c} will define the @code{register_addr()} function and use
286 the macro in it. If you do not define @code{REGISTER_U_ADDR}, but you
287 are using the standard @code{fetch_core_registers()}, you will need to
288 define your own version of @code{register_addr()}, put it into your
289 @code{@var{xxx}-xdep.c} file, and be sure @code{@var{xxx}-xdep.o} is in
290 the @code{XDEPFILES} list. If you have your own
291 @code{fetch_core_registers()}, you may not need a separate
292 @code{register_addr()}. Many custom @code{fetch_core_registers()}
293 implementations simply locate the registers themselves.@refill
296 Object files needed when the target system is an @var{xxx} are listed
297 in the file @file{config/mt-@var{xxx}}, in the makefile macro
298 @samp{TDEPFILES = }@dots{}. The header file that defines the target
299 system should be called @file{tm-@var{xxx}.h}, and should be specified
300 as the value of @samp{TM_FILE} in @file{config/mt-@var{xxx}}. You can
301 also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, and @samp{TM_CDEPS} in
302 there; see @file{Makefile.in}.
304 Now, you are now ready to try configuring GDB to compile for your system.
305 From the top level (above @file{bfd}, @file{gdb}, etc), do:
308 ./configure @var{xxx} +target=vxworks960
311 This will configure your system to cross-compile for VxWorks on
312 the Intel 960, which is probably not what you really want, but it's
313 a test case that works at this stage. (You haven't set up to be
314 able to debug programs that run @emph{on} @var{xxx} yet.)
316 If this succeeds, you can try building it all with:
322 Good luck! Comments and suggestions about this section are particularly
323 welcome; send them to @samp{bug-gdb@@prep.ai.mit.edu}.
325 When hosting GDB on a new operating system, to make it possible to debug
326 core files, you will need to either write specific code for parsing your
327 OS's core files, or customize @file{bfd/trad-core.c}. First, use
328 whatever @code{#include} files your machine uses to define the struct of
329 registers that is accessible (possibly in the u-area) in a core file
330 (rather than @file{machine/reg.h}), and an include file that defines whatever
331 header exists on a core file (e.g. the u-area or a @samp{struct core}). Then
332 modify @code{trad_unix_core_file_p()} to use these values to set up the
333 section information for the data segment, stack segment, any other
334 segments in the core file (perhaps shared library contents or control
335 information), ``registers'' segment, and if there are two discontiguous
336 sets of registers (e.g. integer and float), the ``reg2'' segment. This
337 section information basically delimits areas in the core file in a
338 standard way, which the section-reading routines in BFD know how to seek
341 Then back in GDB, you need a matching routine called
342 @code{fetch_core_registers()}. If you can use the generic one, it's in
343 @file{core-dep.c}; if not, it's in your @file{@var{xxx}-xdep.c} file.
344 It will be passed a char pointer to the entire ``registers'' segment,
345 its length, and a zero; or a char pointer to the entire ``regs2''
346 segment, its length, and a 2. The routine should suck out the supplied
347 register values and install them into GDB's ``registers'' array.
348 (@xref{New Architectures,,Defining a New Host or Target Architecture},
349 for more info about this.)
352 @node Target, Languages, Host, Top
353 @chapter Adding a New Target
355 For a new target called @var{ttt}, first specify the configuration as
356 described in @ref{Config,,Adding a New Configuration}. If your new
357 target is the same as your new host, you've probably already done that.
359 A variety of files specify attributes of the GDB target environment:
362 @item gdb/config/mt-@var{ttt}
363 Contains a Makefile fragment specific to this target.
364 Specifies what object files are needed for target @var{ttt}, by
365 defining @samp{TDEPFILES=@dots{}}.
366 Also specifies the header file which describes @var{ttt}, by defining
367 @samp{TM_FILE= tm-@var{ttt}.h}. You can also define @samp{TM_CFLAGS},
368 and other Makefile variables here; see @file{Makefile.in}.
370 @item gdb/tm-@var{ttt}.h
371 (@file{tm.h} is a link to this file, created by configure).
372 Contains macro definitions about the target machine's
373 registers, stack frame format and instructions.
374 Crib from existing @file{tm-*.h} files when building a new one.
376 @item gdb/@var{ttt}-tdep.c
377 Contains any miscellaneous code required for this target machine.
378 On some machines it doesn't exist at all. Sometimes the macros
379 in @file{tm-@var{ttt}.h} become very complicated, so they are
380 implemented as functions here instead, and the macro is simply
381 defined to call the function.
384 Defines functions for accessing files that are
385 executable on the target system. These functions open and examine an
386 exec file, extract data from one, write data to one, print information
387 about one, etc. Now that executable files are handled with BFD, every
388 target should be able to use the generic exec.c rather than its
391 @item gdb/@var{arch}-pinsn.c
392 Prints (disassembles) the target machine's instructions.
393 This file is usually shared with other target machines which use the
394 same processor, which is why it is @file{@var{arch}-pinsn.c} rather
395 than @file{@var{ttt}-pinsn.c}.
397 @item gdb/@var{arch}-opcode.h
398 Contains some large initialized
399 data structures describing the target machine's instructions.
400 This is a bit strange for a @file{.h} file, but it's OK since
401 it is only included in one place. @file{@var{arch}-opcode.h} is shared
402 between the debugger and the assembler, if the GNU assembler has been
403 ported to the target machine.
405 @item gdb/tm-@var{arch}.h
406 This often exists to describe the basic layout of the target machine's
407 processor chip (registers, stack, etc).
408 If used, it is included by @file{tm-@var{xxx}.h}. It can
409 be shared among many targets that use the same processor.
411 @item gdb/@var{arch}-tdep.c
412 Similarly, there are often common subroutines that are shared by all
413 target machines that use this particular architecture.
416 When adding support for a new target machine, there are various areas
417 of support that might need change, or might be OK.
419 If you are using an existing object file format (a.out or COFF),
420 there is probably little to be done. See @file{bfd/doc/bfd.texinfo}
421 for more information on writing new a.out or COFF versions.
423 If you need to add a new object file format, you are beyond the scope
424 of this document right now. Look at the structure of the a.out
425 and COFF support, build a transfer vector (@code{xvec}) for your new format,
426 and start populating it with routines. Add it to the list in
427 @file{bfd/targets.c}.
429 If you are adding a new operating system for an existing CPU chip, add a
430 @file{tm-@var{xos}.h} file that describes the operating system
431 facilities that are unusual (extra symbol table info; the breakpoint
432 instruction needed; etc). Then write a
433 @file{tm-@var{xarch}-@var{xos}.h} that just @code{#include}s
434 @file{tm-@var{xarch}.h} and @file{tm-@var{xos}.h}. (Now that we have
435 three-part configuration names, this will probably get revised to
436 separate the @var{xos} configuration from the @var{xarch}
440 @node Languages, Releases, Target, Top
441 @chapter Adding a Source Language to GDB
443 To add other languages to GDB's expression parser, follow the following steps:
446 @item Create the expression parser.
448 This should reside in a file @file{@var{lang}-exp.y}. Routines for building
449 parsed expressions into a @samp{union exp_element} list are in @file{parse.c}.
451 Since we can't depend upon everyone having Bison, and YACC produces
452 parsers that define a bunch of global names, the following lines
453 @emph{must} be included at the top of the YACC parser, to prevent
454 the various parsers from defining the same global names:
457 #define yyparse @var{lang}_parse
458 #define yylex @var{lang}_lex
459 #define yyerror @var{lang}_error
460 #define yylval @var{lang}_lval
461 #define yychar @var{lang}_char
462 #define yydebug @var{lang}_debug
463 #define yypact @var{lang}_pact
464 #define yyr1 @var{lang}_r1
465 #define yyr2 @var{lang}_r2
466 #define yydef @var{lang}_def
467 #define yychk @var{lang}_chk
468 #define yypgo @var{lang}_pgo
469 #define yyact @var{lang}_act
470 #define yyexca @var{lang}_exca
471 #define yyerrflag @var{lang}_errflag
472 #define yynerrs @var{lang}_nerrs
475 At the bottom of your parser, define a @code{struct language_defn} and
476 initialize it with the right values for your language. Define an
477 @code{initialize_@var{lang}} routine and have it call
478 @samp{add_language(@var{lang}_language_defn)} to tell the rest of GDB
479 that your language exists. You'll need some other supporting variables
480 and functions, which will be used via pointers from your
481 @code{@var{lang}_language_defn}. See the declaration of @code{struct
482 language_defn} in @file{language.h}, and the other @file{*-exp.y} files,
483 for more information.
485 @item Add any evaluation routines, if necessary
487 If you need new opcodes (that represent the operations of the language),
488 add them to the enumerated type in @file{expression.h}. Add support
489 code for these operations in @code{eval.c:evaluate_subexp()}. Add cases
490 for new opcodes in two functions from @file{parse.c}:
491 @code{prefixify_subexp()} and @code{length_of_subexp()}. These compute
492 the number of @code{exp_element}s that a given operation takes up.
494 @item Update some existing code
496 Add an enumerated identifier for your language to the enumerated type
497 @code{enum language} in @file{defs.h}.
499 Update the routines in @file{language.c} so your language is included. These
500 routines include type predicates and such, which (in some cases) are
501 language dependent. If your language does not appear in the switch
502 statement, an error is reported.
504 Also included in @file{language.c} is the code that updates the variable
505 @code{current_language}, and the routines that translate the
506 @code{language_@var{lang}} enumerated identifier into a printable
509 Update the function @code{_initialize_language} to include your language. This
510 function picks the default language upon startup, so is dependent upon
511 which languages that GDB is built for.
513 Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading
514 code so that the language of each symtab (source file) is set properly.
515 This is used to determine the language to use at each stack frame level.
516 Currently, the language is set based upon the extension of the source
517 file. If the language can be better inferred from the symbol
518 information, please set the language of the symtab in the symbol-reading
521 Add helper code to @code{expprint.c:print_subexp()} to handle any new
522 expression opcodes you have added to @file{expression.h}. Also, add the
523 printed representations of your operators to @code{op_print_tab}.
525 @item Add a place of call
527 Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in
528 @code{parse.c:parse_exp_1()}.
530 @item Use macros to trim code
532 The user has the option of building GDB for some or all of the
533 languages. If the user decides to build GDB for the language
534 @var{lang}, then every file dependent on @file{language.h} will have the
535 macro @code{_LANG_@var{lang}} defined in it. Use @code{#ifdef}s to
536 leave out large routines that the user won't need if he or she is not
539 Note that you do not need to do this in your YACC parser, since if GDB
540 is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the
541 compiled form of your parser) is not linked into GDB at all.
543 See the file @file{configure.in} for how GDB is configured for different
546 @item Edit @file{Makefile.in}
548 Add dependencies in @file{Makefile.in}. Make sure you update the macro
549 variables such as @code{HFILES} and @code{OBJS}, otherwise your code may
550 not get linked in, or, worse yet, it may not get @code{tar}red into the
555 @node Releases, Partial Symbol Tables, Languages, Top
556 @chapter Configuring GDB for Release
558 From the top level directory (containing @file{gdb}, @file{bfd},
559 @file{libiberty}, and so on):
561 make -f Makefile.in gdb.tar.Z
564 This will properly configure, clean, rebuild any files that are
565 distributed pre-built (e.g. @file{c-exp.tab.c} or @file{refcard.ps}),
566 and will then make a tarfile. (If the top level directory has already
567 beenn configured, you can just do @code{make gdb.tar.Z} instead.)
569 This procedure requires:
572 @item @code{makeinfo} (texinfo2 level)
575 @item @code{yacc} or @code{bison}
578 @dots{} and the usual slew of utilities (@code{sed}, @code{tar}, etc.).
580 @subheading TEMPORARY RELEASE PROCEDURE FOR DOCUMENTATION
582 @file{gdb.texinfo} is currently marked up using the texinfo-2 macros,
583 which are not yet a default for anything (but we have to start using
586 For making paper, the only thing this implies is the right generation of
587 @file{texinfo.tex} needs to be included in the distribution.
589 For making info files, however, rather than duplicating the texinfo2
590 distribution, generate @file{gdb-all.texinfo} locally, and include the files
591 @file{gdb.info*} in the distribution. Note the plural; @code{makeinfo} will
592 split the document into one overall file and five or so included files.
595 @node Partial Symbol Tables, BFD support for GDB, Releases, Top
596 @chapter Partial Symbol Tables
598 GDB has three types of symbol tables.
601 @item full symbol tables (symtabs). These contain the main
602 information about symbols and addresses.
603 @item partial symbol tables (psymtabs). These contain enough
604 information to know when to read the corresponding
605 part of the full symbol table.
606 @item minimal symbol tables (msymtabs). These contain information
607 gleaned from non-debugging symbols.
610 This section describes partial symbol tables.
612 A psymtab is constructed by doing a very quick pass over an executable
613 file's debugging information. Small amounts of information are
614 extracted -- enough to identify which parts of the symbol table will
615 need to be re-read and fully digested later, when the user needs the
616 information. The speed of this pass causes GDB to start up very
617 quickly. Later, as the detailed rereading occurs, it occurs in small
618 pieces, at various times, and the delay therefrom is mostly invisible to
619 the user. (@xref{Symbol Reading}.)
621 The symbols that show up in a file's psymtab should be, roughly, those
622 visible to the debugger's user when the program is not running code from
623 that file. These include external symbols and types, static
624 symbols and types, and enum values declared at file scope.
626 The psymtab also contains the range of instruction addresses that the
627 full symbol table would represent.
629 The idea is that there are only two ways for the user (or much of
630 the code in the debugger) to reference a symbol:
635 (e.g. execution stops at some address which is inside a function
636 in this file). The address will be noticed to be in the
637 range of this psymtab, and the full symtab will be read in.
638 @code{find_pc_function}, @code{find_pc_line}, and other @code{find_pc_@dots{}}
639 functions handle this.
642 (e.g. the user asks to print a variable, or set a breakpoint on a
643 function). Global names and file-scope names will be found in the
644 psymtab, which will cause the symtab to be pulled in. Local names will
645 have to be qualified by a global name, or a file-scope name, in which
646 case we will have already read in the symtab as we evaluated the
647 qualifier. Or, a local symbol can be referenced when
648 we are "in" a local scope, in which case the first case applies.
649 @code{lookup_symbol} does most of the work here.
653 The only reason that psymtabs exist is to cause a symtab to be read in
654 at the right moment. Any symbol that can be elided from a psymtab,
655 while still causing that to happen, should not appear in it. Since
656 psymtabs don't have the idea of scope, you can't put local symbols in
657 them anyway. Psymtabs don't have the idea of the type of a symbol,
658 either, so types need not appear, unless they will be referenced by
661 It is a bug for GDB to behave one way when only a psymtab has been read,
662 and another way if the corresponding symtab has been read in. Such
663 bugs are typically caused by a psymtab that does not contain all the
664 visible symbols, or which has the wrong instruction address ranges.
666 The psymtab for a particular section of a symbol-file (objfile)
667 could be thrown away after the symtab has been read in. The symtab
668 should always be searched before the psymtab, so the psymtab will
669 never be used (in a bug-free environment). Currently,
670 psymtabs are allocated on an obstack, and all the psymbols themselves
671 are allocated in a pair of large arrays on an obstack, so there is
672 little to be gained by trying to free them unless you want to do a lot
675 @node BFD support for GDB, Symbol Reading, Partial Symbol Tables, Top
676 @chapter Binary File Descriptor Library Support for GDB
678 BFD provides support for GDB in several ways:
681 @item identifying executable and core files
682 BFD will identify a variety of file types, including a.out, coff, and
683 several variants thereof, as well as several kinds of core files.
685 @item access to sections of files
686 BFD parses the file headers to determine the names, virtual addresses,
687 sizes, and file locations of all the various named sections in files
688 (such as the text section or the data section). GDB simply calls
689 BFD to read or write section X at byte offset Y for length Z.
691 @item specialized core file support
692 BFD provides routines to determine the failing command name stored
693 in a core file, the signal with which the program failed, and whether
694 a core file matches (i.e. could be a core dump of) a particular executable
697 @item locating the symbol information
698 GDB uses an internal interface of BFD to determine where to find the
699 symbol information in an executable file or symbol-file. GDB itself
700 handles the reading of symbols, since BFD does not ``understand'' debug
701 symbols, but GDB uses BFD's cached information to find the symbols,
705 @c The interface for symbol reading is described in @ref{Symbol
706 @c Reading,,Symbol Reading}.
709 @node Symbol Reading, Cleanups, BFD support for GDB, Top
710 @chapter Symbol Reading
712 GDB reads symbols from "symbol files". The usual symbol file is the
713 file containing the program which gdb is debugging. GDB can be directed
714 to use a different file for symbols (with the ``symbol-file''
715 command), and it can also read more symbols via the ``add-file'' and ``load''
716 commands, or while reading symbols from shared libraries.
718 Symbol files are initially opened by @file{symfile.c} using the BFD
719 library. BFD identifies the type of the file by examining its header.
720 @code{symfile_init} then uses this identification to locate a
721 set of symbol-reading functions.
723 Symbol reading modules identify themselves to GDB by calling
724 @code{add_symtab_fns} during their module initialization. The argument
725 to @code{add_symtab_fns} is a @code{struct sym_fns} which contains
726 the name (or name prefix) of the symbol format, the length of the prefix,
727 and pointers to four functions. These functions are called at various
728 times to process symbol-files whose identification matches the specified
731 The functions supplied by each module are:
734 @item @var{xxx}_symfile_init(struct sym_fns *sf)
736 Called from @code{symbol_file_add} when we are about to read a new
737 symbol file. This function should clean up any internal state
738 (possibly resulting from half-read previous files, for example)
739 and prepare to read a new symbol file. Note that the symbol file
740 which we are reading might be a new "main" symbol file, or might
741 be a secondary symbol file whose symbols are being added to the
742 existing symbol table.
744 The argument to @code{@var{xxx}_symfile_init} is a newly allocated
745 @code{struct sym_fns} whose @code{bfd} field contains the BFD
746 for the new symbol file being read. Its @code{private} field
747 has been zeroed, and can be modified as desired. Typically,
748 a struct of private information will be @code{malloc}'d, and
749 a pointer to it will be placed in the @code{private} field.
751 There is no result from @code{@var{xxx}_symfile_init}, but it can call
752 @code{error} if it detects an unavoidable problem.
754 @item @var{xxx}_new_init()
756 Called from @code{symbol_file_add} when discarding existing symbols.
757 This function need only handle
758 the symbol-reading module's internal state; the symbol table data
759 structures visible to the rest of GDB will be discarded by
760 @code{symbol_file_add}. It has no arguments and no result.
761 It may be called after @code{@var{xxx}_symfile_init}, if a new symbol
762 table is being read, or may be called alone if all symbols are
763 simply being discarded.
765 @item @var{xxx}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)
767 Called from @code{symbol_file_add} to actually read the symbols from a
768 symbol-file into a set of psymtabs or symtabs.
770 @code{sf} points to the struct sym_fns originally passed to
771 @code{@var{xxx}_sym_init} for possible initialization. @code{addr} is the
772 offset between the file's specified start address and its true address
773 in memory. @code{mainline} is 1 if this is the main symbol table being
774 read, and 0 if a secondary symbol file (e.g. shared library or
775 dynamically loaded file) is being read.@refill
778 In addition, if a symbol-reading module creates psymtabs when
779 @var{xxx}_symfile_read is called, these psymtabs will contain a pointer to
780 a function @code{@var{xxx}_psymtab_to_symtab}, which can be called from
781 any point in the GDB symbol-handling code.
784 @item @var{xxx}_psymtab_to_symtab (struct partial_symtab *pst)
786 Called from @code{psymtab_to_symtab} (or the PSYMTAB_TO_SYMTAB
787 macro) if the psymtab has not already been read in and had its
788 @code{pst->symtab} pointer set. The argument is the psymtab
789 to be fleshed-out into a symtab. Upon return, pst->readin
790 should have been set to 1, and pst->symtab should contain a
791 pointer to the new corresponding symtab, or zero if there
792 were no symbols in that part of the symbol file.
796 @node Cleanups, Wrapping, Symbol Reading, Top
799 Cleanups are a structured way to deal with things that need to be done
800 later. When your code does something (like @code{malloc} some memory, or open
801 a file) that needs to be undone later (e.g. free the memory or close
802 the file), it can make a cleanup. The cleanup will be done at some
803 future point: when the command is finished, when an error occurs, or
804 when your code decides it's time to do cleanups.
806 You can also discard cleanups, that is, throw them away without doing
807 what they say. This is only done if you ask that it be done.
812 @item @var{old_chain} = make_cleanup (@var{function}, @var{arg});
813 Make a cleanup which will cause @var{function} to be called with @var{arg}
814 (a @code{char *}) later. The result, @var{old_chain}, is a handle that can be
815 passed to @code{do_cleanups} or @code{discard_cleanups} later. Unless you are
816 going to call @code{do_cleanups} or @code{discard_cleanups} yourself,
817 you can ignore the result from @code{make_cleanup}.
820 @item do_cleanups (@var{old_chain});
821 Perform all cleanups done since @code{make_cleanup} returned @var{old_chain}.
825 old = make_cleanup (b, 0);
829 will call @code{b()} but will not call @code{a()}. The cleanup that calls @code{a()} will remain
830 in the cleanup chain, and will be done later unless otherwise discarded.@refill
832 @item discard_cleanups (@var{old_chain});
833 Same as @code{do_cleanups} except that it just removes the cleanups from the
834 chain and does not call the specified functions.
838 Some functions, e.g. @code{fputs_filtered()} or @code{error()}, specify that they
839 ``should not be called when cleanups are not in place''. This means
840 that any actions you need to reverse in the case of an error or
841 interruption must be on the cleanup chain before you call these functions,
842 since they might never return to your code (they @samp{longjmp} instead).
845 @node Wrapping, Frames, Cleanups, Top
846 @chapter Wrapping Output Lines
848 Output that goes through @code{printf_filtered} or @code{fputs_filtered} or
849 @code{fputs_demangled} needs only to have calls to @code{wrap_here} added
850 in places that would be good breaking points. The utility routines
851 will take care of actually wrapping if the line width is exceeded.
853 The argument to @code{wrap_here} is an indentation string which is printed
854 @emph{only} if the line breaks there. This argument is saved away and used
855 later. It must remain valid until the next call to @code{wrap_here} or
856 until a newline has been printed through the @code{*_filtered} functions.
857 Don't pass in a local variable and then return!
859 It is usually best to call @code{wrap_here()} after printing a comma or space.
860 If you call it before printing a space, make sure that your indentation
861 properly accounts for the leading space that will print if the line wraps
864 Any function or set of functions that produce filtered output must finish
865 by printing a newline, to flush the wrap buffer, before switching to
866 unfiltered (``@code{printf}'') output. Symbol reading routines that print
867 warnings are a good example.
870 @node Frames, Coding Style, Wrapping, Top
873 A frame is a construct that GDB uses to keep track of calling and called
878 in the machine description has no meaning to the machine-independent
879 part of GDB, except that it is used when setting up a new frame from
883 create_new_frame (read_register (FP_REGNUM), read_pc ()));
886 Other than that, all the meaning imparted to @code{FP_REGNUM} is imparted by
887 the machine-dependent code. So, @code{FP_REGNUM} can have any value that
888 is convenient for the code that creates new frames. (@code{create_new_frame}
889 calls @code{INIT_EXTRA_FRAME_INFO} if it is defined; that is where you should
890 use the @code{FP_REGNUM} value, if your frames are nonstandard.)
893 Given a GDB frame, determine the address of the calling function's
894 frame. This will be used to create a new GDB frame struct, and then
895 @code{INIT_EXTRA_FRAME_INFO} and @code{INIT_FRAME_PC} will be called for
899 @node Coding Style, Host Conditionals, Frames, Top
900 @chapter Coding Style
902 GDB is generally written using the GNU coding standards, as described in
903 @file{standards.texi}, which you can get from the Free Software
904 Foundation. There are some additional considerations for GDB maintainers
905 that reflect the unique environment and style of GDB maintenance.
906 If you follow these guidelines, GDB will be more consistent and easier
909 GDB's policy on the use of prototypes is that prototypes are used
910 to @emph{declare} functions but never to @emph{define} them. Simple
911 macros are used in the declarations, so that a non-ANSI compiler can
912 compile GDB without trouble. The simple macro calls are used like
917 memory_remove_breakpoint PARAMS ((CORE_ADDR, char *));
920 Note the double parentheses around the parameter types. This allows
921 an arbitrary number of parameters to be described, without freaking
922 out the C preprocessor. When the function has no parameters, it
923 should be described like:
927 noprocess PARAMS ((void));
930 The @code{PARAMS} macro expands to its argument in ANSI C, or to a simple
931 @code{()} in traditional C.
933 All external functions should have a @code{PARAMS} declaration in a
934 header file that callers include. All static functions should have such
935 a declaration near the top of their source file.
937 We don't have a gcc option that will properly check that these rules
938 have been followed, but it's GDB policy, and we periodically check it
939 using the tools available (plus manual labor), and clean up any remnants.
941 @node Host Conditionals, Target Conditionals, Coding Style, Top
942 @chapter Host Conditionals
944 When GDB is configured and compiled, various macros are defined or left
945 undefined, to control compilation based on the attributes of the host
946 system. These macros and their meanings are:
948 @emph{NOTE: For now, both host and target conditionals are here.
949 Eliminate target conditionals from this list as they are identified.}
954 @item BLOCK_ADDRESS_FUNCTION_RELATIVE
956 @item GDBINIT_FILENAME
960 @item MEM_FNS_DECLARED
964 @item PYRAMID_CONTROL_FRAME_DEBUGGING
966 @item SIGWINCH_HANDLER_BODY
984 @item ADDITIONAL_OPTIONS
986 @item ADDITIONAL_OPTION_CASES
988 @item ADDITIONAL_OPTION_HANDLER
990 @item ADDITIONAL_OPTION_HELP
992 @item ADDR_BITS_REMOVE
994 @item AIX_BUGGY_PTRACE_CONTINUE
996 @item ALIGN_STACK_ON_STARTUP
1008 @item BEFORE_MAIN_LOOP_HOOK
1010 @item BELIEVE_PCC_PROMOTION
1012 @item BELIEVE_PCC_PROMOTION_TYPE
1016 @item BITS_BIG_ENDIAN
1020 @item BLOCK_ADDRESS_ABSOLUTE
1026 @item BREAKPOINT_DEBUG
1028 @item BROKEN_LARGE_ALLOCA
1029 Avoid large @code{alloca}'s. For example, on sun's, Large alloca's fail
1030 because the attempt to increase the stack limit in main() fails because
1031 shared libraries are allocated just below the initial stack limit. The
1032 SunOS kernel will not allow the stack to grow into the area occupied by
1033 the shared libraries.
1038 @item CALL_DUMMY_LOCATION
1040 @item CALL_DUMMY_STACK_ADJUST
1042 @item CANNOT_FETCH_REGISTER
1044 @item CANNOT_STORE_REGISTER
1046 @item CFRONT_PRODUCER
1048 @item CHILD_PREPARE_TO_STORE
1050 @item CLEAR_DEFERRED_STORES
1054 @item COFF_ENCAPSULATE
1058 @item COFF_NO_LONG_FILE_NAMES
1060 @item CORE_NEEDS_RELOCATION
1064 @item CREATE_INFERIOR_HOOK
1074 @item DBX_PARM_SYMBOL_CLASS
1082 @item DECR_PC_AFTER_BREAK
1084 @item DEFAULT_PROMPT
1092 @item DISABLE_UNSETTABLE_BREAK
1094 @item DONT_USE_REMOTE
1096 @item DO_DEFERRED_STORES
1098 @item DO_REGISTERS_INFO
1100 @item END_OF_TEXT_DEFAULT
1104 @item EXTRACT_RETURN_VALUE
1106 @item EXTRACT_STRUCT_VALUE_ADDRESS
1108 @item EXTRA_FRAME_INFO
1110 @item EXTRA_SYMTAB_INFO
1112 @item FILES_INFO_HOOK
1126 @item FRAMELESS_FUNCTION_INVOCATION
1128 @item FRAME_ARGS_ADDRESS_CORRECT
1130 @item FRAME_CHAIN_COMBINE
1132 @item FRAME_CHAIN_VALID
1134 @item FRAME_CHAIN_VALID_ALTERNATE
1136 @item FRAME_FIND_SAVED_REGS
1138 @item FRAME_GET_BASEREG_VALUE
1140 @item FRAME_NUM_ARGS
1142 @item FRAME_SPECIFICATION_DYADIC
1144 @item FUNCTION_EPILOGUE_SIZE
1148 @item GCC2_COMPILED_FLAG_SYMBOL
1150 @item GCC_COMPILED_FLAG_SYMBOL
1152 @item GCC_MANGLE_BUG
1156 @item GET_LONGJMP_TARGET
1158 @item GET_SAVED_REGISTER
1160 @item GPLUS_PRODUCER
1171 In some cases, use the system call @code{mmap} for reading symbol
1172 tables. For some machines this allows for sharing and quick updates.
1173 @item HAVE_REGISTER_WINDOWS
1175 @item HAVE_SIGSETMASK
1179 @item HEADER_SEEK_FD
1183 @item HOST_BYTE_ORDER
1187 @item HPUX_VERSION_5
1195 @item IBM6000_TARGET
1203 @item INIT_EXTRA_FRAME_INFO
1205 @item INIT_EXTRA_SYMTAB_INFO
1219 @item IN_SOLIB_TRAMPOLINE
1223 @item IS_TRAPPED_INTERNALVAR
1227 @item KERNEL_DEBUGGING
1230 Define this to the address of the @code{u} structure (the ``user struct'',
1231 also known as the ``u-page'') in kernel virtual memory. GDB needs to know
1232 this so that it can subtract this address from absolute addresses in
1233 the upage, that are obtained via ptrace or from core files. On systems
1234 that don't need this value, set it to zero.
1235 @item KERNEL_U_ADDR_BSD
1236 Define this to cause GDB to determine the address of @code{u} at runtime,
1237 by using Berkeley-style @code{nlist} on the kernel's image in the root
1239 @item KERNEL_U_ADDR_HPUX
1240 Define this to cause GDB to determine the address of @code{u} at runtime,
1241 by using HP-style @code{nlist} on the kernel's image in the root
1257 @item LSEEK_NOT_LINEAR
1263 @item MACHKERNELDEBUG
1269 @item MAINTENANCE_CMDS
1271 @item MAINTENANCE_CMDS
1273 @item MALLOC_INCOMPATIBLE
1274 Define this if the system's prototype for @code{malloc} differs from the
1275 @sc{ANSI} definition.
1278 @item MMAP_BASE_ADDRESS
1279 When using HAVE_MMAP, the first mapping should go at this address.
1280 @item MMAP_INCREMENT
1281 when using HAVE_MMAP, this is the increment between mappings.
1286 @item NAMES_HAVE_UNDERSCORE
1290 @item NEED_POSIX_SETPGID
1292 @item NEED_TEXT_START_END
1306 @item NOTICE_SIGNAL_HANDLING_CHANGE
1308 @item NO_DEFINE_SYMBOL
1310 @item NO_HIF_SUPPORT
1312 @item NO_JOB_CONTROL
1314 @item NO_MALLOC_CHECK
1322 @item NO_SIGINTERRUPT
1324 @item NO_SINGLE_STEP
1332 @item NS32K_SVC_IMMED_OPERANDS
1334 @item NUMERIC_REG_NAMES
1342 @item ONE_PROCESS_WRITETEXT
1350 @item PCC_SOL_BROKEN
1352 @item PC_IN_CALL_DUMMY
1354 @item PC_LOAD_SEGMENT
1358 @item PRINT_RANDOM_SIGNAL
1360 @item PRINT_REGISTER_HOOK
1362 @item PRINT_TYPELESS_INTEGER
1364 @item PROCESS_LINENUMBER_HOOK
1366 @item PROLOGUE_FIRSTLINE_OVERLAP
1368 @item PSIGNAL_IN_SIGNAL_H
1372 @item PTRACE_ARG3_TYPE
1382 @item PUSH_ARGUMENTS
1384 @item PYRAMID_CONTROL_FRAME_DEBUGGING
1388 @item PYRAMID_PTRACE
1390 @item REGISTER_BYTES
1392 @item REGISTER_NAMES
1394 @item REG_STACK_SEGMENT
1396 @item REG_STRUCT_HAS_ADDR
1404 @item SDB_REG_TO_REGNUM
1412 @item SET_STACK_LIMIT_HUGE
1413 When defined, stack limits will be raised to their maximum. Use this
1414 if your host supports @code{setrlimit} and you have trouble with
1415 @code{stringtab} in @file{dbxread.c}.
1417 Also used in @file{fork-child.c} to return stack limits before child
1418 processes are forked.
1419 @item SHELL_COMMAND_CONCAT
1423 @item SHIFT_INST_REGS
1425 @item SIGN_EXTEND_CHAR
1427 @item SIGTRAP_STOP_AFTER_LOAD
1431 @item SKIP_PROLOGUE_FRAMELESS_P
1433 @item SKIP_TRAMPOLINE_CODE
1437 @item SOLIB_CREATE_INFERIOR_HOOK
1439 @item SOME_NAMES_HAVE_DOT
1443 @item STAB_REG_TO_REGNUM
1447 @item STACK_DIRECTION
1449 @item START_INFERIOR_TRAPS_EXPECTED
1453 @item STORE_RETURN_VALUE
1455 @item SUN4_COMPILER_FEATURE
1457 @item SUN_FIXED_LBRAC_BUG
1459 @item SVR4_SHARED_LIBS
1461 @item SWITCH_ENUM_BUG
1465 @item SYMBOL_RELOADING_DEFAULT
1485 @item TM_FILE_OVERRIDE
1501 @item USE_STRUCT_CONVENTION
1504 Means that System V (prior to SVR4) include files are in use.
1505 (FIXME: This symbol is abused in @file{infrun.c}, @file{regex.c},
1506 @file{remote-nindy.c}, and @file{utils.c} for other things, at the moment.)
1511 @item VARIABLES_INSIDE_BLOCK
1523 @item __HAVE_68881__
1527 @item __INT_VARARGS_H
1529 @item __not_on_pyr_yet
1545 @item longest_to_int
1575 @node Target Conditionals, Native Conditionals, Host Conditionals, Top
1576 @chapter Target Conditionals
1578 When GDB is configured and compiled, various macros are defined or left
1579 undefined, to control compilation based on the attributes of the target
1580 system. These macros and their meanings are:
1582 @emph{NOTE: For now, both host and target conditionals are here.
1583 Eliminate host conditionals from this list as they are identified.}
1588 @item BLOCK_ADDRESS_FUNCTION_RELATIVE
1590 @item GDBINIT_FILENAME
1594 @item MEM_FNS_DECLARED
1598 @item PYRAMID_CONTROL_FRAME_DEBUGGING
1600 @item SIGWINCH_HANDLER_BODY
1602 @item ADDITIONAL_OPTIONS
1604 @item ADDITIONAL_OPTION_CASES
1606 @item ADDITIONAL_OPTION_HANDLER
1608 @item ADDITIONAL_OPTION_HELP
1610 @item ADDR_BITS_REMOVE
1612 @item ALIGN_STACK_ON_STARTUP
1624 @item BEFORE_MAIN_LOOP_HOOK
1626 @item BELIEVE_PCC_PROMOTION
1628 @item BELIEVE_PCC_PROMOTION_TYPE
1632 @item BITS_BIG_ENDIAN
1636 @item BLOCK_ADDRESS_ABSOLUTE
1642 @item BREAKPOINT_DEBUG
1648 @item CALL_DUMMY_LOCATION
1650 @item CALL_DUMMY_STACK_ADJUST
1652 @item CANNOT_FETCH_REGISTER
1654 @item CANNOT_STORE_REGISTER
1656 @item CFRONT_PRODUCER
1658 @item CHILD_PREPARE_TO_STORE
1660 @item CLEAR_DEFERRED_STORES
1664 @item COFF_ENCAPSULATE
1668 @item COFF_NO_LONG_FILE_NAMES
1670 @item CORE_NEEDS_RELOCATION
1674 @item CREATE_INFERIOR_HOOK
1684 @item DBX_PARM_SYMBOL_CLASS
1692 @item DECR_PC_AFTER_BREAK
1694 @item DEFAULT_PROMPT
1702 @item DISABLE_UNSETTABLE_BREAK
1704 @item DONT_USE_REMOTE
1706 @item DO_DEFERRED_STORES
1708 @item DO_REGISTERS_INFO
1710 @item END_OF_TEXT_DEFAULT
1714 @item EXTRACT_RETURN_VALUE
1716 @item EXTRACT_STRUCT_VALUE_ADDRESS
1718 @item EXTRA_FRAME_INFO
1720 @item EXTRA_SYMTAB_INFO
1722 @item FILES_INFO_HOOK
1737 Unused? 6-oct-92 rich@cygnus.com. FIXME.
1738 @item FRAMELESS_FUNCTION_INVOCATION
1740 @item FRAME_ARGS_ADDRESS_CORRECT
1742 @item FRAME_CHAIN_COMBINE
1744 @item FRAME_CHAIN_VALID
1746 @item FRAME_CHAIN_VALID_ALTERNATE
1748 @item FRAME_FIND_SAVED_REGS
1750 @item FRAME_GET_BASEREG_VALUE
1752 @item FRAME_NUM_ARGS
1754 @item FRAME_SPECIFICATION_DYADIC
1756 @item FUNCTION_EPILOGUE_SIZE
1760 @item GCC2_COMPILED_FLAG_SYMBOL
1762 @item GCC_COMPILED_FLAG_SYMBOL
1764 @item GCC_MANGLE_BUG
1768 @item GDB_TARGET_IS_HPPA
1769 This determines whether horrible kludge code in dbxread.c and partial-stab.h
1770 is used to mangle multiple-symbol-table files from HPPA's. This should all
1771 be ripped out, and a scheme like elfread.c used.
1772 @item GDB_TARGET_IS_MACH386
1774 @item GDB_TARGET_IS_SUN3
1776 @item GDB_TARGET_IS_SUN386
1778 @item GET_LONGJMP_TARGET
1780 @item GET_SAVED_REGISTER
1782 @item GPLUS_PRODUCER
1792 @item HAVE_REGISTER_WINDOWS
1794 @item HAVE_SIGSETMASK
1798 @item HEADER_SEEK_FD
1802 @item HOST_BYTE_ORDER
1806 @item HPUX_VERSION_5
1814 @item IBM6000_TARGET
1822 @item INIT_EXTRA_FRAME_INFO
1824 @item INIT_EXTRA_SYMTAB_INFO
1838 @item IN_SOLIB_TRAMPOLINE
1842 @item IS_TRAPPED_INTERNALVAR
1846 @item KERNEL_DEBUGGING
1862 @item LSEEK_NOT_LINEAR
1868 @item MACHKERNELDEBUG
1874 @item MAINTENANCE_CMDS
1876 @item MAINTENANCE_CMDS
1882 @item NAMES_HAVE_UNDERSCORE
1886 @item NEED_POSIX_SETPGID
1888 @item NEED_TEXT_START_END
1902 @item NOTICE_SIGNAL_HANDLING_CHANGE
1904 @item NO_DEFINE_SYMBOL
1906 @item NO_HIF_SUPPORT
1908 @item NO_JOB_CONTROL
1910 @item NO_MALLOC_CHECK
1918 @item NO_SIGINTERRUPT
1920 @item NO_SINGLE_STEP
1928 @item NS32K_SVC_IMMED_OPERANDS
1930 @item NUMERIC_REG_NAMES
1938 @item ONE_PROCESS_WRITETEXT
1942 @item PCC_SOL_BROKEN
1944 @item PC_IN_CALL_DUMMY
1946 @item PC_LOAD_SEGMENT
1950 @item PRINT_RANDOM_SIGNAL
1952 @item PRINT_REGISTER_HOOK
1954 @item PRINT_TYPELESS_INTEGER
1956 @item PROCESS_LINENUMBER_HOOK
1958 @item PROLOGUE_FIRSTLINE_OVERLAP
1960 @item PSIGNAL_IN_SIGNAL_H
1964 @item PTRACE_ARG3_TYPE
1968 @item PUSH_ARGUMENTS
1970 @item REGISTER_BYTES
1972 @item REGISTER_NAMES
1974 @item REG_STACK_SEGMENT
1976 @item REG_STRUCT_HAS_ADDR
1984 @item SDB_REG_TO_REGNUM
1992 @item SET_STACK_LIMIT_HUGE
1994 @item SHELL_COMMAND_CONCAT
1998 @item SHIFT_INST_REGS
2000 @item SIGN_EXTEND_CHAR
2002 @item SIGTRAP_STOP_AFTER_LOAD
2006 @item SKIP_PROLOGUE_FRAMELESS_P
2008 @item SKIP_TRAMPOLINE_CODE
2012 @item SOLIB_CREATE_INFERIOR_HOOK
2014 @item SOME_NAMES_HAVE_DOT
2018 @item STAB_REG_TO_REGNUM
2022 @item STACK_DIRECTION
2024 @item START_INFERIOR_TRAPS_EXPECTED
2028 @item STORE_RETURN_VALUE
2030 @item SUN4_COMPILER_FEATURE
2032 @item SUN_FIXED_LBRAC_BUG
2034 @item SVR4_SHARED_LIBS
2036 @item SWITCH_ENUM_BUG
2040 @item SYMBOL_RELOADING_DEFAULT
2046 @item TARGET_BYTE_ORDER
2048 @item TARGET_CHAR_BIT
2050 @item TARGET_COMPLEX_BIT
2052 @item TARGET_DOUBLE_BIT
2054 @item TARGET_DOUBLE_COMPLEX_BIT
2056 @item TARGET_FLOAT_BIT
2058 @item TARGET_INT_BIT
2060 @item TARGET_LONG_BIT
2062 @item TARGET_LONG_DOUBLE_BIT
2064 @item TARGET_LONG_LONG_BIT
2066 @item TARGET_PTR_BIT
2068 @item TARGET_SHORT_BIT
2072 @item TM_FILE_OVERRIDE
2084 @item USE_STRUCT_CONVENTION
2090 @item VARIABLES_INSIDE_BLOCK
2100 @item __HAVE_68881__
2104 @item __INT_VARARGS_H
2106 @item __not_on_pyr_yet
2116 @item longest_to_int
2140 @node Native Conditionals, , Target Conditionals, Top
2141 @chapter Native Conditionals
2146 If defined, then gdb will include support for the @code{attach} and
2147 @code{detach} commands.
2149 @item FETCH_INFERIOR_REGISTERS
2150 Define this if the native-dependent code will provide its
2152 @code{fetch_inferior_registers} and @code{store_inferior_registers} in
2153 @file{@var{HOST}-nat.c}.
2154 If this symbol is @emph{not} defined, the default routines in
2155 @file{infptrace.c} are used for these functions.
2157 Defines the format for the name of a @file{/proc} device. Should be
2158 defined in @file{nm.h} @emph{only} in order to override the default
2159 definition in @file{procfs.c}.
2160 @item REGISTER_U_ADDR
2161 Defines the offset of the registers in the ``u area''; @pxref{Host}.
2163 This determines whether small routines that translate register values
2164 to GDB's internal representation (from the /proc representation), and vice
2165 verse, are compiled.
2167 This is the offset of the registers in the upage. It need only be
2168 defined if the generic ptrace register access routines in
2169 @file{infptrace.c} are being used (that is,
2170 @code{FETCH_INFERIOR_REGISTERS} is not defined). If the default value
2171 from @file{infptrace.c} is good enough, leave it undefined.
2173 The default value means that u.u_ar0 @emph{points to} the location of the
2174 registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means that
2175 u.u_ar0 @emph{is} the location of the registers.