Commit | Line | Data |
---|---|---|
ca714d03 | 1 | \input texinfo |
7f09f15f | 2 | @setfilename gdbint.info |
d98259f8 | 3 | @c $Id$ |
b7becc8f RP |
4 | |
5 | @ifinfo | |
6 | @format | |
7 | START-INFO-DIR-ENTRY | |
b517f124 | 8 | * Gdb-Internals: (gdbint). The GNU debugger's internals. |
b7becc8f RP |
9 | END-INFO-DIR-ENTRY |
10 | @end format | |
11 | @end ifinfo | |
12 | ||
ca714d03 RP |
13 | @ifinfo |
14 | This file documents the internals of the GNU debugger GDB. | |
f222d23d | 15 | |
224226b8 | 16 | Copyright 1990, 1991, 1992, 1993 Free Software Foundation, Inc. |
ca714d03 | 17 | Contributed by Cygnus Support. Written by John Gilmore. |
cfddbd02 | 18 | |
ca714d03 RP |
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. | |
22 | ||
23 | @ignore | |
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). | |
28 | ||
29 | @end ignore | |
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). | |
33 | @end ifinfo | |
34 | ||
7f09f15f | 35 | @setchapternewpage off |
ca714d03 RP |
36 | @settitle GDB Internals |
37 | @titlepage | |
38 | @title{Working in GDB} | |
39 | @subtitle{A guide to the internals of the GNU debugger} | |
40 | @author John Gilmore | |
41 | @author Cygnus Support | |
42 | @page | |
43 | @tex | |
44 | \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$ | |
45 | \xdef\manvers{\$Revision$} % For use in headers, footers too | |
46 | {\parskip=0pt | |
47 | \hfill Cygnus Support\par | |
48 | \hfill \manvers\par | |
49 | \hfill \TeX{}info \texinfoversion\par | |
50 | } | |
51 | @end tex | |
52 | ||
53 | @vskip 0pt plus 1filll | |
224226b8 | 54 | Copyright @copyright{} 1990, 1991, 1992, 1993 Free Software Foundation, Inc. |
ca714d03 RP |
55 | |
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. | |
59 | ||
60 | @end titlepage | |
61 | ||
b517f124 | 62 | @node Top |
c1cd5aec JK |
63 | @c Perhaps this should be the title of the document (but only for info, |
64 | @c not for TeX). Existing GNU manuals seem inconsistent on this point. | |
65 | @top Scope of this Document | |
66 | ||
67 | This document documents the internals of the GNU debugger, GDB. It is | |
68 | intended to document aspects of GDB which apply across many different | |
69 | parts of GDB (for example, @pxref{Coding Style}), or which are global | |
70 | aspects of design (for example, what are the major modules and which | |
71 | files document them in detail?). Information which pertains to specific | |
72 | data structures, functions, variables, etc., should be put in comments | |
73 | in the source code, not here. It is more likely to get noticed and kept | |
74 | up to date there. Some of the information in this document should | |
75 | probably be moved into comments. | |
493cf018 | 76 | |
ca714d03 | 77 | @menu |
97f3cb72 | 78 | * README:: The README File |
a5e7f259 JK |
79 | * Getting Started:: Getting started working on GDB |
80 | * Debugging GDB:: Debugging GDB with itself | |
97f3cb72 RP |
81 | * New Architectures:: Defining a New Host or Target Architecture |
82 | * Config:: Adding a New Configuration | |
7f09f15f | 83 | * Host:: Adding a New Host |
fd3d2e1d | 84 | * Native:: Adding a New Native Configuration |
7f09f15f | 85 | * Target:: Adding a New Target |
97f3cb72 RP |
86 | * Languages:: Defining New Source Languages |
87 | * Releases:: Configuring GDB for Release | |
493cf018 | 88 | * Partial Symbol Tables:: How GDB reads symbols quickly at startup |
3a8bc841 | 89 | * Types:: How GDB keeps track of types |
d98259f8 | 90 | * BFD support for GDB:: How BFD and GDB interface |
97f3cb72 RP |
91 | * Symbol Reading:: Defining New Symbol Readers |
92 | * Cleanups:: Cleanups | |
93 | * Wrapping:: Wrapping Output Lines | |
968720bf | 94 | * Frames:: Keeping track of function calls |
00db1549 | 95 | * Remote Stubs:: Code that runs in targets and talks to GDB |
d3d6d0ff | 96 | * Longjmp Support:: Stepping through longjmp's in the target |
968720bf | 97 | * Coding Style:: Strunk and White for GDB maintainers |
2a20c602 JG |
98 | * Clean Design:: Frank Lloyd Wright for GDB maintainers |
99 | * Submitting Patches:: How to get your changes into GDB releases | |
b517f124 JG |
100 | * Host Conditionals:: What features exist in the host |
101 | * Target Conditionals:: What features exist in the target | |
102 | * Native Conditionals:: Conditionals for when host and target are same | |
103 | * Obsolete Conditionals:: Conditionals that don't exist any more | |
9729ef22 | 104 | * XCOFF:: The Object file format used on IBM's RS/6000 |
ca714d03 RP |
105 | @end menu |
106 | ||
b517f124 | 107 | @node README |
97f3cb72 | 108 | @chapter The @file{README} File |
cfddbd02 | 109 | |
97f3cb72 RP |
110 | Check the @file{README} file, it often has useful information that does not |
111 | appear anywhere else in the directory. | |
cfddbd02 | 112 | |
a5e7f259 JK |
113 | @node Getting Started |
114 | @chapter Getting Started Working on GDB | |
115 | ||
116 | GDB is a large and complicated program, and if you first starting to | |
117 | work on it, it can be hard to know where to start. Fortunately, if you | |
118 | know how to go about it, there are ways to figure out what is going on: | |
119 | ||
c1cd5aec | 120 | @itemize @bullet |
a5e7f259 JK |
121 | @item |
122 | This manual, the GDB Internals manual, has information which applies | |
123 | generally to many parts of GDB. | |
124 | ||
125 | @item | |
126 | Information about particular functions or data structures are located in | |
127 | comments with those functions or data structures. If you run across a | |
128 | function or a global variable which does not have a comment correctly | |
129 | explaining what is does, this can be thought of as a bug in GDB; feel | |
130 | free to submit a bug report, with a suggested comment if you can figure | |
131 | out what the comment should say (@pxref{Submitting Patches}). If you | |
132 | find a comment which is actually wrong, be especially sure to report that. | |
133 | ||
134 | Comments explaining the function of macros defined in host, target, or | |
135 | native dependent files can be in several places. Sometimes they are | |
136 | repeated every place the macro is defined. Sometimes they are where the | |
137 | macro is used. Sometimes there is a header file which supplies a | |
138 | default definition of the macro, and the comment is there. This manual | |
139 | also has a list of macros (@pxref{Host Conditionals}, @pxref{Target | |
140 | Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete | |
141 | Conditionals}) with some documentation. | |
142 | ||
143 | @item | |
144 | Start with the header files. Once you some idea of how GDB's internal | |
145 | symbol tables are stored (see @file{symtab.h}, @file{gdbtypes.h}), you | |
146 | will find it much easier to understand the code which uses and creates | |
147 | those symbol tables. | |
148 | ||
149 | @item | |
150 | You may wish to process the information you are getting somehow, to | |
151 | enhance your understanding of it. Summarize it, translate it to another | |
152 | language, add some (perhaps trivial or non-useful) feature to GDB, use | |
153 | the code to predict what a test case would do and write the test case | |
154 | and verify your prediction, etc. If you are reading code and your eyes | |
155 | are starting to glaze over, this is a sign you need to use a more active | |
156 | approach. | |
157 | ||
158 | @item | |
159 | Once you have a part of GDB to start with, you can find more | |
160 | specifically the part you are looking for by stepping through each | |
161 | function with the @code{next} command. Do not use @code{step} or you | |
162 | will quickly get distracted; when the function you are stepping through | |
163 | calls another function try only to get a big-picture understanding | |
164 | (perhaps using the comment at the beginning of the function being | |
165 | called) of what it does. This way you can identify which of the | |
166 | functions being called by the function you are stepping through is the | |
167 | one which you are interested in. You may need to examine the data | |
168 | structures generated at each stage, with reference to the comments in | |
169 | the header files explaining what the data structures are supposed to | |
170 | look like. | |
171 | ||
172 | Of course, this same technique can be used if you are just reading the | |
173 | code, rather than actually stepping through it. The same general | |
174 | principle applies---when the code you are looking at calls something | |
175 | else, just try to understand generally what the code being called does, | |
176 | rather than worrying about all its details. | |
177 | ||
178 | @item | |
179 | A good place to start when tracking down some particular area is with a | |
180 | command which invokes that feature. Suppose you want to know how | |
181 | single-stepping works. As a GDB user, you know that the @code{step} | |
182 | command invokes single-stepping. The command is invoked via command | |
183 | tables (see @file{command.h}); by convention the function which actually | |
184 | performs the command is formed by taking the name of the command and | |
185 | adding @samp{_command}, or in the case of an @code{info} subcommand, | |
186 | @samp{_info}. For example, the @code{step} command invokes the | |
187 | @code{step_command} function and the @code{info display} command invokes | |
188 | @code{display_info}. When this convention is not followed, you might | |
189 | have to use @code{grep} or @kbd{M-x tags-search} in emacs, or run GDB on | |
190 | itself and set a breakpoint in @code{execute_command}. | |
191 | ||
192 | @item | |
193 | If all of the above fail, it may be appropriate to ask for information | |
194 | on @code{bug-gdb}. But @emph{never} post a generic question like ``I was | |
195 | wondering if anyone could give me some tips about understanding | |
196 | GDB''---if we had some magic secret we would put it in this manual. | |
197 | Suggestions for improving the manual are always welcome, of course. | |
c1cd5aec | 198 | @end itemize |
a5e7f259 JK |
199 | |
200 | Good luck! | |
201 | ||
202 | @node Debugging GDB | |
203 | @chapter Debugging GDB with itself | |
204 | If gdb is limping on your machine, this is the preferred way to get it | |
205 | fully functional. Be warned that in some ancient Unix systems, like | |
c1cd5aec | 206 | Ultrix 4.2, a program can't be running in one process while it is being |
a5e7f259 JK |
207 | debugged in another. Rather than typing the command @code{@w{./gdb |
208 | ./gdb}}, which works on Suns and such, you can copy @file{gdb} to | |
209 | @file{gdb2} and then type @code{@w{./gdb ./gdb2}}. | |
210 | ||
211 | When you run gdb in the gdb source directory, it will read a | |
212 | @file{.gdbinit} file that sets up some simple things to make debugging | |
213 | gdb easier. The @code{info} command, when executed without a subcommand | |
214 | in a gdb being debugged by gdb, will pop you back up to the top level | |
215 | gdb. See @file{.gdbinit} for details. | |
216 | ||
217 | If you use emacs, you will probably want to do a @code{make TAGS} after | |
218 | you configure your distribution; this will put the machine dependent | |
219 | routines for your local machine where they will be accessed first by | |
220 | @kbd{M-.} | |
221 | ||
222 | Also, make sure that you've either compiled gdb with your local cc, or | |
223 | have run @code{fixincludes} if you are compiling with gcc. | |
cfddbd02 | 224 | |
b517f124 | 225 | @node New Architectures |
97f3cb72 | 226 | @chapter Defining a New Host or Target Architecture |
cfddbd02 | 227 | |
97f3cb72 RP |
228 | When building support for a new host and/or target, much of the work you |
229 | need to do is handled by specifying configuration files; | |
230 | @pxref{Config,,Adding a New Configuration}. Further work can be | |
231 | divided into ``host-dependent'' (@pxref{Host,,Adding a New Host}) and | |
aeb62c7b | 232 | ``target-dependent'' (@pxref{Target,,Adding a New Target}). The |
97f3cb72 RP |
233 | following discussion is meant to explain the difference between hosts |
234 | and targets. | |
d98259f8 | 235 | |
97f3cb72 | 236 | @heading What is considered ``host-dependent'' versus ``target-dependent''? |
d98259f8 | 237 | |
b7becc8f RP |
238 | @dfn{Host} refers to attributes of the system where GDB runs. |
239 | @dfn{Target} refers to the system where the program being debugged | |
fd3d2e1d JG |
240 | executes. In most cases they are the same machine, in which case |
241 | a third type of @dfn{Native} attributes come into play. | |
cfddbd02 | 242 | |
97f3cb72 RP |
243 | Defines and include files needed to build on the host are host support. |
244 | Examples are tty support, system defined types, host byte order, host | |
245 | float format. | |
cfddbd02 | 246 | |
fd3d2e1d JG |
247 | Defines and information needed to handle the target format are target |
248 | dependent. Examples are the stack frame format, instruction set, | |
249 | breakpoint instruction, registers, and how to set up and tear down the stack | |
250 | to call a function. | |
251 | ||
252 | Information that is only needed when the host and target are the same, | |
253 | is native dependent. One example is Unix child process support; if the | |
254 | host and target are not the same, doing a fork to start the target | |
255 | process is a bad idea. The various macros needed for finding the | |
256 | registers in the @code{upage}, running @code{ptrace}, and such are all in the | |
257 | native-dependent files. | |
258 | ||
259 | Another example of native-dependent code is support for features | |
260 | that are really part of the target environment, but which require | |
261 | @code{#include} files that are only available on the host system. | |
262 | Core file handling and @code{setjmp} handling are two common cases. | |
263 | ||
264 | When you want to make GDB work ``native'' on a particular | |
265 | machine, you have to include all three kinds of information. | |
266 | ||
267 | The dependent information in GDB is organized into files by naming | |
268 | conventions. | |
7f27984e | 269 | |
fd3d2e1d JG |
270 | Host-Dependent Files |
271 | @table @file | |
3a8bc841 | 272 | @item config/*/*.mh |
fd3d2e1d | 273 | Sets Makefile parameters |
3a8bc841 | 274 | @item config/*/xm-*.h |
fd3d2e1d JG |
275 | Global #include's and #define's and definitions |
276 | @item *-xdep.c | |
277 | Global variables and functions | |
278 | @end table | |
279 | ||
280 | Native-Dependent Files | |
281 | @table @file | |
3a8bc841 | 282 | @item config/*/*.mh |
fd3d2e1d | 283 | Sets Makefile parameters (for @emph{both} host and native) |
3a8bc841 | 284 | @item config/*/nm-*.h |
fd3d2e1d JG |
285 | #include's and #define's and definitions. This file |
286 | is only included by the small number of modules that need it, | |
287 | so beware of doing feature-test #define's from its macros. | |
288 | @item *-nat.c | |
289 | global variables and functions | |
290 | @end table | |
7f27984e | 291 | |
fd3d2e1d JG |
292 | Target-Dependent Files |
293 | @table @file | |
3a8bc841 | 294 | @item config/*/*.mt |
fd3d2e1d | 295 | Sets Makefile parameters |
3a8bc841 | 296 | @item config/*/tm-*.h |
fd3d2e1d JG |
297 | Global #include's and #define's and definitions |
298 | @item *-tdep.c | |
299 | Global variables and functions | |
300 | @end table | |
bbb5013f | 301 | |
fd3d2e1d JG |
302 | At this writing, most supported hosts have had their host and native |
303 | dependencies sorted out properly. There are a few stragglers, which | |
304 | can be recognized by the absence of NATDEPFILES lines in their | |
3a8bc841 | 305 | @file{config/*/*.mh}. |
bbb5013f | 306 | |
b517f124 | 307 | @node Config |
97f3cb72 | 308 | @chapter Adding a New Configuration |
bbb5013f | 309 | |
97f3cb72 RP |
310 | Most of the work in making GDB compile on a new machine is in specifying |
311 | the configuration of the machine. This is done in a dizzying variety of | |
312 | header files and configuration scripts, which we hope to make more | |
313 | sensible soon. Let's say your new host is called an @var{xxx} (e.g. | |
314 | @samp{sun4}), and its full three-part configuration name is | |
315 | @code{@var{xarch}-@var{xvend}-@var{xos}} (e.g. @samp{sparc-sun-sunos4}). In | |
316 | particular: | |
317 | ||
b7becc8f | 318 | In the top level directory, edit @file{config.sub} and add @var{xarch}, |
97f3cb72 RP |
319 | @var{xvend}, and @var{xos} to the lists of supported architectures, |
320 | vendors, and operating systems near the bottom of the file. Also, add | |
321 | @var{xxx} as an alias that maps to | |
322 | @code{@var{xarch}-@var{xvend}-@var{xos}}. You can test your changes by | |
323 | running | |
bbb5013f | 324 | |
97f3cb72 RP |
325 | @example |
326 | ./config.sub @var{xxx} | |
327 | @end example | |
328 | @noindent | |
329 | and | |
330 | @example | |
331 | ./config.sub @code{@var{xarch}-@var{xvend}-@var{xos}} | |
332 | @end example | |
333 | @noindent | |
334 | which should both respond with @code{@var{xarch}-@var{xvend}-@var{xos}} | |
335 | and no error messages. | |
bbb5013f | 336 | |
b7becc8f RP |
337 | Now, go to the @file{bfd} directory and |
338 | create a new file @file{bfd/hosts/h-@var{xxx}.h}. Examine the | |
97f3cb72 RP |
339 | other @file{h-*.h} files as templates, and create one that brings in the |
340 | right include files for your system, and defines any host-specific | |
fd3d2e1d JG |
341 | macros needed by BFD, the Binutils, GNU LD, or the Opcodes directories. |
342 | (They all share the bfd @file{hosts} directory and the @file{configure.host} | |
343 | file.) | |
7f27984e | 344 | |
fd3d2e1d | 345 | Then edit @file{bfd/configure.host}. Add a line to recognize your |
97f3cb72 | 346 | @code{@var{xarch}-@var{xvend}-@var{xos}} configuration, and set |
b7becc8f RP |
347 | @code{my_host} to @var{xxx} when you recognize it. This will cause your |
348 | file @file{h-@var{xxx}.h} to be linked to @file{sysdep.h} at configuration | |
fd3d2e1d JG |
349 | time. When creating the line that recognizes your configuration, |
350 | only match the fields that you really need to match; e.g. don't match | |
351 | match the architecture or manufacturer if the OS is sufficient | |
352 | to distinguish the configuration that your @file{h-@var{xxx}.h} file supports. | |
353 | Don't match the manufacturer name unless you really need to. | |
354 | This should make future ports easier. | |
7f27984e | 355 | |
b7becc8f | 356 | Also, if this host requires any changes to the Makefile, create a file |
fd3d2e1d | 357 | @file{bfd/config/@var{xxx}.mh}, which includes the required lines. |
97f3cb72 | 358 | |
8cc1c08f | 359 | It's possible that the @file{libiberty} and @file{readline} directories |
97f3cb72 RP |
360 | won't need any changes for your configuration, but if they do, you can |
361 | change the @file{configure.in} file there to recognize your system and | |
8cc1c08f | 362 | map to an @file{mh-@var{xxx}} file. Then add @file{mh-@var{xxx}} |
97f3cb72 RP |
363 | to the @file{config/} subdirectory, to set any makefile variables you |
364 | need. The only current options in there are things like @samp{-DSYSV}. | |
fd3d2e1d JG |
365 | (This @file{mh-@var{xxx}} naming convention differs from elsewhere |
366 | in GDB, by historical accident. It should be cleaned up so that all | |
367 | such files are called @file{@var{xxx}.mh}.) | |
97f3cb72 | 368 | |
b7becc8f | 369 | Aha! Now to configure GDB itself! Edit |
97f3cb72 RP |
370 | @file{gdb/configure.in} to recognize your system and set @code{gdb_host} |
371 | to @var{xxx}, and (unless your desired target is already available) also | |
372 | set @code{gdb_target} to something appropriate (for instance, | |
373 | @var{xxx}). To handle new hosts, modify the segment after the comment | |
374 | @samp{# per-host}; to handle new targets, modify after @samp{# | |
375 | per-target}. | |
376 | @c Would it be simpler to just use different per-host and per-target | |
377 | @c *scripts*, and call them from {configure} ? | |
7f27984e | 378 | |
fd3d2e1d | 379 | Finally, you'll need to specify and define GDB's host-, native-, and |
8cc1c08f JG |
380 | target-dependent @file{.h} and @file{.c} files used for your |
381 | configuration; the next two chapters discuss those. | |
7f27984e | 382 | |
7f27984e | 383 | |
b517f124 | 384 | @node Host |
97f3cb72 | 385 | @chapter Adding a New Host |
7f27984e | 386 | |
97f3cb72 | 387 | Once you have specified a new configuration for your host |
fd3d2e1d | 388 | (@pxref{Config,,Adding a New Configuration}), there are three remaining |
97f3cb72 RP |
389 | pieces to making GDB work on a new machine. First, you have to make it |
390 | host on the new machine (compile there, handle that machine's terminals | |
391 | properly, etc). If you will be cross-debugging to some other kind of | |
392 | system that's already supported, you are done. | |
46bc46eb | 393 | |
97f3cb72 RP |
394 | If you want to use GDB to debug programs that run on the new machine, |
395 | you have to get it to understand the machine's object files, symbol | |
fd3d2e1d JG |
396 | files, and interfaces to processes; @pxref{Target,,Adding a New Target} |
397 | and @pxref{Native,,Adding a New Native Configuration} | |
46bc46eb | 398 | |
aeb62c7b JG |
399 | Several files control GDB's configuration for host systems: |
400 | ||
401 | @table @file | |
3a8bc841 | 402 | @item gdb/config/@var{arch}/@var{xxx}.mh |
8cc1c08f JG |
403 | Specifies Makefile fragments needed when hosting on machine @var{xxx}. |
404 | In particular, this lists the required machine-dependent object files, | |
405 | by defining @samp{XDEPFILES=@dots{}}. Also | |
406 | specifies the header file which describes host @var{xxx}, by defining | |
c1cd5aec JK |
407 | @code{XM_FILE= xm-@var{xxx}.h}. You can also define @code{CC}, |
408 | @code{REGEX} and @code{REGEX1}, @code{SYSV_DEFINE}, @code{XM_CFLAGS}, | |
409 | @code{XM_ADD_FILES}, @code{XM_CLIBS}, @code{XM_CDEPS}, | |
aeb62c7b JG |
410 | etc.; see @file{Makefile.in}. |
411 | ||
3a8bc841 | 412 | @item gdb/config/@var{arch}/xm-@var{xxx}.h |
aeb62c7b JG |
413 | (@file{xm.h} is a link to this file, created by configure). |
414 | Contains C macro definitions describing the host system environment, | |
415 | such as byte order, host C compiler and library, ptrace support, | |
416 | and core file structure. Crib from existing @file{xm-*.h} files | |
417 | to create a new one. | |
418 | ||
419 | @item gdb/@var{xxx}-xdep.c | |
420 | Contains any miscellaneous C code required for this machine | |
fd3d2e1d JG |
421 | as a host. On many machines it doesn't exist at all. If it does |
422 | exist, put @file{@var{xxx}-xdep.o} into the @code{XDEPFILES} line | |
423 | in @file{gdb/config/mh-@var{xxx}}. | |
aeb62c7b | 424 | @end table |
46bc46eb | 425 | |
fd3d2e1d JG |
426 | @subheading Generic Host Support Files |
427 | ||
97f3cb72 | 428 | There are some ``generic'' versions of routines that can be used by |
fd3d2e1d | 429 | various systems. These can be customized in various ways by macros |
97f3cb72 RP |
430 | defined in your @file{xm-@var{xxx}.h} file. If these routines work for |
431 | the @var{xxx} host, you can just include the generic file's name (with | |
432 | @samp{.o}, not @samp{.c}) in @code{XDEPFILES}. | |
46bc46eb | 433 | |
97f3cb72 RP |
434 | Otherwise, if your machine needs custom support routines, you will need |
435 | to write routines that perform the same functions as the generic file. | |
436 | Put them into @code{@var{xxx}-xdep.c}, and put @code{@var{xxx}-xdep.o} | |
fd3d2e1d | 437 | into @code{XDEPFILES}. |
46bc46eb | 438 | |
fd3d2e1d JG |
439 | @table @file |
440 | @item ser-bsd.c | |
441 | This contains serial line support for Berkeley-derived Unix systems. | |
442 | ||
443 | @item ser-go32.c | |
444 | This contains serial line support for 32-bit programs running under DOS | |
445 | using the GO32 execution environment. | |
446 | ||
447 | @item ser-termios.c | |
448 | This contains serial line support for System V-derived Unix systems. | |
449 | @end table | |
450 | ||
451 | Now, you are now ready to try configuring GDB to compile using your system | |
452 | as its host. From the top level (above @file{bfd}, @file{gdb}, etc), do: | |
453 | ||
454 | @example | |
455 | ./configure @var{xxx} +target=vxworks960 | |
456 | @end example | |
457 | ||
458 | This will configure your system to cross-compile for VxWorks on | |
459 | the Intel 960, which is probably not what you really want, but it's | |
460 | a test case that works at this stage. (You haven't set up to be | |
461 | able to debug programs that run @emph{on} @var{xxx} yet.) | |
462 | ||
463 | If this succeeds, you can try building it all with: | |
464 | ||
465 | @example | |
466 | make | |
467 | @end example | |
468 | ||
469 | Repeat until the program configures, compiles, links, and runs. | |
470 | When run, it won't be able to do much (unless you have a VxWorks/960 | |
471 | board on your network) but you will know that the host support is | |
472 | pretty well done. | |
473 | ||
474 | Good luck! Comments and suggestions about this section are particularly | |
475 | welcome; send them to @samp{bug-gdb@@prep.ai.mit.edu}. | |
476 | ||
477 | @node Native | |
478 | @chapter Adding a New Native Configuration | |
479 | ||
480 | If you are making GDB run native on the @var{xxx} machine, you have | |
481 | plenty more work to do. Several files control GDB's configuration for | |
482 | native support: | |
46bc46eb | 483 | |
aeb62c7b | 484 | @table @file |
3a8bc841 | 485 | @item gdb/config/@var{xarch}/@var{xxx}.mh |
fd3d2e1d JG |
486 | Specifies Makefile fragments needed when hosting @emph{or native} |
487 | on machine @var{xxx}. | |
488 | In particular, this lists the required native-dependent object files, | |
489 | by defining @samp{NATDEPFILES=@dots{}}. Also | |
490 | specifies the header file which describes native support on @var{xxx}, | |
224226b8 | 491 | by defining @samp{NAT_FILE= nm-@var{xxx}.h}. |
fd3d2e1d JG |
492 | You can also define @samp{NAT_CFLAGS}, |
493 | @samp{NAT_ADD_FILES}, @samp{NAT_CLIBS}, @samp{NAT_CDEPS}, | |
494 | etc.; see @file{Makefile.in}. | |
495 | ||
3a8bc841 | 496 | @item gdb/config/@var{arch}/nm-@var{xxx}.h |
fd3d2e1d JG |
497 | (@file{nm.h} is a link to this file, created by configure). |
498 | Contains C macro definitions describing the native system environment, | |
499 | such as child process control and core file support. | |
500 | Crib from existing @file{nm-*.h} files to create a new one. | |
fd3d2e1d JG |
501 | |
502 | @item gdb/@var{xxx}-nat.c | |
503 | Contains any miscellaneous C code required for this native support | |
504 | of this machine. On some machines it doesn't exist at all. | |
505 | @end table | |
506 | ||
507 | @subheading Generic Native Support Files | |
508 | ||
509 | There are some ``generic'' versions of routines that can be used by | |
510 | various systems. These can be customized in various ways by macros | |
511 | defined in your @file{nm-@var{xxx}.h} file. If these routines work for | |
512 | the @var{xxx} host, you can just include the generic file's name (with | |
513 | @samp{.o}, not @samp{.c}) in @code{NATDEPFILES}. | |
514 | ||
515 | Otherwise, if your machine needs custom support routines, you will need | |
516 | to write routines that perform the same functions as the generic file. | |
517 | Put them into @code{@var{xxx}-nat.c}, and put @code{@var{xxx}-nat.o} | |
518 | into @code{NATDEPFILES}. | |
519 | ||
520 | @table @file | |
521 | ||
522 | @item inftarg.c | |
523 | This contains the @emph{target_ops vector} that supports Unix child | |
524 | processes on systems which use ptrace and wait to control the child. | |
525 | ||
526 | @item procfs.c | |
527 | This contains the @emph{target_ops vector} that supports Unix child | |
528 | processes on systems which use /proc to control the child. | |
529 | ||
530 | @item fork-child.c | |
531 | This does the low-level grunge that uses Unix system calls | |
532 | to do a "fork and exec" to start up a child process. | |
46bc46eb | 533 | |
97f3cb72 | 534 | @item infptrace.c |
aeb62c7b JG |
535 | This is the low level interface to inferior processes for systems |
536 | using the Unix @code{ptrace} call in a vanilla way. | |
46bc46eb | 537 | |
aeb62c7b | 538 | @item coredep.c::fetch_core_registers() |
46bc46eb | 539 | Support for reading registers out of a core file. This routine calls |
aeb62c7b JG |
540 | @code{register_addr()}, see below. |
541 | Now that BFD is used to read core files, virtually all machines should | |
542 | use @code{coredep.c}, and should just provide @code{fetch_core_registers} in | |
fd3d2e1d | 543 | @code{@var{xxx}-nat.c} (or @code{REGISTER_U_ADDR} in @code{nm-@var{xxx}.h}). |
ca714d03 | 544 | |
aeb62c7b | 545 | @item coredep.c::register_addr() |
fd3d2e1d | 546 | If your @code{nm-@var{xxx}.h} file defines the macro |
493cf018 JG |
547 | @code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to |
548 | set @code{addr} to the offset within the @samp{user} | |
549 | struct of GDB register number @code{regno}. @code{blockend} is the | |
550 | offset within the ``upage'' of @code{u.u_ar0}. | |
551 | If @code{REGISTER_U_ADDR} is defined, | |
d98259f8 RP |
552 | @file{coredep.c} will define the @code{register_addr()} function and use |
553 | the macro in it. If you do not define @code{REGISTER_U_ADDR}, but you | |
97f3cb72 RP |
554 | are using the standard @code{fetch_core_registers()}, you will need to |
555 | define your own version of @code{register_addr()}, put it into your | |
fd3d2e1d JG |
556 | @code{@var{xxx}-nat.c} file, and be sure @code{@var{xxx}-nat.o} is in |
557 | the @code{NATDEPFILES} list. If you have your own | |
97f3cb72 RP |
558 | @code{fetch_core_registers()}, you may not need a separate |
559 | @code{register_addr()}. Many custom @code{fetch_core_registers()} | |
560 | implementations simply locate the registers themselves.@refill | |
ca714d03 | 561 | @end table |
46bc46eb | 562 | |
fd3d2e1d JG |
563 | When making GDB run native on a new operating system, |
564 | to make it possible to debug | |
97f3cb72 RP |
565 | core files, you will need to either write specific code for parsing your |
566 | OS's core files, or customize @file{bfd/trad-core.c}. First, use | |
567 | whatever @code{#include} files your machine uses to define the struct of | |
568 | registers that is accessible (possibly in the u-area) in a core file | |
569 | (rather than @file{machine/reg.h}), and an include file that defines whatever | |
570 | header exists on a core file (e.g. the u-area or a @samp{struct core}). Then | |
571 | modify @code{trad_unix_core_file_p()} to use these values to set up the | |
572 | section information for the data segment, stack segment, any other | |
573 | segments in the core file (perhaps shared library contents or control | |
574 | information), ``registers'' segment, and if there are two discontiguous | |
575 | sets of registers (e.g. integer and float), the ``reg2'' segment. This | |
576 | section information basically delimits areas in the core file in a | |
577 | standard way, which the section-reading routines in BFD know how to seek | |
578 | around in. | |
579 | ||
b7becc8f RP |
580 | Then back in GDB, you need a matching routine called |
581 | @code{fetch_core_registers()}. If you can use the generic one, it's in | |
fd3d2e1d | 582 | @file{coredep.c}; if not, it's in your @file{@var{xxx}-nat.c} file. |
b7becc8f RP |
583 | It will be passed a char pointer to the entire ``registers'' segment, |
584 | its length, and a zero; or a char pointer to the entire ``regs2'' | |
585 | segment, its length, and a 2. The routine should suck out the supplied | |
586 | register values and install them into GDB's ``registers'' array. | |
587 | (@xref{New Architectures,,Defining a New Host or Target Architecture}, | |
1dbe1ef7 JG |
588 | for more info about this.) |
589 | ||
fd3d2e1d JG |
590 | If your system uses @file{/proc} to control processes, and uses ELF |
591 | format core files, then you may be able to use the same routines | |
592 | for reading the registers out of processes and out of core files. | |
97f3cb72 | 593 | |
b517f124 | 594 | @node Target |
7f09f15f | 595 | @chapter Adding a New Target |
d98259f8 | 596 | |
97f3cb72 RP |
597 | For a new target called @var{ttt}, first specify the configuration as |
598 | described in @ref{Config,,Adding a New Configuration}. If your new | |
599 | target is the same as your new host, you've probably already done that. | |
600 | ||
8cc1c08f | 601 | A variety of files specify attributes of the GDB target environment: |
1dbe1ef7 | 602 | |
aeb62c7b | 603 | @table @file |
3a8bc841 | 604 | @item gdb/config/@var{arch}/@var{ttt}.mt |
8cc1c08f | 605 | Contains a Makefile fragment specific to this target. |
aeb62c7b | 606 | Specifies what object files are needed for target @var{ttt}, by |
8cc1c08f | 607 | defining @samp{TDEPFILES=@dots{}}. |
aeb62c7b | 608 | Also specifies the header file which describes @var{ttt}, by defining |
8cc1c08f | 609 | @samp{TM_FILE= tm-@var{ttt}.h}. You can also define @samp{TM_CFLAGS}, |
fd3d2e1d | 610 | @samp{TM_CLIBS}, @samp{TM_CDEPS}, |
aeb62c7b JG |
611 | and other Makefile variables here; see @file{Makefile.in}. |
612 | ||
3a8bc841 | 613 | @item gdb/config/@var{arch}/tm-@var{ttt}.h |
aeb62c7b JG |
614 | (@file{tm.h} is a link to this file, created by configure). |
615 | Contains macro definitions about the target machine's | |
616 | registers, stack frame format and instructions. | |
617 | Crib from existing @file{tm-*.h} files when building a new one. | |
618 | ||
619 | @item gdb/@var{ttt}-tdep.c | |
620 | Contains any miscellaneous code required for this target machine. | |
621 | On some machines it doesn't exist at all. Sometimes the macros | |
622 | in @file{tm-@var{ttt}.h} become very complicated, so they are | |
623 | implemented as functions here instead, and the macro is simply | |
624 | defined to call the function. | |
625 | ||
626 | @item gdb/exec.c | |
627 | Defines functions for accessing files that are | |
97f3cb72 RP |
628 | executable on the target system. These functions open and examine an |
629 | exec file, extract data from one, write data to one, print information | |
630 | about one, etc. Now that executable files are handled with BFD, every | |
631 | target should be able to use the generic exec.c rather than its | |
632 | own custom code. | |
633 | ||
aeb62c7b JG |
634 | @item gdb/@var{arch}-pinsn.c |
635 | Prints (disassembles) the target machine's instructions. | |
636 | This file is usually shared with other target machines which use the | |
637 | same processor, which is why it is @file{@var{arch}-pinsn.c} rather | |
638 | than @file{@var{ttt}-pinsn.c}. | |
639 | ||
640 | @item gdb/@var{arch}-opcode.h | |
641 | Contains some large initialized | |
642 | data structures describing the target machine's instructions. | |
643 | This is a bit strange for a @file{.h} file, but it's OK since | |
644 | it is only included in one place. @file{@var{arch}-opcode.h} is shared | |
645 | between the debugger and the assembler, if the GNU assembler has been | |
646 | ported to the target machine. | |
647 | ||
3a8bc841 | 648 | @item gdb/config/@var{arch}/tm-@var{arch}.h |
aeb62c7b JG |
649 | This often exists to describe the basic layout of the target machine's |
650 | processor chip (registers, stack, etc). | |
651 | If used, it is included by @file{tm-@var{xxx}.h}. It can | |
652 | be shared among many targets that use the same processor. | |
653 | ||
654 | @item gdb/@var{arch}-tdep.c | |
655 | Similarly, there are often common subroutines that are shared by all | |
656 | target machines that use this particular architecture. | |
657 | @end table | |
658 | ||
659 | When adding support for a new target machine, there are various areas | |
660 | of support that might need change, or might be OK. | |
661 | ||
1dbe1ef7 JG |
662 | If you are using an existing object file format (a.out or COFF), |
663 | there is probably little to be done. See @file{bfd/doc/bfd.texinfo} | |
664 | for more information on writing new a.out or COFF versions. | |
665 | ||
6e1c67d2 JG |
666 | If you need to add a new object file format, you must first add it to |
667 | BFD. This is beyond the scope of this document right now. Basically | |
668 | you must build a transfer vector (of type @code{bfd_target}), which will | |
669 | mean writing all the required routines, and add it to the list in | |
1dbe1ef7 JG |
670 | @file{bfd/targets.c}. |
671 | ||
6e1c67d2 JG |
672 | You must then arrange for the BFD code to provide access to the |
673 | debugging symbols. Generally GDB will have to call swapping routines | |
674 | from BFD and a few other BFD internal routines to locate the debugging | |
675 | information. As much as possible, GDB should not depend on the BFD | |
676 | internal data structures. | |
677 | ||
678 | For some targets (e.g., COFF), there is a special transfer vector used | |
679 | to call swapping routines, since the external data structures on various | |
680 | platforms have different sizes and layouts. Specialized routines that | |
681 | will only ever be implemented by one object file format may be called | |
682 | directly. This interface should be described in a file | |
683 | @file{bfd/libxxx.h}, which is included by GDB. | |
684 | ||
97f3cb72 RP |
685 | If you are adding a new operating system for an existing CPU chip, add a |
686 | @file{tm-@var{xos}.h} file that describes the operating system | |
687 | facilities that are unusual (extra symbol table info; the breakpoint | |
688 | instruction needed; etc). Then write a | |
689 | @file{tm-@var{xarch}-@var{xos}.h} that just @code{#include}s | |
690 | @file{tm-@var{xarch}.h} and @file{tm-@var{xos}.h}. (Now that we have | |
1dbe1ef7 | 691 | three-part configuration names, this will probably get revised to |
97f3cb72 RP |
692 | separate the @var{xos} configuration from the @var{xarch} |
693 | configuration.) | |
694 | ||
695 | ||
b517f124 | 696 | @node Languages |
97f3cb72 RP |
697 | @chapter Adding a Source Language to GDB |
698 | ||
699 | To add other languages to GDB's expression parser, follow the following steps: | |
700 | ||
701 | @table @emph | |
702 | @item Create the expression parser. | |
703 | ||
704 | This should reside in a file @file{@var{lang}-exp.y}. Routines for building | |
705 | parsed expressions into a @samp{union exp_element} list are in @file{parse.c}. | |
706 | ||
aeb62c7b JG |
707 | Since we can't depend upon everyone having Bison, and YACC produces |
708 | parsers that define a bunch of global names, the following lines | |
709 | @emph{must} be included at the top of the YACC parser, to prevent | |
710 | the various parsers from defining the same global names: | |
d98259f8 | 711 | |
d98259f8 | 712 | @example |
97f3cb72 | 713 | #define yyparse @var{lang}_parse |
aeb62c7b | 714 | #define yylex @var{lang}_lex |
97f3cb72 RP |
715 | #define yyerror @var{lang}_error |
716 | #define yylval @var{lang}_lval | |
717 | #define yychar @var{lang}_char | |
718 | #define yydebug @var{lang}_debug | |
719 | #define yypact @var{lang}_pact | |
720 | #define yyr1 @var{lang}_r1 | |
721 | #define yyr2 @var{lang}_r2 | |
722 | #define yydef @var{lang}_def | |
723 | #define yychk @var{lang}_chk | |
724 | #define yypgo @var{lang}_pgo | |
725 | #define yyact @var{lang}_act | |
726 | #define yyexca @var{lang}_exca | |
aeb62c7b JG |
727 | #define yyerrflag @var{lang}_errflag |
728 | #define yynerrs @var{lang}_nerrs | |
d98259f8 | 729 | @end example |
d98259f8 | 730 | |
b7becc8f RP |
731 | At the bottom of your parser, define a @code{struct language_defn} and |
732 | initialize it with the right values for your language. Define an | |
733 | @code{initialize_@var{lang}} routine and have it call | |
734 | @samp{add_language(@var{lang}_language_defn)} to tell the rest of GDB | |
735 | that your language exists. You'll need some other supporting variables | |
736 | and functions, which will be used via pointers from your | |
737 | @code{@var{lang}_language_defn}. See the declaration of @code{struct | |
738 | language_defn} in @file{language.h}, and the other @file{*-exp.y} files, | |
739 | for more information. | |
740 | ||
97f3cb72 RP |
741 | @item Add any evaluation routines, if necessary |
742 | ||
743 | If you need new opcodes (that represent the operations of the language), | |
744 | add them to the enumerated type in @file{expression.h}. Add support | |
745 | code for these operations in @code{eval.c:evaluate_subexp()}. Add cases | |
746 | for new opcodes in two functions from @file{parse.c}: | |
747 | @code{prefixify_subexp()} and @code{length_of_subexp()}. These compute | |
748 | the number of @code{exp_element}s that a given operation takes up. | |
749 | ||
750 | @item Update some existing code | |
751 | ||
752 | Add an enumerated identifier for your language to the enumerated type | |
753 | @code{enum language} in @file{defs.h}. | |
754 | ||
755 | Update the routines in @file{language.c} so your language is included. These | |
756 | routines include type predicates and such, which (in some cases) are | |
757 | language dependent. If your language does not appear in the switch | |
758 | statement, an error is reported. | |
759 | ||
760 | Also included in @file{language.c} is the code that updates the variable | |
761 | @code{current_language}, and the routines that translate the | |
762 | @code{language_@var{lang}} enumerated identifier into a printable | |
763 | string. | |
764 | ||
765 | Update the function @code{_initialize_language} to include your language. This | |
766 | function picks the default language upon startup, so is dependent upon | |
767 | which languages that GDB is built for. | |
768 | ||
b7becc8f RP |
769 | Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading |
770 | code so that the language of each symtab (source file) is set properly. | |
771 | This is used to determine the language to use at each stack frame level. | |
772 | Currently, the language is set based upon the extension of the source | |
773 | file. If the language can be better inferred from the symbol | |
774 | information, please set the language of the symtab in the symbol-reading | |
775 | code. | |
97f3cb72 RP |
776 | |
777 | Add helper code to @code{expprint.c:print_subexp()} to handle any new | |
778 | expression opcodes you have added to @file{expression.h}. Also, add the | |
779 | printed representations of your operators to @code{op_print_tab}. | |
780 | ||
781 | @item Add a place of call | |
782 | ||
783 | Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in | |
784 | @code{parse.c:parse_exp_1()}. | |
785 | ||
786 | @item Use macros to trim code | |
787 | ||
788 | The user has the option of building GDB for some or all of the | |
789 | languages. If the user decides to build GDB for the language | |
790 | @var{lang}, then every file dependent on @file{language.h} will have the | |
791 | macro @code{_LANG_@var{lang}} defined in it. Use @code{#ifdef}s to | |
792 | leave out large routines that the user won't need if he or she is not | |
793 | using your language. | |
794 | ||
795 | Note that you do not need to do this in your YACC parser, since if GDB | |
796 | is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the | |
797 | compiled form of your parser) is not linked into GDB at all. | |
798 | ||
799 | See the file @file{configure.in} for how GDB is configured for different | |
800 | languages. | |
801 | ||
802 | @item Edit @file{Makefile.in} | |
803 | ||
804 | Add dependencies in @file{Makefile.in}. Make sure you update the macro | |
805 | variables such as @code{HFILES} and @code{OBJS}, otherwise your code may | |
806 | not get linked in, or, worse yet, it may not get @code{tar}red into the | |
807 | distribution! | |
808 | @end table | |
809 | ||
810 | ||
b517f124 | 811 | @node Releases |
97f3cb72 RP |
812 | @chapter Configuring GDB for Release |
813 | ||
b7becc8f RP |
814 | From the top level directory (containing @file{gdb}, @file{bfd}, |
815 | @file{libiberty}, and so on): | |
816 | @example | |
ca25cb3b | 817 | make -f Makefile.in gdb.tar.Z |
b7becc8f | 818 | @end example |
97f3cb72 | 819 | |
b7becc8f RP |
820 | This will properly configure, clean, rebuild any files that are |
821 | distributed pre-built (e.g. @file{c-exp.tab.c} or @file{refcard.ps}), | |
ca25cb3b JG |
822 | and will then make a tarfile. (If the top level directory has already |
823 | beenn configured, you can just do @code{make gdb.tar.Z} instead.) | |
b7becc8f RP |
824 | |
825 | This procedure requires: | |
826 | @itemize @bullet | |
827 | @item symbolic links | |
828 | @item @code{makeinfo} (texinfo2 level) | |
829 | @item @TeX{} | |
830 | @item @code{dvips} | |
831 | @item @code{yacc} or @code{bison} | |
832 | @end itemize | |
833 | @noindent | |
834 | @dots{} and the usual slew of utilities (@code{sed}, @code{tar}, etc.). | |
97f3cb72 RP |
835 | |
836 | @subheading TEMPORARY RELEASE PROCEDURE FOR DOCUMENTATION | |
837 | ||
838 | @file{gdb.texinfo} is currently marked up using the texinfo-2 macros, | |
839 | which are not yet a default for anything (but we have to start using | |
840 | them sometime). | |
841 | ||
842 | For making paper, the only thing this implies is the right generation of | |
843 | @file{texinfo.tex} needs to be included in the distribution. | |
844 | ||
845 | For making info files, however, rather than duplicating the texinfo2 | |
846 | distribution, generate @file{gdb-all.texinfo} locally, and include the files | |
847 | @file{gdb.info*} in the distribution. Note the plural; @code{makeinfo} will | |
848 | split the document into one overall file and five or so included files. | |
849 | ||
850 | ||
b517f124 | 851 | @node Partial Symbol Tables |
493cf018 JG |
852 | @chapter Partial Symbol Tables |
853 | ||
854 | GDB has three types of symbol tables. | |
855 | ||
856 | @itemize @bullet | |
857 | @item full symbol tables (symtabs). These contain the main | |
858 | information about symbols and addresses. | |
859 | @item partial symbol tables (psymtabs). These contain enough | |
860 | information to know when to read the corresponding | |
861 | part of the full symbol table. | |
862 | @item minimal symbol tables (msymtabs). These contain information | |
863 | gleaned from non-debugging symbols. | |
864 | @end itemize | |
865 | ||
866 | This section describes partial symbol tables. | |
867 | ||
868 | A psymtab is constructed by doing a very quick pass over an executable | |
869 | file's debugging information. Small amounts of information are | |
870 | extracted -- enough to identify which parts of the symbol table will | |
871 | need to be re-read and fully digested later, when the user needs the | |
872 | information. The speed of this pass causes GDB to start up very | |
873 | quickly. Later, as the detailed rereading occurs, it occurs in small | |
874 | pieces, at various times, and the delay therefrom is mostly invisible to | |
875 | the user. (@xref{Symbol Reading}.) | |
876 | ||
877 | The symbols that show up in a file's psymtab should be, roughly, those | |
878 | visible to the debugger's user when the program is not running code from | |
879 | that file. These include external symbols and types, static | |
880 | symbols and types, and enum values declared at file scope. | |
881 | ||
882 | The psymtab also contains the range of instruction addresses that the | |
883 | full symbol table would represent. | |
884 | ||
885 | The idea is that there are only two ways for the user (or much of | |
886 | the code in the debugger) to reference a symbol: | |
887 | ||
888 | @itemize @bullet | |
889 | ||
890 | @item by its address | |
891 | (e.g. execution stops at some address which is inside a function | |
892 | in this file). The address will be noticed to be in the | |
893 | range of this psymtab, and the full symtab will be read in. | |
894 | @code{find_pc_function}, @code{find_pc_line}, and other @code{find_pc_@dots{}} | |
895 | functions handle this. | |
896 | ||
897 | @item by its name | |
898 | (e.g. the user asks to print a variable, or set a breakpoint on a | |
899 | function). Global names and file-scope names will be found in the | |
900 | psymtab, which will cause the symtab to be pulled in. Local names will | |
901 | have to be qualified by a global name, or a file-scope name, in which | |
902 | case we will have already read in the symtab as we evaluated the | |
903 | qualifier. Or, a local symbol can be referenced when | |
904 | we are "in" a local scope, in which case the first case applies. | |
905 | @code{lookup_symbol} does most of the work here. | |
906 | ||
907 | @end itemize | |
908 | ||
909 | The only reason that psymtabs exist is to cause a symtab to be read in | |
910 | at the right moment. Any symbol that can be elided from a psymtab, | |
911 | while still causing that to happen, should not appear in it. Since | |
912 | psymtabs don't have the idea of scope, you can't put local symbols in | |
913 | them anyway. Psymtabs don't have the idea of the type of a symbol, | |
914 | either, so types need not appear, unless they will be referenced by | |
915 | name. | |
916 | ||
917 | It is a bug for GDB to behave one way when only a psymtab has been read, | |
918 | and another way if the corresponding symtab has been read in. Such | |
919 | bugs are typically caused by a psymtab that does not contain all the | |
920 | visible symbols, or which has the wrong instruction address ranges. | |
921 | ||
922 | The psymtab for a particular section of a symbol-file (objfile) | |
923 | could be thrown away after the symtab has been read in. The symtab | |
924 | should always be searched before the psymtab, so the psymtab will | |
925 | never be used (in a bug-free environment). Currently, | |
926 | psymtabs are allocated on an obstack, and all the psymbols themselves | |
927 | are allocated in a pair of large arrays on an obstack, so there is | |
928 | little to be gained by trying to free them unless you want to do a lot | |
929 | more work. | |
930 | ||
3a8bc841 JK |
931 | @node Types |
932 | @chapter Types | |
933 | ||
934 | Fundamental Types (e.g., FT_VOID, FT_BOOLEAN). | |
935 | ||
936 | These are the fundamental types that gdb uses internally. Fundamental | |
937 | types from the various debugging formats (stabs, ELF, etc) are mapped into | |
938 | one of these. They are basically a union of all fundamental types that | |
939 | gdb knows about for all the languages that gdb knows about. | |
940 | ||
941 | Type Codes (e.g., TYPE_CODE_PTR, TYPE_CODE_ARRAY). | |
942 | ||
943 | Each time gdb builds an internal type, it marks it with one of these | |
944 | types. The type may be a fundamental type, such as TYPE_CODE_INT, or | |
945 | a derived type, such as TYPE_CODE_PTR which is a pointer to another | |
946 | type. Typically, several FT_* types map to one TYPE_CODE_* type, and | |
947 | are distinguished by other members of the type struct, such as whether | |
948 | the type is signed or unsigned, and how many bits it uses. | |
949 | ||
950 | Builtin Types (e.g., builtin_type_void, builtin_type_char). | |
951 | ||
952 | These are instances of type structs that roughly correspond to fundamental | |
953 | types and are created as global types for gdb to use for various ugly | |
954 | historical reasons. We eventually want to eliminate these. Note for | |
955 | example that builtin_type_int initialized in gdbtypes.c is basically the | |
956 | same as a TYPE_CODE_INT type that is initialized in c-lang.c for an | |
957 | FT_INTEGER fundamental type. The difference is that the builtin_type is | |
958 | not associated with any particular objfile, and only one instance exists, | |
959 | while c-lang.c builds as many TYPE_CODE_INT types as needed, with each | |
960 | one associated with some particular objfile. | |
961 | ||
b517f124 | 962 | @node BFD support for GDB |
97f3cb72 | 963 | @chapter Binary File Descriptor Library Support for GDB |
7f09f15f JG |
964 | |
965 | BFD provides support for GDB in several ways: | |
966 | ||
967 | @table @emph | |
968 | @item identifying executable and core files | |
969 | BFD will identify a variety of file types, including a.out, coff, and | |
970 | several variants thereof, as well as several kinds of core files. | |
971 | ||
972 | @item access to sections of files | |
973 | BFD parses the file headers to determine the names, virtual addresses, | |
974 | sizes, and file locations of all the various named sections in files | |
975 | (such as the text section or the data section). GDB simply calls | |
976 | BFD to read or write section X at byte offset Y for length Z. | |
977 | ||
978 | @item specialized core file support | |
979 | BFD provides routines to determine the failing command name stored | |
980 | in a core file, the signal with which the program failed, and whether | |
981 | a core file matches (i.e. could be a core dump of) a particular executable | |
982 | file. | |
983 | ||
984 | @item locating the symbol information | |
985 | GDB uses an internal interface of BFD to determine where to find the | |
986 | symbol information in an executable file or symbol-file. GDB itself | |
987 | handles the reading of symbols, since BFD does not ``understand'' debug | |
988 | symbols, but GDB uses BFD's cached information to find the symbols, | |
989 | string table, etc. | |
990 | @end table | |
991 | ||
b7becc8f RP |
992 | @c The interface for symbol reading is described in @ref{Symbol |
993 | @c Reading,,Symbol Reading}. | |
7f09f15f | 994 | |
7f09f15f | 995 | |
b517f124 | 996 | @node Symbol Reading |
eb752e4e JG |
997 | @chapter Symbol Reading |
998 | ||
999 | GDB reads symbols from "symbol files". The usual symbol file is the | |
1000 | file containing the program which gdb is debugging. GDB can be directed | |
1001 | to use a different file for symbols (with the ``symbol-file'' | |
1002 | command), and it can also read more symbols via the ``add-file'' and ``load'' | |
1003 | commands, or while reading symbols from shared libraries. | |
1004 | ||
1005 | Symbol files are initially opened by @file{symfile.c} using the BFD | |
1006 | library. BFD identifies the type of the file by examining its header. | |
1007 | @code{symfile_init} then uses this identification to locate a | |
1008 | set of symbol-reading functions. | |
1009 | ||
1010 | Symbol reading modules identify themselves to GDB by calling | |
1011 | @code{add_symtab_fns} during their module initialization. The argument | |
1012 | to @code{add_symtab_fns} is a @code{struct sym_fns} which contains | |
1013 | the name (or name prefix) of the symbol format, the length of the prefix, | |
1014 | and pointers to four functions. These functions are called at various | |
1015 | times to process symbol-files whose identification matches the specified | |
1016 | prefix. | |
1017 | ||
1018 | The functions supplied by each module are: | |
1019 | ||
1020 | @table @code | |
97f3cb72 | 1021 | @item @var{xxx}_symfile_init(struct sym_fns *sf) |
eb752e4e JG |
1022 | |
1023 | Called from @code{symbol_file_add} when we are about to read a new | |
1024 | symbol file. This function should clean up any internal state | |
1025 | (possibly resulting from half-read previous files, for example) | |
1026 | and prepare to read a new symbol file. Note that the symbol file | |
1027 | which we are reading might be a new "main" symbol file, or might | |
1028 | be a secondary symbol file whose symbols are being added to the | |
1029 | existing symbol table. | |
1030 | ||
97f3cb72 | 1031 | The argument to @code{@var{xxx}_symfile_init} is a newly allocated |
eb752e4e JG |
1032 | @code{struct sym_fns} whose @code{bfd} field contains the BFD |
1033 | for the new symbol file being read. Its @code{private} field | |
1034 | has been zeroed, and can be modified as desired. Typically, | |
1035 | a struct of private information will be @code{malloc}'d, and | |
1036 | a pointer to it will be placed in the @code{private} field. | |
1037 | ||
97f3cb72 | 1038 | There is no result from @code{@var{xxx}_symfile_init}, but it can call |
eb752e4e JG |
1039 | @code{error} if it detects an unavoidable problem. |
1040 | ||
97f3cb72 | 1041 | @item @var{xxx}_new_init() |
eb752e4e JG |
1042 | |
1043 | Called from @code{symbol_file_add} when discarding existing symbols. | |
1044 | This function need only handle | |
1045 | the symbol-reading module's internal state; the symbol table data | |
1046 | structures visible to the rest of GDB will be discarded by | |
1047 | @code{symbol_file_add}. It has no arguments and no result. | |
97f3cb72 | 1048 | It may be called after @code{@var{xxx}_symfile_init}, if a new symbol |
eb752e4e JG |
1049 | table is being read, or may be called alone if all symbols are |
1050 | simply being discarded. | |
1051 | ||
97f3cb72 | 1052 | @item @var{xxx}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline) |
eb752e4e JG |
1053 | |
1054 | Called from @code{symbol_file_add} to actually read the symbols from a | |
1055 | symbol-file into a set of psymtabs or symtabs. | |
1056 | ||
d98259f8 | 1057 | @code{sf} points to the struct sym_fns originally passed to |
97f3cb72 | 1058 | @code{@var{xxx}_sym_init} for possible initialization. @code{addr} is the |
d98259f8 RP |
1059 | offset between the file's specified start address and its true address |
1060 | in memory. @code{mainline} is 1 if this is the main symbol table being | |
1061 | read, and 0 if a secondary symbol file (e.g. shared library or | |
1062 | dynamically loaded file) is being read.@refill | |
eb752e4e JG |
1063 | @end table |
1064 | ||
1065 | In addition, if a symbol-reading module creates psymtabs when | |
97f3cb72 RP |
1066 | @var{xxx}_symfile_read is called, these psymtabs will contain a pointer to |
1067 | a function @code{@var{xxx}_psymtab_to_symtab}, which can be called from | |
eb752e4e JG |
1068 | any point in the GDB symbol-handling code. |
1069 | ||
1070 | @table @code | |
97f3cb72 | 1071 | @item @var{xxx}_psymtab_to_symtab (struct partial_symtab *pst) |
eb752e4e JG |
1072 | |
1073 | Called from @code{psymtab_to_symtab} (or the PSYMTAB_TO_SYMTAB | |
1074 | macro) if the psymtab has not already been read in and had its | |
1075 | @code{pst->symtab} pointer set. The argument is the psymtab | |
1076 | to be fleshed-out into a symtab. Upon return, pst->readin | |
1077 | should have been set to 1, and pst->symtab should contain a | |
1078 | pointer to the new corresponding symtab, or zero if there | |
1079 | were no symbols in that part of the symbol file. | |
1080 | @end table | |
1081 | ||
7f09f15f | 1082 | |
b517f124 | 1083 | @node Cleanups |
97f3cb72 | 1084 | @chapter Cleanups |
7f09f15f | 1085 | |
97f3cb72 RP |
1086 | Cleanups are a structured way to deal with things that need to be done |
1087 | later. When your code does something (like @code{malloc} some memory, or open | |
1088 | a file) that needs to be undone later (e.g. free the memory or close | |
1089 | the file), it can make a cleanup. The cleanup will be done at some | |
1090 | future point: when the command is finished, when an error occurs, or | |
1091 | when your code decides it's time to do cleanups. | |
7f09f15f | 1092 | |
97f3cb72 RP |
1093 | You can also discard cleanups, that is, throw them away without doing |
1094 | what they say. This is only done if you ask that it be done. | |
7f09f15f | 1095 | |
97f3cb72 | 1096 | Syntax: |
7f09f15f | 1097 | |
97f3cb72 | 1098 | @table @code |
f8f37439 DZ |
1099 | @item struct cleanup *@var{old_chain}; |
1100 | Declare a variable which will hold a cleanup chain handle. | |
1101 | ||
97f3cb72 RP |
1102 | @item @var{old_chain} = make_cleanup (@var{function}, @var{arg}); |
1103 | Make a cleanup which will cause @var{function} to be called with @var{arg} | |
1104 | (a @code{char *}) later. The result, @var{old_chain}, is a handle that can be | |
1105 | passed to @code{do_cleanups} or @code{discard_cleanups} later. Unless you are | |
1106 | going to call @code{do_cleanups} or @code{discard_cleanups} yourself, | |
1107 | you can ignore the result from @code{make_cleanup}. | |
7f09f15f | 1108 | |
7f09f15f | 1109 | |
97f3cb72 RP |
1110 | @item do_cleanups (@var{old_chain}); |
1111 | Perform all cleanups done since @code{make_cleanup} returned @var{old_chain}. | |
1112 | E.g.: | |
1113 | @example | |
1114 | make_cleanup (a, 0); | |
1115 | old = make_cleanup (b, 0); | |
1116 | do_cleanups (old); | |
1117 | @end example | |
1118 | @noindent | |
1119 | will call @code{b()} but will not call @code{a()}. The cleanup that calls @code{a()} will remain | |
1120 | in the cleanup chain, and will be done later unless otherwise discarded.@refill | |
7f09f15f | 1121 | |
97f3cb72 RP |
1122 | @item discard_cleanups (@var{old_chain}); |
1123 | Same as @code{do_cleanups} except that it just removes the cleanups from the | |
1124 | chain and does not call the specified functions. | |
7f09f15f | 1125 | |
97f3cb72 | 1126 | @end table |
7f09f15f | 1127 | |
97f3cb72 RP |
1128 | Some functions, e.g. @code{fputs_filtered()} or @code{error()}, specify that they |
1129 | ``should not be called when cleanups are not in place''. This means | |
1130 | that any actions you need to reverse in the case of an error or | |
1131 | interruption must be on the cleanup chain before you call these functions, | |
1132 | since they might never return to your code (they @samp{longjmp} instead). | |
7f09f15f | 1133 | |
7f09f15f | 1134 | |
b517f124 | 1135 | @node Wrapping |
97f3cb72 | 1136 | @chapter Wrapping Output Lines |
7f09f15f | 1137 | |
97f3cb72 RP |
1138 | Output that goes through @code{printf_filtered} or @code{fputs_filtered} or |
1139 | @code{fputs_demangled} needs only to have calls to @code{wrap_here} added | |
1140 | in places that would be good breaking points. The utility routines | |
1141 | will take care of actually wrapping if the line width is exceeded. | |
7f09f15f | 1142 | |
97f3cb72 RP |
1143 | The argument to @code{wrap_here} is an indentation string which is printed |
1144 | @emph{only} if the line breaks there. This argument is saved away and used | |
1145 | later. It must remain valid until the next call to @code{wrap_here} or | |
1146 | until a newline has been printed through the @code{*_filtered} functions. | |
1147 | Don't pass in a local variable and then return! | |
7f09f15f | 1148 | |
97f3cb72 RP |
1149 | It is usually best to call @code{wrap_here()} after printing a comma or space. |
1150 | If you call it before printing a space, make sure that your indentation | |
1151 | properly accounts for the leading space that will print if the line wraps | |
1152 | there. | |
7f09f15f | 1153 | |
97f3cb72 RP |
1154 | Any function or set of functions that produce filtered output must finish |
1155 | by printing a newline, to flush the wrap buffer, before switching to | |
1156 | unfiltered (``@code{printf}'') output. Symbol reading routines that print | |
1157 | warnings are a good example. | |
7f09f15f | 1158 | |
7f09f15f | 1159 | |
b517f124 | 1160 | @node Frames |
edbf28ce JG |
1161 | @chapter Frames |
1162 | ||
1163 | A frame is a construct that GDB uses to keep track of calling and called | |
1164 | functions. | |
1165 | ||
8cc1c08f JG |
1166 | @table @code |
1167 | @item FRAME_FP | |
1168 | in the machine description has no meaning to the machine-independent | |
edbf28ce JG |
1169 | part of GDB, except that it is used when setting up a new frame from |
1170 | scratch, as follows: | |
1171 | ||
1172 | @example | |
1173 | create_new_frame (read_register (FP_REGNUM), read_pc ())); | |
1174 | @end example | |
1175 | ||
8cc1c08f JG |
1176 | Other than that, all the meaning imparted to @code{FP_REGNUM} is imparted by |
1177 | the machine-dependent code. So, @code{FP_REGNUM} can have any value that | |
1178 | is convenient for the code that creates new frames. (@code{create_new_frame} | |
1179 | calls @code{INIT_EXTRA_FRAME_INFO} if it is defined; that is where you should | |
1180 | use the @code{FP_REGNUM} value, if your frames are nonstandard.) | |
1181 | ||
1182 | @item FRAME_CHAIN | |
1183 | Given a GDB frame, determine the address of the calling function's | |
1184 | frame. This will be used to create a new GDB frame struct, and then | |
1185 | @code{INIT_EXTRA_FRAME_INFO} and @code{INIT_FRAME_PC} will be called for | |
1186 | the new frame. | |
1187 | @end table | |
edbf28ce | 1188 | |
00db1549 JG |
1189 | @node Remote Stubs |
1190 | @chapter Remote Stubs | |
1191 | ||
1192 | GDB's file @file{remote.c} talks a serial protocol to code that runs | |
1193 | in the target system. GDB provides several sample ``stubs'' that can | |
1194 | be integrated into target programs or operating systems for this purpose; | |
1195 | they are named @file{*-stub.c}. | |
1196 | ||
1197 | The GDB user's manual describes how to put such a stub into your target | |
1198 | code. What follows is a discussion of integrating the SPARC stub | |
1199 | into a complicated operating system (rather than a simple program), | |
1200 | by Stu Grossman, the author of this stub. | |
1201 | ||
1202 | The trap handling code in the stub assumes the following upon entry to | |
1203 | trap_low: | |
1204 | ||
1205 | @enumerate | |
1206 | @item %l1 and %l2 contain pc and npc respectively at the time of the trap | |
1207 | @item traps are disabled | |
1208 | @item you are in the correct trap window | |
1209 | @end enumerate | |
1210 | ||
1211 | As long as your trap handler can guarantee those conditions, then there is no | |
1212 | reason why you shouldn't be able to `share' traps with the stub. The stub has | |
1213 | no requirement that it be jumped to directly from the hardware trap vector. | |
1214 | That is why it calls @code{exceptionHandler()}, which is provided by the external | |
1215 | environment. For instance, this could setup the hardware traps to actually | |
1216 | execute code which calls the stub first, and then transfers to its own trap | |
1217 | handler. | |
1218 | ||
1219 | For the most point, there probably won't be much of an issue with `sharing' | |
1220 | traps, as the traps we use are usually not used by the kernel, and often | |
1221 | indicate unrecoverable error conditions. Anyway, this is all controlled by a | |
1222 | table, and is trivial to modify. | |
1223 | The most important trap for us is for @code{ta 1}. Without that, we | |
1224 | can't single step or do breakpoints. Everything else is unnecessary | |
1225 | for the proper operation of the debugger/stub. | |
1226 | ||
1227 | From reading the stub, it's probably not obvious how breakpoints work. They | |
1228 | are simply done by deposit/examine operations from GDB. | |
1229 | ||
d3d6d0ff JG |
1230 | @node Longjmp Support |
1231 | @chapter Longjmp Support | |
1232 | ||
1233 | GDB has support for figuring out that the target is doing a | |
1234 | @code{longjmp} and for stopping at the target of the jump, if we are | |
1235 | stepping. This is done with a few specialized internal breakpoints, | |
1236 | which are visible in the @code{maint info breakpoint} command. | |
1237 | ||
1238 | To make this work, you need to define a macro called | |
1239 | @code{GET_LONGJMP_TARGET}, which will examine the @code{jmp_buf} | |
1240 | structure and extract the longjmp target address. Since @code{jmp_buf} | |
1241 | is target specific, you will need to define it in the appropriate | |
1242 | @file{tm-xxx.h} file. Look in @file{tm-sun4os4.h} and | |
1243 | @file{sparc-tdep.c} for examples of how to do this. | |
1244 | ||
b517f124 | 1245 | @node Coding Style |
968720bf RP |
1246 | @chapter Coding Style |
1247 | ||
1248 | GDB is generally written using the GNU coding standards, as described in | |
a5e7f259 JK |
1249 | @file{standards.texi}, which is available for anonymous FTP from GNU |
1250 | archive sites. There are some additional considerations for GDB | |
1251 | maintainers that reflect the unique environment and style of GDB | |
1252 | maintenance. If you follow these guidelines, GDB will be more | |
1253 | consistent and easier to maintain. | |
968720bf RP |
1254 | |
1255 | GDB's policy on the use of prototypes is that prototypes are used | |
1256 | to @emph{declare} functions but never to @emph{define} them. Simple | |
1257 | macros are used in the declarations, so that a non-ANSI compiler can | |
1258 | compile GDB without trouble. The simple macro calls are used like | |
1259 | this: | |
1260 | ||
1261 | @example @code | |
1262 | extern int | |
1263 | memory_remove_breakpoint PARAMS ((CORE_ADDR, char *)); | |
1264 | @end example | |
1265 | ||
1266 | Note the double parentheses around the parameter types. This allows | |
1267 | an arbitrary number of parameters to be described, without freaking | |
1268 | out the C preprocessor. When the function has no parameters, it | |
1269 | should be described like: | |
1270 | ||
1271 | @example @code | |
1272 | void | |
1273 | noprocess PARAMS ((void)); | |
1274 | @end example | |
1275 | ||
1276 | The @code{PARAMS} macro expands to its argument in ANSI C, or to a simple | |
1277 | @code{()} in traditional C. | |
1278 | ||
1279 | All external functions should have a @code{PARAMS} declaration in a | |
1280 | header file that callers include. All static functions should have such | |
1281 | a declaration near the top of their source file. | |
1282 | ||
1283 | We don't have a gcc option that will properly check that these rules | |
1284 | have been followed, but it's GDB policy, and we periodically check it | |
1285 | using the tools available (plus manual labor), and clean up any remnants. | |
1286 | ||
2a20c602 JG |
1287 | @node Clean Design |
1288 | @chapter Clean Design | |
1289 | ||
1290 | In addition to getting the syntax right, there's the little question of | |
1291 | semantics. Some things are done in certain ways in GDB because long | |
1292 | experience has shown that the more obvious ways caused various kinds of | |
1293 | trouble. In particular: | |
1294 | ||
1295 | @table @bullet | |
1296 | @item | |
1297 | You can't assume the byte order of anything that comes from a | |
1298 | target (including @var{value}s, object files, and instructions). Such | |
00db1549 | 1299 | things must be byte-swapped using @code{SWAP_TARGET_AND_HOST} in GDB, |
2a20c602 JG |
1300 | or one of the swap routines defined in @file{bfd.h}, such as @code{bfd_get_32}. |
1301 | ||
1302 | @item | |
1303 | You can't assume that you know what interface is being used to talk to | |
1304 | the target system. All references to the target must go through the | |
1305 | current @code{target_ops} vector. | |
1306 | ||
1307 | @item | |
1308 | You can't assume that the host and target machines are the same machine | |
1309 | (except in the ``native'' support modules). | |
1310 | In particular, you can't assume that the target machine's header files | |
1311 | will be available on the host machine. Target code must bring along its | |
1312 | own header files -- written from scratch or explicitly donated by their | |
1313 | owner, to avoid copyright problems. | |
1314 | ||
1315 | @item | |
00db1549 JG |
1316 | Insertion of new @code{#ifdef}'s will be frowned upon. It's much better |
1317 | to write the code portably than to conditionalize it for various systems. | |
2a20c602 JG |
1318 | |
1319 | @item | |
1320 | New @code{#ifdef}'s which test for specific compilers or manufacturers | |
1321 | or operating systems are unacceptable. All @code{#ifdef}'s should test | |
1322 | for features. The information about which configurations contain which | |
1323 | features should be segregated into the configuration files. Experience | |
1324 | has proven far too often that a feature unique to one particular system | |
1325 | often creeps into other systems; and that a conditional based on | |
1326 | some predefined macro for your current system will become worthless | |
1327 | over time, as new versions of your system come out that behave differently | |
1328 | with regard to this feature. | |
1329 | ||
1330 | @item | |
1331 | Adding code that handles specific architectures, operating systems, target | |
1332 | interfaces, or hosts, is not acceptable in generic code. If a hook | |
1333 | is needed at that point, invent a generic hook and define it for your | |
1334 | configuration, with something like: | |
1335 | ||
1336 | @example | |
1337 | #ifdef WRANGLE_SIGNALS | |
1338 | WRANGLE_SIGNALS (signo); | |
1339 | #endif | |
1340 | @end example | |
1341 | ||
1342 | In your host, target, or native configuration file, as appropriate, | |
1343 | define @code{WRANGLE_SIGNALS} to do the machine-dependent thing. Take | |
1344 | a bit of care in defining the hook, so that it can be used by other | |
1345 | ports in the future, if they need a hook in the same place. | |
1346 | ||
a5e7f259 JK |
1347 | If the hook is not defined, the code should do whatever "most" machines |
1348 | want. Using @code{#ifdef}, as above, is the preferred way to do this, | |
1349 | but sometimes that gets convoluted, in which case use | |
1350 | ||
1351 | @example | |
1352 | #ifndef SPECIAL_FOO_HANDLING | |
1353 | #define SPECIAL_FOO_HANDLING(pc, sp) (0) | |
1354 | #endif | |
1355 | @end example | |
1356 | ||
1357 | where the macro is used or in an appropriate header file. | |
1358 | ||
1359 | Whether to include a @dfn{small} hook, a hook around the exact pieces of | |
1360 | code which are system-dependent, or whether to replace a whole function | |
1361 | with a hook depends on the case. A good example of this dilemma can be | |
1362 | found in @code{get_saved_register}. All machines that GDB 2.8 ran on | |
1363 | just needed the @code{FRAME_FIND_SAVED_REGS} hook to find the saved | |
1364 | registers. Then the SPARC and Pyramid came along, and | |
1365 | @code{HAVE_REGISTER_WINDOWS} and @code{REGISTER_IN_WINDOW_P} were | |
1366 | introduced. Then the 29k and 88k required the @code{GET_SAVED_REGISTER} | |
1367 | hook. The first three are examples of small hooks; the latter replaces | |
1368 | a whole function. In this specific case, it is useful to have both | |
1369 | kinds; it would be a bad idea to replace all the uses of the small hooks | |
1370 | with @code{GET_SAVED_REGISTER}, since that would result in much | |
1371 | duplicated code. Other times, duplicating a few lines of code here or | |
1372 | there is much cleaner than introducing a large number of small hooks. | |
1373 | ||
1374 | Another way to generalize GDB along a particular interface is with an | |
1375 | attribute struct. For example, GDB has been generalized to handle | |
1376 | multiple kinds of remote interfaces -- not by #ifdef's everywhere, but | |
1377 | by defining the "target_ops" structure and having a current target (as | |
1378 | well as a stack of targets below it, for memory references). Whenever | |
1379 | something needs to be done that depends on which remote interface we are | |
1380 | using, a flag in the current target_ops structure is tested (e.g. | |
1381 | `target_has_stack'), or a function is called through a pointer in the | |
1382 | current target_ops structure. In this way, when a new remote interface | |
1383 | is added, only one module needs to be touched -- the one that actually | |
1384 | implements the new remote interface. Other examples of | |
1385 | attribute-structs are BFD access to multiple kinds of object file | |
1386 | formats, or GDB's access to multiple source languages. | |
1387 | ||
1388 | Please avoid duplicating code. For example, in GDB 3.x all the code | |
1389 | interfacing between @code{ptrace} and the rest of GDB was duplicated in | |
1390 | @file{*-dep.c}, and so changing something was very painful. In GDB 4.x, | |
1391 | these have all been consolidated into @file{infptrace.c}. | |
1392 | @file{infptrace.c} can deal with variations between systems the same way | |
1393 | any system-independent file would (hooks, #if defined, etc.), and | |
1394 | machines which are radically different don't need to use infptrace.c at | |
1395 | all. | |
1396 | ||
2a20c602 JG |
1397 | @item |
1398 | @emph{Do} write code that doesn't depend on the sizes of C data types, | |
1399 | the format of the host's floating point numbers, the alignment of anything, | |
1400 | or the order of evaluation of expressions. In short, follow good | |
1401 | programming practices for writing portable C code. | |
1402 | ||
1403 | @end table | |
1404 | ||
1405 | @node Submitting Patches | |
1406 | @chapter Submitting Patches | |
1407 | ||
1408 | Thanks for thinking of offering your changes back to the community of | |
1409 | GDB users. In general we like to get well designed enhancements. | |
1410 | Thanks also for checking in advance about the best way to transfer the | |
1411 | changes. | |
1412 | ||
1413 | The two main problems with getting your patches in are, | |
1414 | ||
1415 | @table @bullet | |
1416 | @item | |
a5e7f259 | 1417 | The GDB maintainers will only install ``cleanly designed'' patches. |
2a20c602 JG |
1418 | You may not always agree on what is clean design. |
1419 | @pxref{Coding Style}, @pxref{Clean Design}. | |
1420 | ||
1421 | @item | |
1422 | If the maintainers don't have time to put the patch in when it | |
1423 | arrives, or if there is any question about a patch, it | |
1424 | goes into a large queue with everyone else's patches and | |
00db1549 | 1425 | bug reports. |
2a20c602 JG |
1426 | @end table |
1427 | ||
1428 | I don't know how to get past these problems except by continuing to try. | |
1429 | ||
1430 | There are two issues here -- technical and legal. | |
1431 | ||
1432 | The legal issue is that to incorporate substantial changes requires a | |
a5e7f259 JK |
1433 | copyright assignment from you and/or your employer, granting ownership |
1434 | of the changes to the Free Software Foundation. You can get the | |
1435 | standard document for doing this by sending mail to | |
1436 | @code{gnu@@prep.ai.mit.edu} and asking for it. I recommend that people | |
1437 | write in "All programs owned by the Free Software Foundation" as "NAME | |
1438 | OF PROGRAM", so that changes in many programs (not just GDB, but GAS, | |
1439 | Emacs, GCC, etc) can be contributed with only one piece of legalese | |
1440 | pushed through the bureacracy and filed with the FSF. I can't start | |
1441 | merging changes until this paperwork is received by the FSF (their | |
1442 | rules, which I follow since I maintain it for them). | |
2a20c602 JG |
1443 | |
1444 | Technically, the easiest way to receive changes is to receive each | |
1445 | feature as a small context diff or unidiff, suitable for "patch". | |
1446 | Each message sent to me should include the changes to C code and | |
1447 | header files for a single feature, plus ChangeLog entries for each | |
1448 | directory where files were modified, and diffs for any changes needed | |
1449 | to the manuals (gdb/doc/gdb.texi or gdb/doc/gdbint.texi). If there | |
1450 | are a lot of changes for a single feature, they can be split down | |
1451 | into multiple messages. | |
1452 | ||
1453 | In this way, if I read and like the feature, I can add it to the | |
1454 | sources with a single patch command, do some testing, and check it in. | |
1455 | If you leave out the ChangeLog, I have to write one. If you leave | |
1456 | out the doc, I have to puzzle out what needs documenting. Etc. | |
1457 | ||
1458 | The reason to send each change in a separate message is that I will | |
1459 | not install some of the changes. They'll be returned to you with | |
1460 | questions or comments. If I'm doing my job, my message back to you | |
1461 | will say what you have to fix in order to make the change acceptable. | |
1462 | The reason to have separate messages for separate features is so | |
1463 | that other changes (which I @emph{am} willing to accept) can be installed | |
1464 | while one or more changes are being reworked. If multiple features | |
1465 | are sent in a single message, I tend to not put in the effort to sort | |
1466 | out the acceptable changes from the unacceptable, so none of the | |
1467 | features get installed until all are acceptable. | |
1468 | ||
1469 | If this sounds painful or authoritarian, well, it is. But I get a lot | |
1470 | of bug reports and a lot of patches, and most of them don't get | |
1471 | installed because I don't have the time to finish the job that the bug | |
1472 | reporter or the contributor could have done. Patches that arrive | |
1473 | complete, working, and well designed, tend to get installed on the day | |
1474 | they arrive. The others go into a queue and get installed if and when | |
1475 | I scan back over the queue -- which can literally take months | |
1476 | sometimes. It's in both our interests to make patch installation easy | |
1477 | -- you get your changes installed, and I make some forward progress on | |
1478 | GDB in a normal 12-hour day (instead of them having to wait until I | |
1479 | have a 14-hour or 16-hour day to spend cleaning up patches before I | |
1480 | can install them). | |
1481 | ||
a5e7f259 JK |
1482 | Please send patches to @code{bug-gdb@@prep.ai.mit.edu}, if they are less |
1483 | than about 25,000 characters. If longer than that, either make them | |
1484 | available somehow (e.g. anonymous FTP), and announce it on | |
1485 | @code{bug-gdb}, or send them directly to the GDB maintainers at | |
1486 | @code{gdb-patches@@cygnus.com}. | |
1487 | ||
b517f124 | 1488 | @node Host Conditionals |
493cf018 JG |
1489 | @chapter Host Conditionals |
1490 | ||
1491 | When GDB is configured and compiled, various macros are defined or left | |
1492 | undefined, to control compilation based on the attributes of the host | |
1493 | system. These macros and their meanings are: | |
1494 | ||
1495 | @emph{NOTE: For now, both host and target conditionals are here. | |
1496 | Eliminate target conditionals from this list as they are identified.} | |
1497 | ||
1498 | @table @code | |
1499 | @item ALIGN_SIZE | |
1500 | alloca.c | |
1501 | @item BLOCK_ADDRESS_FUNCTION_RELATIVE | |
1502 | dbxread.c | |
1503 | @item GDBINIT_FILENAME | |
1504 | main.c | |
1505 | @item KERNELDEBUG | |
1506 | tm-hppa.h | |
1507 | @item MEM_FNS_DECLARED | |
00db1549 JG |
1508 | Your host config file defines this if it includes |
1509 | declarations of @code{memcpy} and @code{memset}. Define this | |
1510 | to avoid conflicts between the native include | |
1511 | files and the declarations in @file{defs.h}. | |
493cf018 JG |
1512 | @item NO_SYS_FILE |
1513 | dbxread.c | |
493cf018 JG |
1514 | @item PYRAMID_CONTROL_FRAME_DEBUGGING |
1515 | pyr-xdep.c | |
1516 | @item SIGWINCH_HANDLER_BODY | |
1517 | utils.c | |
1518 | @item 1 | |
1519 | buildsym.c | |
1520 | @item 1 | |
1521 | dbxread.c | |
1522 | @item 1 | |
1523 | dbxread.c | |
1524 | @item 1 | |
1525 | buildsym.c | |
1526 | @item 1 | |
1527 | dwarfread.c | |
1528 | @item 1 | |
1529 | valops.c | |
1530 | @item 1 | |
1531 | valops.c | |
1532 | @item 1 | |
1533 | pyr-xdep.c | |
1534 | @item ADDITIONAL_OPTIONS | |
1535 | main.c | |
1536 | @item ADDITIONAL_OPTION_CASES | |
1537 | main.c | |
1538 | @item ADDITIONAL_OPTION_HANDLER | |
1539 | main.c | |
1540 | @item ADDITIONAL_OPTION_HELP | |
1541 | main.c | |
1542 | @item ADDR_BITS_REMOVE | |
1543 | defs.h | |
1544 | @item AIX_BUGGY_PTRACE_CONTINUE | |
1545 | infptrace.c | |
1546 | @item ALIGN_STACK_ON_STARTUP | |
1547 | main.c | |
1548 | @item ALTOS | |
1549 | altos-xdep.c | |
1550 | @item ALTOS_AS | |
1551 | xm-altos.h | |
1552 | @item ASCII_COFF | |
1553 | remote-adapt.c | |
493cf018 JG |
1554 | @item BADMAG |
1555 | coffread.c | |
1556 | @item BCS | |
1557 | tm-delta88.h | |
1558 | @item BEFORE_MAIN_LOOP_HOOK | |
1559 | main.c | |
1560 | @item BELIEVE_PCC_PROMOTION | |
1561 | coffread.c | |
1562 | @item BELIEVE_PCC_PROMOTION_TYPE | |
1563 | stabsread.c | |
1564 | @item BIG_ENDIAN | |
1565 | defs.h | |
1566 | @item BITS_BIG_ENDIAN | |
1567 | defs.h | |
1568 | @item BKPT_AT_MAIN | |
1569 | solib.c | |
1570 | @item BLOCK_ADDRESS_ABSOLUTE | |
1571 | dbxread.c | |
1572 | @item BPT_VECTOR | |
3a8bc841 | 1573 | tm-m68k.h |
493cf018 | 1574 | @item BREAKPOINT |
3a8bc841 | 1575 | tm-m68k.h |
493cf018 JG |
1576 | @item BREAKPOINT_DEBUG |
1577 | breakpoint.c | |
1578 | @item BROKEN_LARGE_ALLOCA | |
968720bf RP |
1579 | Avoid large @code{alloca}'s. For example, on sun's, Large alloca's fail |
1580 | because the attempt to increase the stack limit in main() fails because | |
1581 | shared libraries are allocated just below the initial stack limit. The | |
1582 | SunOS kernel will not allow the stack to grow into the area occupied by | |
1583 | the shared libraries. | |
493cf018 JG |
1584 | @item BSTRING |
1585 | regex.c | |
1586 | @item CALL_DUMMY | |
1587 | valops.c | |
1588 | @item CALL_DUMMY_LOCATION | |
1589 | inferior.h | |
1590 | @item CALL_DUMMY_STACK_ADJUST | |
1591 | valops.c | |
1592 | @item CANNOT_FETCH_REGISTER | |
1593 | hppabsd-xdep.c | |
1594 | @item CANNOT_STORE_REGISTER | |
1595 | findvar.c | |
1596 | @item CFRONT_PRODUCER | |
1597 | dwarfread.c | |
1598 | @item CHILD_PREPARE_TO_STORE | |
1599 | inftarg.c | |
1600 | @item CLEAR_DEFERRED_STORES | |
1601 | inflow.c | |
1602 | @item CLEAR_SOLIB | |
1603 | objfiles.c | |
1604 | @item COFF_ENCAPSULATE | |
1605 | hppabsd-tdep.c | |
1606 | @item COFF_FORMAT | |
1607 | symm-tdep.c | |
493cf018 JG |
1608 | @item CORE_NEEDS_RELOCATION |
1609 | stack.c | |
1610 | @item CPLUS_MARKER | |
1611 | cplus-dem.c | |
1612 | @item CREATE_INFERIOR_HOOK | |
1613 | infrun.c | |
1614 | @item C_ALLOCA | |
1615 | regex.c | |
1616 | @item C_GLBLREG | |
1617 | coffread.c | |
493cf018 JG |
1618 | @item DBXREAD_ONLY |
1619 | partial-stab.h | |
1620 | @item DBX_PARM_SYMBOL_CLASS | |
1621 | stabsread.c | |
1622 | @item DEBUG | |
1623 | remote-adapt.c | |
1624 | @item DEBUG_INFO | |
1625 | partial-stab.h | |
1626 | @item DEBUG_PTRACE | |
1627 | hppabsd-xdep.c | |
1628 | @item DECR_PC_AFTER_BREAK | |
1629 | breakpoint.c | |
1630 | @item DEFAULT_PROMPT | |
1631 | main.c | |
1632 | @item DELTA88 | |
1633 | m88k-xdep.c | |
1634 | @item DEV_TTY | |
1635 | symmisc.c | |
1636 | @item DGUX | |
1637 | m88k-xdep.c | |
1638 | @item DISABLE_UNSETTABLE_BREAK | |
1639 | breakpoint.c | |
1640 | @item DONT_USE_REMOTE | |
1641 | remote.c | |
1642 | @item DO_DEFERRED_STORES | |
1643 | infrun.c | |
1644 | @item DO_REGISTERS_INFO | |
1645 | infcmd.c | |
1646 | @item END_OF_TEXT_DEFAULT | |
1647 | dbxread.c | |
1648 | @item EXTERN | |
1649 | buildsym.h | |
1650 | @item EXTRACT_RETURN_VALUE | |
3a8bc841 | 1651 | tm-m68k.h |
493cf018 JG |
1652 | @item EXTRACT_STRUCT_VALUE_ADDRESS |
1653 | values.c | |
1654 | @item EXTRA_FRAME_INFO | |
1655 | frame.h | |
1656 | @item EXTRA_SYMTAB_INFO | |
1657 | symtab.h | |
493cf018 JG |
1658 | @item FILES_INFO_HOOK |
1659 | target.c | |
1660 | @item FIXME | |
1661 | coffread.c | |
1662 | @item FLOAT_INFO | |
1663 | infcmd.c | |
1664 | @item FOPEN_RB | |
1665 | defs.h | |
1666 | @item FP0_REGNUM | |
1667 | a68v-xdep.c | |
1668 | @item FPC_REGNUM | |
1669 | mach386-xdep.c | |
1670 | @item FP_REGNUM | |
1671 | parse.c | |
1672 | @item FRAMELESS_FUNCTION_INVOCATION | |
1673 | blockframe.c | |
1674 | @item FRAME_ARGS_ADDRESS_CORRECT | |
1675 | stack.c | |
1676 | @item FRAME_CHAIN_COMBINE | |
1677 | blockframe.c | |
1678 | @item FRAME_CHAIN_VALID | |
1679 | frame.h | |
1680 | @item FRAME_CHAIN_VALID_ALTERNATE | |
1681 | frame.h | |
1682 | @item FRAME_FIND_SAVED_REGS | |
1683 | stack.c | |
1684 | @item FRAME_GET_BASEREG_VALUE | |
1685 | frame.h | |
1686 | @item FRAME_NUM_ARGS | |
3a8bc841 | 1687 | tm-m68k.h |
493cf018 JG |
1688 | @item FRAME_SPECIFICATION_DYADIC |
1689 | stack.c | |
1690 | @item FUNCTION_EPILOGUE_SIZE | |
1691 | coffread.c | |
1692 | @item F_OK | |
1693 | xm-ultra3.h | |
1694 | @item GCC2_COMPILED_FLAG_SYMBOL | |
1695 | dbxread.c | |
1696 | @item GCC_COMPILED_FLAG_SYMBOL | |
1697 | dbxread.c | |
1698 | @item GCC_MANGLE_BUG | |
1699 | symtab.c | |
1700 | @item GCC_PRODUCER | |
1701 | dwarfread.c | |
493cf018 JG |
1702 | @item GET_SAVED_REGISTER |
1703 | findvar.c | |
1704 | @item GPLUS_PRODUCER | |
1705 | dwarfread.c | |
1706 | @item GR64_REGNUM | |
1707 | remote-adapt.c | |
1708 | @item GR64_REGNUM | |
1709 | remote-mm.c | |
1710 | @item HANDLE_RBRAC | |
1711 | partial-stab.h | |
1712 | @item HAVE_68881 | |
1713 | m68k-tdep.c | |
1714 | @item HAVE_MMAP | |
968720bf RP |
1715 | In some cases, use the system call @code{mmap} for reading symbol |
1716 | tables. For some machines this allows for sharing and quick updates. | |
493cf018 JG |
1717 | @item HAVE_REGISTER_WINDOWS |
1718 | findvar.c | |
1719 | @item HAVE_SIGSETMASK | |
1720 | main.c | |
1721 | @item HAVE_TERMIO | |
1722 | inflow.c | |
1723 | @item HEADER_SEEK_FD | |
1724 | arm-tdep.c | |
1725 | @item HOSTING_ONLY | |
1726 | xm-rtbsd.h | |
1727 | @item HOST_BYTE_ORDER | |
1728 | ieee-float.c | |
1729 | @item HPUX_ASM | |
1730 | xm-hp300hpux.h | |
1731 | @item HPUX_VERSION_5 | |
1732 | hp300ux-xdep.c | |
1733 | @item HP_OS_BUG | |
1734 | infrun.c | |
1735 | @item I80960 | |
1736 | remote-vx.c | |
493cf018 JG |
1737 | @item IEEE_DEBUG |
1738 | ieee-float.c | |
1739 | @item IEEE_FLOAT | |
1740 | valprint.c | |
1741 | @item IGNORE_SYMBOL | |
1742 | dbxread.c | |
1743 | @item INIT_EXTRA_FRAME_INFO | |
1744 | blockframe.c | |
1745 | @item INIT_EXTRA_SYMTAB_INFO | |
1746 | symfile.c | |
1747 | @item INIT_FRAME_PC | |
1748 | blockframe.c | |
1749 | @item INNER_THAN | |
1750 | valops.c | |
1751 | @item INT_MAX | |
1752 | defs.h | |
1753 | @item INT_MIN | |
1754 | defs.h | |
1755 | @item IN_GDB | |
1756 | i960-pinsn.c | |
1757 | @item IN_SIGTRAMP | |
1758 | infrun.c | |
1759 | @item IN_SOLIB_TRAMPOLINE | |
1760 | infrun.c | |
1761 | @item ISATTY | |
1762 | main.c | |
1763 | @item IS_TRAPPED_INTERNALVAR | |
1764 | values.c | |
1765 | @item KERNELDEBUG | |
1766 | dbxread.c | |
1767 | @item KERNEL_DEBUGGING | |
1768 | tm-ultra3.h | |
1769 | @item KERNEL_U_ADDR | |
1770 | Define this to the address of the @code{u} structure (the ``user struct'', | |
1771 | also known as the ``u-page'') in kernel virtual memory. GDB needs to know | |
1772 | this so that it can subtract this address from absolute addresses in | |
1773 | the upage, that are obtained via ptrace or from core files. On systems | |
1774 | that don't need this value, set it to zero. | |
1775 | @item KERNEL_U_ADDR_BSD | |
1776 | Define this to cause GDB to determine the address of @code{u} at runtime, | |
1777 | by using Berkeley-style @code{nlist} on the kernel's image in the root | |
1778 | directory. | |
1779 | @item KERNEL_U_ADDR_HPUX | |
1780 | Define this to cause GDB to determine the address of @code{u} at runtime, | |
1781 | by using HP-style @code{nlist} on the kernel's image in the root | |
1782 | directory. | |
1783 | @item LCC_PRODUCER | |
1784 | dwarfread.c | |
1785 | @item LITTLE_ENDIAN | |
1786 | defs.h | |
1787 | @item LOG_FILE | |
1788 | remote-adapt.c | |
1789 | @item LONGERNAMES | |
1790 | cplus-dem.c | |
1791 | @item LONGEST | |
1792 | defs.h | |
238ffce0 JG |
1793 | @item CC_HAS_LONG_LONG |
1794 | defs.h | |
1795 | @item PRINTF_HAS_LONG_LONG | |
493cf018 JG |
1796 | defs.h |
1797 | @item LONG_MAX | |
1798 | defs.h | |
1799 | @item LSEEK_NOT_LINEAR | |
1800 | source.c | |
1801 | @item L_LNNO32 | |
1802 | coffread.c | |
1803 | @item L_SET | |
c3bbca3a JG |
1804 | This macro is used as the argument to lseek (or, most commonly, bfd_seek). |
1805 | FIXME, it should be replaced by SEEK_SET instead, which is the POSIX equivalent. | |
493cf018 JG |
1806 | @item MACHKERNELDEBUG |
1807 | hppabsd-tdep.c | |
1808 | @item MAIN | |
1809 | cplus-dem.c | |
1810 | @item MAINTENANCE | |
1811 | dwarfread.c | |
1812 | @item MAINTENANCE_CMDS | |
1813 | breakpoint.c | |
1814 | @item MAINTENANCE_CMDS | |
1815 | maint.c | |
1816 | @item MALLOC_INCOMPATIBLE | |
968720bf RP |
1817 | Define this if the system's prototype for @code{malloc} differs from the |
1818 | @sc{ANSI} definition. | |
493cf018 JG |
1819 | @item MIPSEL |
1820 | mips-tdep.c | |
1821 | @item MMAP_BASE_ADDRESS | |
968720bf RP |
1822 | When using HAVE_MMAP, the first mapping should go at this address. |
1823 | @item MMAP_INCREMENT | |
1824 | when using HAVE_MMAP, this is the increment between mappings. | |
493cf018 JG |
1825 | @item MONO |
1826 | ser-go32.c | |
1827 | @item MOTOROLA | |
1828 | xm-altos.h | |
493cf018 JG |
1829 | @item NBPG |
1830 | altos-xdep.c | |
1831 | @item NEED_POSIX_SETPGID | |
1832 | infrun.c | |
1833 | @item NEED_TEXT_START_END | |
1834 | exec.c | |
1835 | @item NFAILURES | |
1836 | regex.c | |
1837 | @item NNPC_REGNUM | |
1838 | infrun.c | |
1839 | @item NORETURN | |
1840 | defs.h | |
1841 | @item NOTDEF | |
1842 | regex.c | |
1843 | @item NOTDEF | |
1844 | remote-adapt.c | |
1845 | @item NOTDEF | |
1846 | remote-mm.c | |
1847 | @item NOTICE_SIGNAL_HANDLING_CHANGE | |
1848 | infrun.c | |
493cf018 JG |
1849 | @item NO_HIF_SUPPORT |
1850 | remote-mm.c | |
1851 | @item NO_JOB_CONTROL | |
1852 | signals.h | |
493cf018 | 1853 | @item NO_MMALLOC |
d7d35f00 FF |
1854 | GDB will use the @code{mmalloc} library for memory allocation for symbol |
1855 | reading, unless this symbol is defined. Define it on systems | |
1856 | on which @code{mmalloc} does not | |
1857 | work for some reason. One example is the DECstation, where its RPC | |
1858 | library can't cope with our redefinition of @code{malloc} to call | |
1859 | @code{mmalloc}. When defining @code{NO_MMALLOC}, you will also have | |
1860 | to override the setting of @code{MMALLOC_LIB} to empty, in the Makefile. | |
1861 | Therefore, this define is usually set on the command line by overriding | |
3a8bc841 | 1862 | @code{MMALLOC_DISABLE} in @file{config/*/*.mh}, rather than by defining |
d7d35f00 FF |
1863 | it in @file{xm-*.h}. |
1864 | @item NO_MMALLOC_CHECK | |
1865 | Define this if you are using @code{mmalloc}, but don't want the overhead | |
1866 | of checking the heap with @code{mmcheck}. | |
493cf018 JG |
1867 | @item NO_SIGINTERRUPT |
1868 | remote-adapt.c | |
1869 | @item NO_SINGLE_STEP | |
1870 | infptrace.c | |
493cf018 JG |
1871 | @item NPC_REGNUM |
1872 | infcmd.c | |
1873 | @item NS32K_SVC_IMMED_OPERANDS | |
1874 | ns32k-opcode.h | |
1875 | @item NUMERIC_REG_NAMES | |
1876 | mips-tdep.c | |
1877 | @item N_SETV | |
1878 | dbxread.c | |
1879 | @item N_SET_MAGIC | |
1880 | hppabsd-tdep.c | |
1881 | @item NaN | |
1882 | tm-umax.h | |
1883 | @item ONE_PROCESS_WRITETEXT | |
1884 | breakpoint.c | |
1885 | @item O_BINARY | |
1886 | exec.c | |
1887 | @item O_RDONLY | |
1888 | xm-ultra3.h | |
1889 | @item PC | |
1890 | convx-opcode.h | |
1891 | @item PCC_SOL_BROKEN | |
1892 | dbxread.c | |
1893 | @item PC_IN_CALL_DUMMY | |
1894 | inferior.h | |
1895 | @item PC_LOAD_SEGMENT | |
1896 | stack.c | |
1897 | @item PC_REGNUM | |
1898 | parse.c | |
1899 | @item PRINT_RANDOM_SIGNAL | |
1900 | infcmd.c | |
1901 | @item PRINT_REGISTER_HOOK | |
1902 | infcmd.c | |
1903 | @item PRINT_TYPELESS_INTEGER | |
1904 | valprint.c | |
1905 | @item PROCESS_LINENUMBER_HOOK | |
1906 | buildsym.c | |
1907 | @item PROLOGUE_FIRSTLINE_OVERLAP | |
1908 | infrun.c | |
1909 | @item PSIGNAL_IN_SIGNAL_H | |
1910 | defs.h | |
1911 | @item PS_REGNUM | |
1912 | parse.c | |
493cf018 JG |
1913 | @item PUSH_ARGUMENTS |
1914 | valops.c | |
1915 | @item PYRAMID_CONTROL_FRAME_DEBUGGING | |
1916 | pyr-xdep.c | |
1917 | @item PYRAMID_CORE | |
1918 | pyr-xdep.c | |
1919 | @item PYRAMID_PTRACE | |
1920 | pyr-xdep.c | |
1921 | @item REGISTER_BYTES | |
1922 | remote.c | |
1923 | @item REGISTER_NAMES | |
d7d35f00 | 1924 | tm-a29k.h |
493cf018 JG |
1925 | @item REG_STACK_SEGMENT |
1926 | exec.c | |
1927 | @item REG_STRUCT_HAS_ADDR | |
1928 | findvar.c | |
1929 | @item RE_NREGS | |
1930 | regex.h | |
1931 | @item R_FP | |
1932 | dwarfread.c | |
1933 | @item R_OK | |
1934 | xm-altos.h | |
1935 | @item SDB_REG_TO_REGNUM | |
1936 | coffread.c | |
1937 | @item SEEK_END | |
1938 | state.c | |
1939 | @item SEEK_SET | |
1940 | state.c | |
1941 | @item SEM | |
1942 | coffread.c | |
1943 | @item SET_STACK_LIMIT_HUGE | |
968720bf RP |
1944 | When defined, stack limits will be raised to their maximum. Use this |
1945 | if your host supports @code{setrlimit} and you have trouble with | |
1946 | @code{stringtab} in @file{dbxread.c}. | |
1947 | ||
1948 | Also used in @file{fork-child.c} to return stack limits before child | |
1949 | processes are forked. | |
493cf018 JG |
1950 | @item SHELL_COMMAND_CONCAT |
1951 | infrun.c | |
1952 | @item SHELL_FILE | |
1953 | infrun.c | |
1954 | @item SHIFT_INST_REGS | |
1955 | breakpoint.c | |
1956 | @item SIGN_EXTEND_CHAR | |
1957 | regex.c | |
1958 | @item SIGTRAP_STOP_AFTER_LOAD | |
1959 | infrun.c | |
1960 | @item SKIP_PROLOGUE | |
3a8bc841 | 1961 | tm-m68k.h |
493cf018 JG |
1962 | @item SKIP_PROLOGUE_FRAMELESS_P |
1963 | blockframe.c | |
1964 | @item SKIP_TRAMPOLINE_CODE | |
1965 | infrun.c | |
1966 | @item SOLIB_ADD | |
1967 | core.c | |
1968 | @item SOLIB_CREATE_INFERIOR_HOOK | |
1969 | infrun.c | |
493cf018 JG |
1970 | @item SP_REGNUM |
1971 | parse.c | |
1972 | @item STAB_REG_TO_REGNUM | |
1973 | stabsread.h | |
1974 | @item STACK_ALIGN | |
1975 | valops.c | |
1976 | @item STACK_DIRECTION | |
1977 | alloca.c | |
1978 | @item START_INFERIOR_TRAPS_EXPECTED | |
1979 | infrun.c | |
1980 | @item STOP_SIGNAL | |
1981 | main.c | |
1982 | @item STORE_RETURN_VALUE | |
3a8bc841 | 1983 | tm-m68k.h |
493cf018 JG |
1984 | @item SUN4_COMPILER_FEATURE |
1985 | infrun.c | |
1986 | @item SUN_FIXED_LBRAC_BUG | |
1987 | dbxread.c | |
1988 | @item SVR4_SHARED_LIBS | |
1989 | solib.c | |
1990 | @item SWITCH_ENUM_BUG | |
1991 | regex.c | |
1992 | @item SYM1 | |
1993 | tm-ultra3.h | |
1994 | @item SYMBOL_RELOADING_DEFAULT | |
1995 | symfile.c | |
1996 | @item SYNTAX_TABLE | |
1997 | regex.c | |
1998 | @item Sword | |
1999 | regex.c | |
2000 | @item TDESC | |
2001 | infrun.c | |
2002 | @item TIOCGETC | |
2003 | inflow.c | |
2004 | @item TIOCGLTC | |
2005 | inflow.c | |
2006 | @item TIOCGPGRP | |
2007 | inflow.c | |
2008 | @item TIOCLGET | |
2009 | inflow.c | |
2010 | @item TIOCLSET | |
2011 | inflow.c | |
2012 | @item TIOCNOTTY | |
2013 | inflow.c | |
493cf018 JG |
2014 | @item T_ARG |
2015 | coffread.c | |
2016 | @item T_VOID | |
2017 | coffread.c | |
2018 | @item UINT_MAX | |
2019 | defs.h | |
2020 | @item UPAGES | |
2021 | altos-xdep.c | |
2022 | @item USER | |
2023 | m88k-tdep.c | |
2024 | @item USE_GAS | |
2025 | xm-news.h | |
2026 | @item USE_O_NOCTTY | |
2027 | inflow.c | |
493cf018 JG |
2028 | @item USE_STRUCT_CONVENTION |
2029 | values.c | |
2030 | @item USG | |
2031 | Means that System V (prior to SVR4) include files are in use. | |
2032 | (FIXME: This symbol is abused in @file{infrun.c}, @file{regex.c}, | |
2033 | @file{remote-nindy.c}, and @file{utils.c} for other things, at the moment.) | |
2034 | @item USIZE | |
2035 | xm-m88k.h | |
2036 | @item U_FPSTATE | |
2037 | i386-xdep.c | |
493cf018 JG |
2038 | @item VARIABLES_INSIDE_BLOCK |
2039 | dbxread.c | |
2040 | @item WRS_ORIG | |
2041 | remote-vx.c | |
2042 | @item _LANG_c | |
2043 | language.c | |
2044 | @item _LANG_m2 | |
2045 | language.c | |
2046 | @item __GNUC__ | |
2047 | news-xdep.c | |
2048 | @item __GO32__ | |
2049 | inflow.c | |
2050 | @item __HAVE_68881__ | |
2051 | m68k-stub.c | |
2052 | @item __HPUX_ASM__ | |
2053 | xm-hp300hpux.h | |
2054 | @item __INT_VARARGS_H | |
2055 | printcmd.c | |
2056 | @item __not_on_pyr_yet | |
2057 | pyr-xdep.c | |
2058 | @item alloca | |
2059 | defs.h | |
2060 | @item const | |
2061 | defs.h | |
2062 | @item GOULD_PN | |
2063 | gould-pinsn.c | |
2064 | @item emacs | |
2065 | alloca.c | |
2066 | @item hp800 | |
2067 | xm-hppabsd.h | |
493cf018 JG |
2068 | @item hpux |
2069 | hppabsd-core.c | |
2070 | @item lint | |
2071 | valarith.c | |
2072 | @item longest_to_int | |
2073 | defs.h | |
2074 | @item mc68020 | |
2075 | m68k-stub.c | |
2076 | @item notdef | |
2077 | gould-pinsn.c | |
2078 | @item ns32k_opcodeT | |
2079 | ns32k-opcode.h | |
2080 | @item sgi | |
2081 | mips-tdep.c | |
2082 | @item sparc | |
2083 | regex.c | |
2084 | @item static | |
2085 | alloca.c | |
2086 | @item sun | |
2087 | m68k-tdep.c | |
2088 | @item sun386 | |
2089 | tm-sun386.h | |
2090 | @item test | |
2091 | regex.c | |
2092 | @item ultrix | |
2093 | xm-mips.h | |
2094 | @item volatile | |
2095 | defs.h | |
2096 | @item x_name | |
2097 | coffread.c | |
2098 | @item x_zeroes | |
2099 | coffread.c | |
2100 | @end table | |
2101 | ||
b517f124 | 2102 | @node Target Conditionals |
493cf018 JG |
2103 | @chapter Target Conditionals |
2104 | ||
2105 | When GDB is configured and compiled, various macros are defined or left | |
2106 | undefined, to control compilation based on the attributes of the target | |
2107 | system. These macros and their meanings are: | |
2108 | ||
2109 | @emph{NOTE: For now, both host and target conditionals are here. | |
2110 | Eliminate host conditionals from this list as they are identified.} | |
2111 | ||
2112 | @table @code | |
ca048722 RP |
2113 | @item PUSH_DUMMY_FRAME |
2114 | Used in @samp{call_function_by_hand} to create an artificial stack frame. | |
2115 | @item POP_FRAME | |
2116 | Used in @samp{call_function_by_hand} to remove an artificial stack frame. | |
493cf018 JG |
2117 | @item ALIGN_SIZE |
2118 | alloca.c | |
2119 | @item BLOCK_ADDRESS_FUNCTION_RELATIVE | |
2120 | dbxread.c | |
2121 | @item GDBINIT_FILENAME | |
2122 | main.c | |
2123 | @item KERNELDEBUG | |
2124 | tm-hppa.h | |
493cf018 JG |
2125 | @item NO_SYS_FILE |
2126 | dbxread.c | |
493cf018 JG |
2127 | @item PYRAMID_CONTROL_FRAME_DEBUGGING |
2128 | pyr-xdep.c | |
2129 | @item SIGWINCH_HANDLER_BODY | |
2130 | utils.c | |
2131 | @item ADDITIONAL_OPTIONS | |
2132 | main.c | |
2133 | @item ADDITIONAL_OPTION_CASES | |
2134 | main.c | |
2135 | @item ADDITIONAL_OPTION_HANDLER | |
2136 | main.c | |
2137 | @item ADDITIONAL_OPTION_HELP | |
2138 | main.c | |
2139 | @item ADDR_BITS_REMOVE | |
2140 | defs.h | |
2141 | @item ALIGN_STACK_ON_STARTUP | |
2142 | main.c | |
2143 | @item ALTOS | |
2144 | altos-xdep.c | |
2145 | @item ALTOS_AS | |
2146 | xm-altos.h | |
2147 | @item ASCII_COFF | |
2148 | remote-adapt.c | |
493cf018 JG |
2149 | @item BADMAG |
2150 | coffread.c | |
2151 | @item BCS | |
2152 | tm-delta88.h | |
2153 | @item BEFORE_MAIN_LOOP_HOOK | |
2154 | main.c | |
2155 | @item BELIEVE_PCC_PROMOTION | |
2156 | coffread.c | |
2157 | @item BELIEVE_PCC_PROMOTION_TYPE | |
2158 | stabsread.c | |
2159 | @item BIG_ENDIAN | |
2160 | defs.h | |
2161 | @item BITS_BIG_ENDIAN | |
2162 | defs.h | |
2163 | @item BKPT_AT_MAIN | |
2164 | solib.c | |
2165 | @item BLOCK_ADDRESS_ABSOLUTE | |
2166 | dbxread.c | |
2167 | @item BPT_VECTOR | |
3a8bc841 | 2168 | tm-m68k.h |
493cf018 | 2169 | @item BREAKPOINT |
3a8bc841 | 2170 | tm-m68k.h |
493cf018 JG |
2171 | @item BREAKPOINT_DEBUG |
2172 | breakpoint.c | |
493cf018 JG |
2173 | @item BSTRING |
2174 | regex.c | |
2175 | @item CALL_DUMMY | |
2176 | valops.c | |
2177 | @item CALL_DUMMY_LOCATION | |
2178 | inferior.h | |
2179 | @item CALL_DUMMY_STACK_ADJUST | |
2180 | valops.c | |
2181 | @item CANNOT_FETCH_REGISTER | |
2182 | hppabsd-xdep.c | |
2183 | @item CANNOT_STORE_REGISTER | |
2184 | findvar.c | |
2185 | @item CFRONT_PRODUCER | |
2186 | dwarfread.c | |
2187 | @item CHILD_PREPARE_TO_STORE | |
2188 | inftarg.c | |
2189 | @item CLEAR_DEFERRED_STORES | |
2190 | inflow.c | |
2191 | @item CLEAR_SOLIB | |
2192 | objfiles.c | |
2193 | @item COFF_ENCAPSULATE | |
2194 | hppabsd-tdep.c | |
2195 | @item COFF_FORMAT | |
2196 | symm-tdep.c | |
493cf018 JG |
2197 | @item CORE_NEEDS_RELOCATION |
2198 | stack.c | |
2199 | @item CPLUS_MARKER | |
2200 | cplus-dem.c | |
2201 | @item CREATE_INFERIOR_HOOK | |
2202 | infrun.c | |
2203 | @item C_ALLOCA | |
2204 | regex.c | |
2205 | @item C_GLBLREG | |
2206 | coffread.c | |
493cf018 JG |
2207 | @item DBXREAD_ONLY |
2208 | partial-stab.h | |
2209 | @item DBX_PARM_SYMBOL_CLASS | |
2210 | stabsread.c | |
2211 | @item DEBUG | |
2212 | remote-adapt.c | |
2213 | @item DEBUG_INFO | |
2214 | partial-stab.h | |
2215 | @item DEBUG_PTRACE | |
2216 | hppabsd-xdep.c | |
2217 | @item DECR_PC_AFTER_BREAK | |
2218 | breakpoint.c | |
2219 | @item DEFAULT_PROMPT | |
2220 | main.c | |
2221 | @item DELTA88 | |
2222 | m88k-xdep.c | |
2223 | @item DEV_TTY | |
2224 | symmisc.c | |
2225 | @item DGUX | |
2226 | m88k-xdep.c | |
2227 | @item DISABLE_UNSETTABLE_BREAK | |
2228 | breakpoint.c | |
2229 | @item DONT_USE_REMOTE | |
2230 | remote.c | |
2231 | @item DO_DEFERRED_STORES | |
2232 | infrun.c | |
2233 | @item DO_REGISTERS_INFO | |
2234 | infcmd.c | |
2235 | @item END_OF_TEXT_DEFAULT | |
2236 | dbxread.c | |
2237 | @item EXTERN | |
2238 | buildsym.h | |
2239 | @item EXTRACT_RETURN_VALUE | |
3a8bc841 | 2240 | tm-m68k.h |
493cf018 JG |
2241 | @item EXTRACT_STRUCT_VALUE_ADDRESS |
2242 | values.c | |
2243 | @item EXTRA_FRAME_INFO | |
2244 | frame.h | |
2245 | @item EXTRA_SYMTAB_INFO | |
2246 | symtab.h | |
2247 | @item FILES_INFO_HOOK | |
2248 | target.c | |
2249 | @item FIXME | |
2250 | coffread.c | |
2251 | @item FLOAT_INFO | |
2252 | infcmd.c | |
2253 | @item FOPEN_RB | |
2254 | defs.h | |
2255 | @item FP0_REGNUM | |
2256 | a68v-xdep.c | |
2257 | @item FPC_REGNUM | |
2258 | mach386-xdep.c | |
2259 | @item FP_REGNUM | |
2260 | parse.c | |
968720bf | 2261 | @item FPU |
1b87a1b2 | 2262 | Unused? 6-oct-92 rich@@cygnus.com. FIXME. |
493cf018 JG |
2263 | @item FRAMELESS_FUNCTION_INVOCATION |
2264 | blockframe.c | |
2265 | @item FRAME_ARGS_ADDRESS_CORRECT | |
2266 | stack.c | |
a5e7f259 JK |
2267 | @item FRAME_CHAIN |
2268 | Given FRAME, return a pointer to the calling frame. | |
493cf018 JG |
2269 | @item FRAME_CHAIN_COMBINE |
2270 | blockframe.c | |
2271 | @item FRAME_CHAIN_VALID | |
2272 | frame.h | |
2273 | @item FRAME_CHAIN_VALID_ALTERNATE | |
2274 | frame.h | |
2275 | @item FRAME_FIND_SAVED_REGS | |
2276 | stack.c | |
2277 | @item FRAME_GET_BASEREG_VALUE | |
2278 | frame.h | |
2279 | @item FRAME_NUM_ARGS | |
3a8bc841 | 2280 | tm-m68k.h |
493cf018 JG |
2281 | @item FRAME_SPECIFICATION_DYADIC |
2282 | stack.c | |
a5e7f259 JK |
2283 | @item FRAME_SAVED_PC |
2284 | Given FRAME, return the pc saved there. That is, the return address. | |
493cf018 JG |
2285 | @item FUNCTION_EPILOGUE_SIZE |
2286 | coffread.c | |
2287 | @item F_OK | |
2288 | xm-ultra3.h | |
2289 | @item GCC2_COMPILED_FLAG_SYMBOL | |
2290 | dbxread.c | |
2291 | @item GCC_COMPILED_FLAG_SYMBOL | |
2292 | dbxread.c | |
2293 | @item GCC_MANGLE_BUG | |
2294 | symtab.c | |
2295 | @item GCC_PRODUCER | |
2296 | dwarfread.c | |
968720bf RP |
2297 | @item GDB_TARGET_IS_HPPA |
2298 | This determines whether horrible kludge code in dbxread.c and partial-stab.h | |
2299 | is used to mangle multiple-symbol-table files from HPPA's. This should all | |
2300 | be ripped out, and a scheme like elfread.c used. | |
493cf018 JG |
2301 | @item GDB_TARGET_IS_MACH386 |
2302 | mach386-xdep.c | |
2303 | @item GDB_TARGET_IS_SUN3 | |
2304 | a68v-xdep.c | |
2305 | @item GDB_TARGET_IS_SUN386 | |
2306 | sun386-xdep.c | |
2307 | @item GET_LONGJMP_TARGET | |
c3bbca3a JG |
2308 | For most machines, this is a target-dependent parameter. On the DECstation |
2309 | and the Iris, this is a native-dependent parameter, since <setjmp.h> is | |
2310 | needed to define it. | |
2311 | ||
2312 | This macro determines the target PC address that longjmp() will jump | |
2313 | to, assuming that we have just stopped at a longjmp breakpoint. It | |
2314 | takes a CORE_ADDR * as argument, and stores the target PC value through | |
2315 | this pointer. It examines the current state of the machine as needed. | |
493cf018 JG |
2316 | @item GET_SAVED_REGISTER |
2317 | findvar.c | |
2318 | @item GPLUS_PRODUCER | |
2319 | dwarfread.c | |
2320 | @item GR64_REGNUM | |
2321 | remote-adapt.c | |
2322 | @item GR64_REGNUM | |
2323 | remote-mm.c | |
2324 | @item HANDLE_RBRAC | |
2325 | partial-stab.h | |
2326 | @item HAVE_68881 | |
2327 | m68k-tdep.c | |
493cf018 JG |
2328 | @item HAVE_REGISTER_WINDOWS |
2329 | findvar.c | |
2330 | @item HAVE_SIGSETMASK | |
2331 | main.c | |
2332 | @item HAVE_TERMIO | |
2333 | inflow.c | |
2334 | @item HEADER_SEEK_FD | |
2335 | arm-tdep.c | |
2336 | @item HOSTING_ONLY | |
2337 | xm-rtbsd.h | |
2338 | @item HOST_BYTE_ORDER | |
2339 | ieee-float.c | |
2340 | @item HPUX_ASM | |
2341 | xm-hp300hpux.h | |
2342 | @item HPUX_VERSION_5 | |
2343 | hp300ux-xdep.c | |
2344 | @item HP_OS_BUG | |
2345 | infrun.c | |
2346 | @item I80960 | |
2347 | remote-vx.c | |
493cf018 | 2348 | @item IBM6000_TARGET |
d3d6d0ff JG |
2349 | Shows that we are configured for an IBM RS/6000 target. This conditional |
2350 | should be eliminated (FIXME) and replaced by feature-specific macros. | |
2351 | It was introduced in haste and we are repenting at leisure. | |
493cf018 JG |
2352 | @item IEEE_DEBUG |
2353 | ieee-float.c | |
2354 | @item IEEE_FLOAT | |
2355 | valprint.c | |
2356 | @item IGNORE_SYMBOL | |
2357 | dbxread.c | |
2358 | @item INIT_EXTRA_FRAME_INFO | |
2359 | blockframe.c | |
2360 | @item INIT_EXTRA_SYMTAB_INFO | |
2361 | symfile.c | |
2362 | @item INIT_FRAME_PC | |
2363 | blockframe.c | |
2364 | @item INNER_THAN | |
2365 | valops.c | |
2366 | @item INT_MAX | |
2367 | defs.h | |
2368 | @item INT_MIN | |
2369 | defs.h | |
2370 | @item IN_GDB | |
2371 | i960-pinsn.c | |
2372 | @item IN_SIGTRAMP | |
2373 | infrun.c | |
2374 | @item IN_SOLIB_TRAMPOLINE | |
2375 | infrun.c | |
2376 | @item ISATTY | |
2377 | main.c | |
2378 | @item IS_TRAPPED_INTERNALVAR | |
2379 | values.c | |
2380 | @item KERNELDEBUG | |
2381 | dbxread.c | |
2382 | @item KERNEL_DEBUGGING | |
2383 | tm-ultra3.h | |
2384 | @item LCC_PRODUCER | |
2385 | dwarfread.c | |
2386 | @item LITTLE_ENDIAN | |
2387 | defs.h | |
2388 | @item LOG_FILE | |
2389 | remote-adapt.c | |
2390 | @item LONGERNAMES | |
2391 | cplus-dem.c | |
2392 | @item LONGEST | |
2393 | defs.h | |
238ffce0 JG |
2394 | @item CC_HAS_LONG_LONG |
2395 | defs.h | |
2396 | @item PRINTF_HAS_LONG_LONG | |
493cf018 JG |
2397 | defs.h |
2398 | @item LONG_MAX | |
2399 | defs.h | |
493cf018 JG |
2400 | @item L_LNNO32 |
2401 | coffread.c | |
493cf018 JG |
2402 | @item MACHKERNELDEBUG |
2403 | hppabsd-tdep.c | |
2404 | @item MAIN | |
2405 | cplus-dem.c | |
2406 | @item MAINTENANCE | |
2407 | dwarfread.c | |
2408 | @item MAINTENANCE_CMDS | |
2409 | breakpoint.c | |
2410 | @item MAINTENANCE_CMDS | |
2411 | maint.c | |
2412 | @item MIPSEL | |
2413 | mips-tdep.c | |
493cf018 JG |
2414 | @item MOTOROLA |
2415 | xm-altos.h | |
493cf018 JG |
2416 | @item NBPG |
2417 | altos-xdep.c | |
2418 | @item NEED_POSIX_SETPGID | |
2419 | infrun.c | |
2420 | @item NEED_TEXT_START_END | |
2421 | exec.c | |
2422 | @item NFAILURES | |
2423 | regex.c | |
2424 | @item NNPC_REGNUM | |
2425 | infrun.c | |
2426 | @item NORETURN | |
2427 | defs.h | |
2428 | @item NOTDEF | |
2429 | regex.c | |
2430 | @item NOTDEF | |
2431 | remote-adapt.c | |
2432 | @item NOTDEF | |
2433 | remote-mm.c | |
2434 | @item NOTICE_SIGNAL_HANDLING_CHANGE | |
2435 | infrun.c | |
493cf018 JG |
2436 | @item NO_HIF_SUPPORT |
2437 | remote-mm.c | |
493cf018 JG |
2438 | @item NO_SIGINTERRUPT |
2439 | remote-adapt.c | |
2440 | @item NO_SINGLE_STEP | |
2441 | infptrace.c | |
493cf018 JG |
2442 | @item NPC_REGNUM |
2443 | infcmd.c | |
2444 | @item NS32K_SVC_IMMED_OPERANDS | |
2445 | ns32k-opcode.h | |
2446 | @item NUMERIC_REG_NAMES | |
2447 | mips-tdep.c | |
2448 | @item N_SETV | |
2449 | dbxread.c | |
2450 | @item N_SET_MAGIC | |
2451 | hppabsd-tdep.c | |
2452 | @item NaN | |
2453 | tm-umax.h | |
2454 | @item ONE_PROCESS_WRITETEXT | |
2455 | breakpoint.c | |
2456 | @item PC | |
2457 | convx-opcode.h | |
2458 | @item PCC_SOL_BROKEN | |
2459 | dbxread.c | |
2460 | @item PC_IN_CALL_DUMMY | |
2461 | inferior.h | |
2462 | @item PC_LOAD_SEGMENT | |
2463 | stack.c | |
2464 | @item PC_REGNUM | |
2465 | parse.c | |
2466 | @item PRINT_RANDOM_SIGNAL | |
2467 | infcmd.c | |
2468 | @item PRINT_REGISTER_HOOK | |
2469 | infcmd.c | |
2470 | @item PRINT_TYPELESS_INTEGER | |
2471 | valprint.c | |
2472 | @item PROCESS_LINENUMBER_HOOK | |
2473 | buildsym.c | |
2474 | @item PROLOGUE_FIRSTLINE_OVERLAP | |
2475 | infrun.c | |
2476 | @item PSIGNAL_IN_SIGNAL_H | |
2477 | defs.h | |
2478 | @item PS_REGNUM | |
2479 | parse.c | |
493cf018 JG |
2480 | @item PUSH_ARGUMENTS |
2481 | valops.c | |
2482 | @item REGISTER_BYTES | |
2483 | remote.c | |
2484 | @item REGISTER_NAMES | |
d7d35f00 | 2485 | tm-a29k.h |
493cf018 JG |
2486 | @item REG_STACK_SEGMENT |
2487 | exec.c | |
2488 | @item REG_STRUCT_HAS_ADDR | |
2489 | findvar.c | |
2490 | @item RE_NREGS | |
2491 | regex.h | |
2492 | @item R_FP | |
2493 | dwarfread.c | |
2494 | @item R_OK | |
2495 | xm-altos.h | |
2496 | @item SDB_REG_TO_REGNUM | |
2497 | coffread.c | |
2498 | @item SEEK_END | |
2499 | state.c | |
2500 | @item SEEK_SET | |
2501 | state.c | |
2502 | @item SEM | |
2503 | coffread.c | |
493cf018 JG |
2504 | @item SHELL_COMMAND_CONCAT |
2505 | infrun.c | |
2506 | @item SHELL_FILE | |
2507 | infrun.c | |
2508 | @item SHIFT_INST_REGS | |
2509 | breakpoint.c | |
2510 | @item SIGN_EXTEND_CHAR | |
2511 | regex.c | |
2512 | @item SIGTRAP_STOP_AFTER_LOAD | |
2513 | infrun.c | |
2514 | @item SKIP_PROLOGUE | |
3a8bc841 | 2515 | tm-m68k.h |
493cf018 JG |
2516 | @item SKIP_PROLOGUE_FRAMELESS_P |
2517 | blockframe.c | |
2518 | @item SKIP_TRAMPOLINE_CODE | |
2519 | infrun.c | |
2520 | @item SOLIB_ADD | |
2521 | core.c | |
2522 | @item SOLIB_CREATE_INFERIOR_HOOK | |
2523 | infrun.c | |
493cf018 JG |
2524 | @item SP_REGNUM |
2525 | parse.c | |
2526 | @item STAB_REG_TO_REGNUM | |
2527 | stabsread.h | |
2528 | @item STACK_ALIGN | |
2529 | valops.c | |
2530 | @item STACK_DIRECTION | |
2531 | alloca.c | |
2532 | @item START_INFERIOR_TRAPS_EXPECTED | |
2533 | infrun.c | |
2534 | @item STOP_SIGNAL | |
2535 | main.c | |
2536 | @item STORE_RETURN_VALUE | |
3a8bc841 | 2537 | tm-m68k.h |
493cf018 JG |
2538 | @item SUN4_COMPILER_FEATURE |
2539 | infrun.c | |
2540 | @item SUN_FIXED_LBRAC_BUG | |
2541 | dbxread.c | |
2542 | @item SVR4_SHARED_LIBS | |
2543 | solib.c | |
2544 | @item SWITCH_ENUM_BUG | |
2545 | regex.c | |
2546 | @item SYM1 | |
2547 | tm-ultra3.h | |
2548 | @item SYMBOL_RELOADING_DEFAULT | |
2549 | symfile.c | |
2550 | @item SYNTAX_TABLE | |
2551 | regex.c | |
2552 | @item Sword | |
2553 | regex.c | |
2554 | @item TARGET_BYTE_ORDER | |
2555 | defs.h | |
2556 | @item TARGET_CHAR_BIT | |
2557 | defs.h | |
2558 | @item TARGET_COMPLEX_BIT | |
2559 | defs.h | |
2560 | @item TARGET_DOUBLE_BIT | |
2561 | defs.h | |
2562 | @item TARGET_DOUBLE_COMPLEX_BIT | |
2563 | defs.h | |
2564 | @item TARGET_FLOAT_BIT | |
2565 | defs.h | |
2566 | @item TARGET_INT_BIT | |
2567 | defs.h | |
2568 | @item TARGET_LONG_BIT | |
2569 | defs.h | |
2570 | @item TARGET_LONG_DOUBLE_BIT | |
2571 | defs.h | |
2572 | @item TARGET_LONG_LONG_BIT | |
2573 | defs.h | |
2574 | @item TARGET_PTR_BIT | |
2575 | defs.h | |
238ffce0 JG |
2576 | @item TARGET_READ_PC |
2577 | @item TARGET_WRITE_PC | |
2578 | @item TARGET_READ_SP | |
2579 | @item TARGET_WRITE_SP | |
2580 | @item TARGET_READ_FP | |
2581 | @item TARGET_WRITE_FP | |
2582 | These change the behavior of @code{read_pc}, @code{write_pc}, | |
2583 | @code{read_sp}, @code{write_sp}, @code{read_fp} and @code{write_fp}. | |
2584 | For most targets, these may be left undefined. GDB will call the | |
2585 | read and write register functions with the relevant @code{_REGNUM} argument. | |
2586 | ||
2587 | These macros are useful when a target keeps one of these registers in a | |
2588 | hard to get at place; for example, part in a segment register and part | |
2589 | in an ordinary register. | |
2590 | ||
493cf018 JG |
2591 | @item TARGET_SHORT_BIT |
2592 | defs.h | |
2593 | @item TDESC | |
2594 | infrun.c | |
493cf018 JG |
2595 | @item T_ARG |
2596 | coffread.c | |
2597 | @item T_VOID | |
2598 | coffread.c | |
2599 | @item UINT_MAX | |
2600 | defs.h | |
2601 | @item USER | |
2602 | m88k-tdep.c | |
2603 | @item USE_GAS | |
2604 | xm-news.h | |
2605 | @item USE_STRUCT_CONVENTION | |
2606 | values.c | |
2607 | @item USIZE | |
2608 | xm-m88k.h | |
2609 | @item U_FPSTATE | |
2610 | i386-xdep.c | |
2611 | @item VARIABLES_INSIDE_BLOCK | |
2612 | dbxread.c | |
2613 | @item WRS_ORIG | |
2614 | remote-vx.c | |
2615 | @item _LANG_c | |
2616 | language.c | |
2617 | @item _LANG_m2 | |
2618 | language.c | |
2619 | @item __GO32__ | |
2620 | inflow.c | |
2621 | @item __HAVE_68881__ | |
2622 | m68k-stub.c | |
2623 | @item __HPUX_ASM__ | |
2624 | xm-hp300hpux.h | |
2625 | @item __INT_VARARGS_H | |
2626 | printcmd.c | |
2627 | @item __not_on_pyr_yet | |
2628 | pyr-xdep.c | |
2629 | @item GOULD_PN | |
2630 | gould-pinsn.c | |
2631 | @item emacs | |
2632 | alloca.c | |
2633 | @item hp800 | |
2634 | xm-hppabsd.h | |
493cf018 JG |
2635 | @item hpux |
2636 | hppabsd-core.c | |
2637 | @item longest_to_int | |
2638 | defs.h | |
2639 | @item mc68020 | |
2640 | m68k-stub.c | |
2641 | @item ns32k_opcodeT | |
2642 | ns32k-opcode.h | |
2643 | @item sgi | |
2644 | mips-tdep.c | |
2645 | @item sparc | |
2646 | regex.c | |
2647 | @item static | |
2648 | alloca.c | |
2649 | @item sun | |
2650 | m68k-tdep.c | |
2651 | @item sun386 | |
2652 | tm-sun386.h | |
2653 | @item test | |
2654 | regex.c | |
2655 | @item x_name | |
2656 | coffread.c | |
2657 | @item x_zeroes | |
2658 | coffread.c | |
2659 | @end table | |
2660 | ||
b517f124 | 2661 | @node Native Conditionals |
968720bf RP |
2662 | @chapter Native Conditionals |
2663 | ||
b517f124 JG |
2664 | When GDB is configured and compiled, various macros are defined or left |
2665 | undefined, to control compilation when the host and target systems | |
2666 | are the same. These macros should be defined (or left undefined) | |
2667 | in @file{nm-@var{system}.h}. | |
968720bf | 2668 | |
1b87a1b2 | 2669 | @table @code |
968720bf RP |
2670 | @item ATTACH_DETACH |
2671 | If defined, then gdb will include support for the @code{attach} and | |
2672 | @code{detach} commands. | |
968720bf RP |
2673 | @item FETCH_INFERIOR_REGISTERS |
2674 | Define this if the native-dependent code will provide its | |
2675 | own routines | |
2676 | @code{fetch_inferior_registers} and @code{store_inferior_registers} in | |
2677 | @file{@var{HOST}-nat.c}. | |
f8f37439 DZ |
2678 | If this symbol is @emph{not} defined, and @file{infptrace.c} |
2679 | is included in this configuration, the default routines in | |
968720bf | 2680 | @file{infptrace.c} are used for these functions. |
c3bbca3a JG |
2681 | @item GET_LONGJMP_TARGET |
2682 | For most machines, this is a target-dependent parameter. On the DECstation | |
2683 | and the Iris, this is a native-dependent parameter, since <setjmp.h> is | |
2684 | needed to define it. | |
2685 | ||
2686 | This macro determines the target PC address that longjmp() will jump | |
2687 | to, assuming that we have just stopped at a longjmp breakpoint. It | |
2688 | takes a CORE_ADDR * as argument, and stores the target PC value through | |
2689 | this pointer. It examines the current state of the machine as needed. | |
968720bf RP |
2690 | @item PROC_NAME_FMT |
2691 | Defines the format for the name of a @file{/proc} device. Should be | |
2692 | defined in @file{nm.h} @emph{only} in order to override the default | |
2693 | definition in @file{procfs.c}. | |
9729ef22 JK |
2694 | @item PTRACE_FP_BUG |
2695 | mach386-xdep.c | |
2696 | @item PTRACE_ARG3_TYPE | |
2697 | The type of the third argument to the @code{ptrace} system call, if it exists | |
2698 | and is different from @code{int}. | |
968720bf RP |
2699 | @item REGISTER_U_ADDR |
2700 | Defines the offset of the registers in the ``u area''; @pxref{Host}. | |
2701 | @item USE_PROC_FS | |
f8f37439 DZ |
2702 | This determines whether small routines in @file{*-tdep.c}, which |
2703 | translate register values | |
2704 | between GDB's internal representation and the /proc representation, | |
2705 | are compiled. | |
968720bf RP |
2706 | @item U_REGS_OFFSET |
2707 | This is the offset of the registers in the upage. It need only be | |
2708 | defined if the generic ptrace register access routines in | |
2709 | @file{infptrace.c} are being used (that is, | |
f8f37439 | 2710 | @file{infptrace.c} is configured in, and |
968720bf RP |
2711 | @code{FETCH_INFERIOR_REGISTERS} is not defined). If the default value |
2712 | from @file{infptrace.c} is good enough, leave it undefined. | |
2713 | ||
2714 | The default value means that u.u_ar0 @emph{points to} the location of the | |
2715 | registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means that | |
2716 | u.u_ar0 @emph{is} the location of the registers. | |
2717 | @end table | |
2718 | ||
b517f124 JG |
2719 | @node Obsolete Conditionals |
2720 | @chapter Obsolete Conditionals | |
2721 | ||
2722 | Fragments of old code in GDB sometimes reference or set the following | |
2723 | configuration macros. They should not be used by new code, and | |
2724 | old uses should be removed as those parts of the debugger are | |
2725 | otherwise touched. | |
2726 | ||
2727 | @table @code | |
2728 | @item STACK_END_ADDR | |
2729 | This macro used to define where the end of the stack appeared, for use | |
2730 | in interpreting core file formats that don't record this address in the | |
2731 | core file itself. This information is now configured in BFD, and GDB | |
2732 | gets the info portably from there. The values in GDB's configuration | |
2733 | files should be moved into BFD configuration files (if needed there), | |
2734 | and deleted from all of GDB's config files. | |
2735 | ||
2736 | Any @file{@var{foo}-xdep.c} file that references STACK_END_ADDR | |
2737 | is so old that it has never been converted to use BFD. Now that's old! | |
2738 | @end table | |
9729ef22 JK |
2739 | |
2740 | @node XCOFF | |
2741 | @chapter The XCOFF Object File Format | |
2742 | ||
2743 | The IBM RS/6000 running AIX uses an object file format called xcoff. | |
2744 | The COFF sections, symbols, and line numbers are used, but debugging | |
2745 | symbols are dbx-style stabs whose strings are located in the | |
238ffce0 JG |
2746 | @samp{.debug} section (rather than the string table). For more |
2747 | information, @xref{Top,,,stabs,The Stabs Debugging Format}, and search | |
2748 | for XCOFF. | |
9729ef22 JK |
2749 | |
2750 | The shared library scheme has a nice clean interface for figuring out | |
2751 | what shared libraries are in use, but the catch is that everything which | |
2752 | refers to addresses (symbol tables and breakpoints at least) needs to be | |
2753 | relocated for both shared libraries and the main executable. At least | |
2754 | using the standard mechanism this can only be done once the program has | |
2755 | been run (or the core file has been read). | |
2756 | ||
ca714d03 RP |
2757 | @contents |
2758 | @bye |