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 | |
2a426d31 | 16 | Copyright 1990, 91, 92, 93, 94, 95, 96, 1997 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 | |
2a426d31 | 54 | Copyright @copyright{} 1990, 91, 92, 93, 94, 95, 96, 1997 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 | |
beb773f3 | 204 | If GDB is limping on your machine, this is the preferred way to get it |
a5e7f259 | 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 | ||
beb773f3 | 211 | When you run GDB in the GDB source directory, it will read a |
a5e7f259 JK |
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 | |
beb773f3 | 214 | in a GDB being debugged by gdb, will pop you back up to the top level |
a5e7f259 JK |
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 | ||
beb773f3 | 222 | Also, make sure that you've either compiled GDB with your local cc, or |
a5e7f259 | 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 | 349 | time. When creating the line that recognizes your configuration, |
cdc647da | 350 | only match the fields that you really need to match; e.g. don't |
fd3d2e1d JG |
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 | |
cdc647da | 455 | ./configure @var{xxx} --target=vxworks960 |
fd3d2e1d JG |
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 | |
54109914 | 538 | @item core-aout.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 | |
54109914 | 542 | use @code{core-aout.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 | |
54109914 | 545 | @item core-aout.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, | |
54109914 | 552 | @file{core-aout.c} will define the @code{register_addr()} function and use |
d98259f8 | 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 | |
54109914 | 582 | @file{core-aout.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 | |
54109914 | 817 | make -f Makefile.in gdb.tar.gz |
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 | 822 | and will then make a tarfile. (If the top level directory has already |
54109914 | 823 | been configured, you can just do @code{make gdb.tar.gz} 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 | ||
beb773f3 | 936 | These are the fundamental types that GDB uses internally. Fundamental |
3a8bc841 JK |
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 | |
beb773f3 | 939 | gdb knows about for all the languages that GDB knows about. |
3a8bc841 JK |
940 | |
941 | Type Codes (e.g., TYPE_CODE_PTR, TYPE_CODE_ARRAY). | |
942 | ||
beb773f3 | 943 | Each time GDB builds an internal type, it marks it with one of these |
3a8bc841 JK |
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 | |
beb773f3 | 953 | types and are created as global types for GDB to use for various ugly |
3a8bc841 JK |
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 | |
beb773f3 | 1000 | file containing the program which GDB is debugging. GDB can be directed |
eb752e4e JG |
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 | |
cdc647da SS |
1493 | system. These macros and their meanings (or if the meaning is not |
1494 | documented here, then one of the source files where they are used is | |
1495 | indicated) are: | |
493cf018 JG |
1496 | |
1497 | @emph{NOTE: For now, both host and target conditionals are here. | |
1498 | Eliminate target conditionals from this list as they are identified.} | |
1499 | ||
1500 | @table @code | |
cdc647da | 1501 | |
493cf018 JG |
1502 | @item BLOCK_ADDRESS_FUNCTION_RELATIVE |
1503 | dbxread.c | |
cdc647da | 1504 | |
493cf018 | 1505 | @item GDBINIT_FILENAME |
cdc647da SS |
1506 | The default name of GDB's initialization file (normally @file{.gdbinit}). |
1507 | ||
493cf018 | 1508 | @item MEM_FNS_DECLARED |
00db1549 JG |
1509 | Your host config file defines this if it includes |
1510 | declarations of @code{memcpy} and @code{memset}. Define this | |
1511 | to avoid conflicts between the native include | |
1512 | files and the declarations in @file{defs.h}. | |
cdc647da | 1513 | |
493cf018 | 1514 | @item NO_SYS_FILE |
54109914 FF |
1515 | Define this if your system does not have a @code{<sys/file.h>}. |
1516 | ||
1517 | @item SIGWINCH_HANDLER | |
1518 | If your host defines @code{SIGWINCH}, you can define this to | |
1519 | be the name of a function to be called if @code{SIGWINCH} is received. | |
1520 | ||
493cf018 | 1521 | @item SIGWINCH_HANDLER_BODY |
54109914 FF |
1522 | Define this to expand into code that will define the function |
1523 | named by the expansion of @code{SIGWINCH_HANDLER}. | |
1524 | ||
493cf018 JG |
1525 | @item ADDITIONAL_OPTIONS |
1526 | main.c | |
1527 | @item ADDITIONAL_OPTION_CASES | |
1528 | main.c | |
1529 | @item ADDITIONAL_OPTION_HANDLER | |
1530 | main.c | |
1531 | @item ADDITIONAL_OPTION_HELP | |
1532 | main.c | |
54109914 | 1533 | |
493cf018 JG |
1534 | @item AIX_BUGGY_PTRACE_CONTINUE |
1535 | infptrace.c | |
cdc647da | 1536 | |
54109914 FF |
1537 | @item ALIGN_STACK_ON_STARTUP |
1538 | Define this if your system is of a sort that will crash in @code{tgetent} | |
1539 | if the stack happens not to be longword-aligned when @code{main} is | |
1540 | called. This is a rare situation, but is known to occur on several | |
1541 | different types of systems. | |
cdc647da | 1542 | |
493cf018 JG |
1543 | @item CFRONT_PRODUCER |
1544 | dwarfread.c | |
2a426d31 FF |
1545 | |
1546 | @item CRLF_SOURCE_FILES | |
1547 | Define this if host files use @code{\r\n} rather than @code{\n} as a | |
1548 | line terminator. This will cause source file listings to omit @code{\r} | |
1549 | characters when printing. It must be possible to open files in binary | |
1550 | mode using @code{O_BINARY} or, for fopen, @code{"rb"}. | |
1551 | ||
493cf018 JG |
1552 | @item DBX_PARM_SYMBOL_CLASS |
1553 | stabsread.c | |
cdc647da | 1554 | |
493cf018 | 1555 | @item DEFAULT_PROMPT |
cdc647da SS |
1556 | The default value of the prompt string (normally @code{"(gdb) "}). |
1557 | ||
493cf018 JG |
1558 | @item DEV_TTY |
1559 | symmisc.c | |
493cf018 JG |
1560 | @item DO_REGISTERS_INFO |
1561 | infcmd.c | |
54109914 FF |
1562 | |
1563 | @item FCLOSE_PROVIDED | |
1564 | Define this if the system declares @code{fclose} in the headers included in | |
1565 | @code{defs.h}. This isn't needed unless your compiler is unusually anal. | |
1566 | ||
1567 | @sc{ANSI} definition. | |
1568 | ||
493cf018 JG |
1569 | @item FILES_INFO_HOOK |
1570 | target.c | |
493cf018 JG |
1571 | @item FLOAT_INFO |
1572 | infcmd.c | |
54109914 | 1573 | |
493cf018 | 1574 | @item FOPEN_RB |
54109914 FF |
1575 | Define this if binary files are opened the same way as text files. |
1576 | ||
493cf018 JG |
1577 | @item GCC2_COMPILED_FLAG_SYMBOL |
1578 | dbxread.c | |
1579 | @item GCC_COMPILED_FLAG_SYMBOL | |
1580 | dbxread.c | |
1581 | @item GCC_MANGLE_BUG | |
1582 | symtab.c | |
1583 | @item GCC_PRODUCER | |
1584 | dwarfread.c | |
54109914 FF |
1585 | |
1586 | @item GETENV_PROVIDED | |
1587 | Define this if the system declares @code{getenv} in its headers included in | |
1588 | @code{defs.h}. This isn't needed unless your compiler is unusually anal. | |
1589 | ||
493cf018 JG |
1590 | @item GPLUS_PRODUCER |
1591 | dwarfread.c | |
cdc647da | 1592 | |
493cf018 | 1593 | @item HAVE_MMAP |
968720bf RP |
1594 | In some cases, use the system call @code{mmap} for reading symbol |
1595 | tables. For some machines this allows for sharing and quick updates. | |
cdc647da | 1596 | |
493cf018 | 1597 | @item HAVE_SIGSETMASK |
54109914 FF |
1598 | Define this if the host system has job control, but does not |
1599 | define @code{sigsetmask()}. | |
1600 | Currently, this is only true of the RS/6000. | |
1601 | ||
493cf018 JG |
1602 | @item HAVE_TERMIO |
1603 | inflow.c | |
54109914 | 1604 | |
493cf018 | 1605 | @item HOST_BYTE_ORDER |
54109914 FF |
1606 | The ordering of bytes in the host. |
1607 | This must be defined to be either @code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}. | |
beb773f3 | 1608 | |
493cf018 | 1609 | @item INT_MAX |
493cf018 | 1610 | @item INT_MIN |
beb773f3 SS |
1611 | @item LONG_MAX |
1612 | @item UINT_MAX | |
1613 | @item ULONG_MAX | |
1614 | Values for host-side constants. | |
1615 | ||
493cf018 | 1616 | @item ISATTY |
beb773f3 SS |
1617 | Substitute for isatty, if not available. |
1618 | ||
493cf018 JG |
1619 | @item KERNEL_DEBUGGING |
1620 | tm-ultra3.h | |
cdc647da | 1621 | |
493cf018 JG |
1622 | @item KERNEL_U_ADDR |
1623 | Define this to the address of the @code{u} structure (the ``user struct'', | |
1624 | also known as the ``u-page'') in kernel virtual memory. GDB needs to know | |
1625 | this so that it can subtract this address from absolute addresses in | |
1626 | the upage, that are obtained via ptrace or from core files. On systems | |
1627 | that don't need this value, set it to zero. | |
cdc647da | 1628 | |
493cf018 JG |
1629 | @item KERNEL_U_ADDR_BSD |
1630 | Define this to cause GDB to determine the address of @code{u} at runtime, | |
1631 | by using Berkeley-style @code{nlist} on the kernel's image in the root | |
1632 | directory. | |
cdc647da | 1633 | |
493cf018 JG |
1634 | @item KERNEL_U_ADDR_HPUX |
1635 | Define this to cause GDB to determine the address of @code{u} at runtime, | |
1636 | by using HP-style @code{nlist} on the kernel's image in the root | |
1637 | directory. | |
cdc647da | 1638 | |
493cf018 JG |
1639 | @item LCC_PRODUCER |
1640 | dwarfread.c | |
beb773f3 | 1641 | |
493cf018 | 1642 | @item LONGEST |
beb773f3 SS |
1643 | This is the longest integer type available on the host. |
1644 | If not defined, it will default to @code{long long} or @code{long}, | |
1645 | depending on @code{CC_HAS_LONG_LONG}. | |
1646 | ||
238ffce0 | 1647 | @item CC_HAS_LONG_LONG |
beb773f3 | 1648 | Define this if the host C compiler supports ``long long''. |
2a426d31 | 1649 | This is set by the configure script. |
beb773f3 | 1650 | |
238ffce0 | 1651 | @item PRINTF_HAS_LONG_LONG |
2a426d31 FF |
1652 | Define this if the host can handle printing of long long integers via |
1653 | the printf format directive ``ll''. This is set by the configure script. | |
1654 | ||
1655 | @item HAVE_LONG_DOUBLE | |
1656 | Define this if the host C compiler supports ``long double''. | |
1657 | This is set by the configure script. | |
1658 | ||
1659 | @item PRINTF_HAS_LONG_DOUBLE | |
1660 | Define this if the host can handle printing of long double float-point | |
1661 | numbers via the printf format directive ``Lg''. This is set by the | |
1662 | configure script. | |
1663 | ||
1664 | @item SCANF_HAS_LONG_DOUBLE | |
1665 | Define this if the host can handle the parsing of long double | |
1666 | float-point numbers via the scanf format directive directive | |
1667 | ``Lg''. This is set by the configure script. | |
beb773f3 | 1668 | |
493cf018 | 1669 | @item LSEEK_NOT_LINEAR |
2a426d31 FF |
1670 | Define this if @code{lseek (n)} does not necessarily move to byte number |
1671 | @code{n} in the file. This is only used when reading source files. It | |
1672 | is normally faster to define @code{CRLF_SOURCE_FILES} when possible. | |
1673 | ||
493cf018 JG |
1674 | @item L_LNNO32 |
1675 | coffread.c | |
cdc647da | 1676 | |
493cf018 | 1677 | @item L_SET |
c3bbca3a | 1678 | This macro is used as the argument to lseek (or, most commonly, bfd_seek). |
cdc647da SS |
1679 | FIXME, should be replaced by SEEK_SET instead, which is the POSIX equivalent. |
1680 | ||
493cf018 | 1681 | @item MAINTENANCE_CMDS |
cdc647da SS |
1682 | If the value of this is 1, then a number of optional maintenance commands |
1683 | are compiled in. | |
1684 | ||
493cf018 | 1685 | @item MALLOC_INCOMPATIBLE |
968720bf RP |
1686 | Define this if the system's prototype for @code{malloc} differs from the |
1687 | @sc{ANSI} definition. | |
cdc647da | 1688 | |
493cf018 | 1689 | @item MMAP_BASE_ADDRESS |
968720bf | 1690 | When using HAVE_MMAP, the first mapping should go at this address. |
cdc647da | 1691 | |
968720bf RP |
1692 | @item MMAP_INCREMENT |
1693 | when using HAVE_MMAP, this is the increment between mappings. | |
cdc647da | 1694 | |
493cf018 | 1695 | @item NEED_POSIX_SETPGID |
54109914 FF |
1696 | Define this to use the POSIX version of @code{setpgid} to determine |
1697 | whether job control is available. | |
cdc647da | 1698 | |
493cf018 | 1699 | @item NORETURN |
beb773f3 SS |
1700 | If defined, this should be one or more tokens, such as @code{volatile}, |
1701 | that can be used in both the declaration and definition of functions | |
1702 | to indicate that they never return. The default is already set | |
1703 | correctly if compiling with GCC. | |
1704 | This will almost never need to be defined. | |
1705 | ||
1706 | @item ATTR_NORETURN | |
1707 | If defined, this should be one or more tokens, such as | |
1708 | @code{__attribute__ ((noreturn))}, that can be used in the declarations | |
1709 | of functions to indicate that they never return. The default is already | |
1710 | set correctly if compiling with GCC. | |
1711 | This will almost never need to be defined. | |
cdc647da | 1712 | |
493cf018 JG |
1713 | @item NOTICE_SIGNAL_HANDLING_CHANGE |
1714 | infrun.c | |
493cf018 JG |
1715 | @item NO_HIF_SUPPORT |
1716 | remote-mm.c | |
1717 | @item NO_JOB_CONTROL | |
1718 | signals.h | |
cdc647da | 1719 | |
2a426d31 | 1720 | @item USE_MMALLOC |
d7d35f00 | 1721 | GDB will use the @code{mmalloc} library for memory allocation for symbol |
2a426d31 FF |
1722 | reading if this symbol is defined. Be careful defining it since there |
1723 | are systems on which @code{mmalloc} does not | |
d7d35f00 FF |
1724 | work for some reason. One example is the DECstation, where its RPC |
1725 | library can't cope with our redefinition of @code{malloc} to call | |
2a426d31 FF |
1726 | @code{mmalloc}. When defining @code{USE_MMALLOC}, you will also have |
1727 | to set @code{MMALLOC} in the Makefile, to point to the mmalloc library. | |
1728 | This define is set when you configure with --with-mmalloc. | |
cdc647da | 1729 | |
54109914 | 1730 | @item NO_MMCHECK |
d7d35f00 | 1731 | Define this if you are using @code{mmalloc}, but don't want the overhead |
54109914 FF |
1732 | of checking the heap with @code{mmcheck}. Note that on some systems, |
1733 | the C runtime makes calls to malloc prior to calling @code{main}, and if | |
1734 | @code{free} is ever called with these pointers after calling @code{mmcheck} | |
1735 | to enable checking, a memory corruption abort is certain to occur. These | |
1736 | systems can still use mmalloc, but must define NO_MMCHECK. | |
1737 | ||
1738 | @item MMCHECK_FORCE | |
1739 | Define this to 1 if the C runtime allocates memory prior to @code{mmcheck} | |
1740 | being called, but that memory is never freed so we don't have to worry | |
1741 | about it triggering a memory corruption abort. The default is 0, which | |
1742 | means that @code{mmcheck} will only install the heap checking functions | |
1743 | if there has not yet been any memory allocation calls, and if it fails | |
2a426d31 FF |
1744 | to install the functions, gdb will issue a warning. This is currently |
1745 | defined if you configure using --with-mmalloc. | |
cdc647da | 1746 | |
493cf018 JG |
1747 | @item NO_SIGINTERRUPT |
1748 | remote-adapt.c | |
493cf018 JG |
1749 | @item NUMERIC_REG_NAMES |
1750 | mips-tdep.c | |
1751 | @item N_SETV | |
1752 | dbxread.c | |
1753 | @item N_SET_MAGIC | |
1754 | hppabsd-tdep.c | |
493cf018 JG |
1755 | @item ONE_PROCESS_WRITETEXT |
1756 | breakpoint.c | |
1757 | @item O_BINARY | |
1758 | exec.c | |
1759 | @item O_RDONLY | |
1760 | xm-ultra3.h | |
493cf018 JG |
1761 | @item PCC_SOL_BROKEN |
1762 | dbxread.c | |
493cf018 JG |
1763 | @item PC_LOAD_SEGMENT |
1764 | stack.c | |
493cf018 JG |
1765 | @item PRINT_RANDOM_SIGNAL |
1766 | infcmd.c | |
1767 | @item PRINT_REGISTER_HOOK | |
1768 | infcmd.c | |
493cf018 JG |
1769 | @item PROCESS_LINENUMBER_HOOK |
1770 | buildsym.c | |
1771 | @item PROLOGUE_FIRSTLINE_OVERLAP | |
1772 | infrun.c | |
493cf018 JG |
1773 | @item PUSH_ARGUMENTS |
1774 | valops.c | |
1775 | @item PYRAMID_CONTROL_FRAME_DEBUGGING | |
1776 | pyr-xdep.c | |
1777 | @item PYRAMID_CORE | |
1778 | pyr-xdep.c | |
1779 | @item PYRAMID_PTRACE | |
1780 | pyr-xdep.c | |
1781 | @item REGISTER_BYTES | |
1782 | remote.c | |
493cf018 JG |
1783 | @item REG_STACK_SEGMENT |
1784 | exec.c | |
1785 | @item REG_STRUCT_HAS_ADDR | |
1786 | findvar.c | |
493cf018 JG |
1787 | @item R_FP |
1788 | dwarfread.c | |
1789 | @item R_OK | |
1790 | xm-altos.h | |
493cf018 JG |
1791 | @item SEEK_END |
1792 | state.c | |
1793 | @item SEEK_SET | |
1794 | state.c | |
1795 | @item SEM | |
1796 | coffread.c | |
cdc647da | 1797 | |
493cf018 JG |
1798 | @item SHELL_COMMAND_CONCAT |
1799 | infrun.c | |
1800 | @item SHELL_FILE | |
1801 | infrun.c | |
1802 | @item SHIFT_INST_REGS | |
1803 | breakpoint.c | |
493cf018 JG |
1804 | @item SIGTRAP_STOP_AFTER_LOAD |
1805 | infrun.c | |
493cf018 JG |
1806 | @item STACK_ALIGN |
1807 | valops.c | |
493cf018 JG |
1808 | @item STOP_SIGNAL |
1809 | main.c | |
493cf018 JG |
1810 | @item SUN4_COMPILER_FEATURE |
1811 | infrun.c | |
1812 | @item SUN_FIXED_LBRAC_BUG | |
1813 | dbxread.c | |
1814 | @item SVR4_SHARED_LIBS | |
1815 | solib.c | |
493cf018 JG |
1816 | @item SYMBOL_RELOADING_DEFAULT |
1817 | symfile.c | |
493cf018 JG |
1818 | @item TIOCGETC |
1819 | inflow.c | |
1820 | @item TIOCGLTC | |
1821 | inflow.c | |
1822 | @item TIOCGPGRP | |
1823 | inflow.c | |
1824 | @item TIOCLGET | |
1825 | inflow.c | |
1826 | @item TIOCLSET | |
1827 | inflow.c | |
1828 | @item TIOCNOTTY | |
1829 | inflow.c | |
493cf018 JG |
1830 | @item UPAGES |
1831 | altos-xdep.c | |
493cf018 JG |
1832 | @item USE_O_NOCTTY |
1833 | inflow.c | |
cdc647da | 1834 | |
493cf018 JG |
1835 | @item USG |
1836 | Means that System V (prior to SVR4) include files are in use. | |
1837 | (FIXME: This symbol is abused in @file{infrun.c}, @file{regex.c}, | |
1838 | @file{remote-nindy.c}, and @file{utils.c} for other things, at the moment.) | |
cdc647da | 1839 | |
493cf018 JG |
1840 | @item WRS_ORIG |
1841 | remote-vx.c | |
493cf018 JG |
1842 | @item alloca |
1843 | defs.h | |
1844 | @item const | |
1845 | defs.h | |
beb773f3 | 1846 | |
493cf018 | 1847 | @item lint |
beb773f3 SS |
1848 | Define this to help lint in some stupid way. |
1849 | ||
1850 | @item volatile | |
1851 | Define this to override the defaults of @code{__volatile__} or @code{/**/}. | |
1852 | ||
1853 | @end table | |
1854 | ||
54109914 FF |
1855 | Platform-specific host conditionals. |
1856 | ||
1857 | @table @code | |
1858 | ||
1859 | @item ALTOS | |
1860 | altos-xdep.c | |
1861 | @item ALTOS_AS | |
1862 | xm-altos.h | |
1863 | @item MOTOROLA | |
1864 | xm-altos.h | |
1865 | @item NBPG | |
1866 | altos-xdep.c | |
1867 | ||
1868 | @item BCS | |
1869 | tm-delta88.h | |
1870 | ||
1871 | @item DELTA88 | |
1872 | m88k-xdep.c | |
1873 | @item DGUX | |
1874 | m88k-xdep.c | |
1875 | ||
1876 | @item F_OK | |
1877 | xm-ultra3.h | |
1878 | ||
1879 | @end table | |
1880 | ||
beb773f3 SS |
1881 | Regex conditionals. |
1882 | ||
54109914 | 1883 | @table @code |
7f494564 | 1884 | |
beb773f3 SS |
1885 | @item C_ALLOCA |
1886 | regex.c | |
1887 | @item NFAILURES | |
1888 | regex.c | |
1889 | @item RE_NREGS | |
1890 | regex.h | |
1891 | @item SIGN_EXTEND_CHAR | |
1892 | regex.c | |
1893 | @item SWITCH_ENUM_BUG | |
1894 | regex.c | |
1895 | @item SYNTAX_TABLE | |
1896 | regex.c | |
1897 | @item Sword | |
1898 | regex.c | |
493cf018 JG |
1899 | @item sparc |
1900 | regex.c | |
493cf018 JG |
1901 | @item test |
1902 | regex.c | |
493cf018 | 1903 | |
7f494564 SS |
1904 | @end table |
1905 | ||
b517f124 | 1906 | @node Target Conditionals |
493cf018 JG |
1907 | @chapter Target Conditionals |
1908 | ||
1909 | When GDB is configured and compiled, various macros are defined or left | |
1910 | undefined, to control compilation based on the attributes of the target | |
1911 | system. These macros and their meanings are: | |
1912 | ||
1913 | @emph{NOTE: For now, both host and target conditionals are here. | |
1914 | Eliminate host conditionals from this list as they are identified.} | |
1915 | ||
1916 | @table @code | |
cdc647da | 1917 | |
ca048722 RP |
1918 | @item PUSH_DUMMY_FRAME |
1919 | Used in @samp{call_function_by_hand} to create an artificial stack frame. | |
cdc647da | 1920 | |
ca048722 RP |
1921 | @item POP_FRAME |
1922 | Used in @samp{call_function_by_hand} to remove an artificial stack frame. | |
cdc647da | 1923 | |
493cf018 JG |
1924 | @item BLOCK_ADDRESS_FUNCTION_RELATIVE |
1925 | dbxread.c | |
493cf018 JG |
1926 | @item PYRAMID_CONTROL_FRAME_DEBUGGING |
1927 | pyr-xdep.c | |
493cf018 JG |
1928 | @item ADDITIONAL_OPTIONS |
1929 | main.c | |
1930 | @item ADDITIONAL_OPTION_CASES | |
1931 | main.c | |
1932 | @item ADDITIONAL_OPTION_HANDLER | |
1933 | main.c | |
1934 | @item ADDITIONAL_OPTION_HELP | |
1935 | main.c | |
beb773f3 SS |
1936 | |
1937 | @item ADDR_BITS_REMOVE (addr) | |
1938 | If a raw machine address includes any bits that are not really part | |
1939 | of the address, then define this macro to expand into an expression | |
1940 | that zeros those bits in @var{addr}. For example, the two low-order | |
1941 | bits of a Motorola 88K address may be used by some kernels for their | |
1942 | own purposes, since addresses must always be 4-byte aligned, and so | |
1943 | are of no use for addressing. Those bits should be filtered out with | |
1944 | an expression such as @code{((addr) & ~3)}. | |
1945 | ||
493cf018 JG |
1946 | @item ALIGN_STACK_ON_STARTUP |
1947 | main.c | |
1948 | @item ALTOS | |
1949 | altos-xdep.c | |
1950 | @item ALTOS_AS | |
1951 | xm-altos.h | |
493cf018 JG |
1952 | @item BCS |
1953 | tm-delta88.h | |
54109914 FF |
1954 | |
1955 | @item BEFORE_MAIN_LOOP_HOOK | |
1956 | Define this to expand into any code that you want to execute before | |
1957 | the main loop starts. Although this is not, strictly speaking, | |
1958 | a target conditional, that is how it is currently being used. | |
1959 | Note that if a configuration were to define it one way for a host | |
1960 | and a different way for the target, GDB will probably not compile, | |
1961 | let alone run correctly. | |
1962 | ||
493cf018 JG |
1963 | @item BELIEVE_PCC_PROMOTION |
1964 | coffread.c | |
1965 | @item BELIEVE_PCC_PROMOTION_TYPE | |
1966 | stabsread.c | |
beb773f3 | 1967 | |
493cf018 | 1968 | @item BITS_BIG_ENDIAN |
beb773f3 SS |
1969 | Define this if the numbering of bits in the targets does *not* match |
1970 | the endianness of the target byte order. | |
1971 | A value of 1 means that the bits are numbered in a big-endian order, | |
1972 | 0 means little-endian. | |
1973 | ||
493cf018 JG |
1974 | @item BLOCK_ADDRESS_ABSOLUTE |
1975 | dbxread.c | |
493cf018 | 1976 | @item BREAKPOINT |
3a8bc841 | 1977 | tm-m68k.h |
54109914 | 1978 | |
493cf018 JG |
1979 | @item CALL_DUMMY |
1980 | valops.c | |
1981 | @item CALL_DUMMY_LOCATION | |
1982 | inferior.h | |
1983 | @item CALL_DUMMY_STACK_ADJUST | |
1984 | valops.c | |
beb773f3 SS |
1985 | |
1986 | @item CANNOT_FETCH_REGISTER (regno) | |
1987 | A C expression that should be nonzero if @var{regno} cannot be | |
1988 | fetched from an inferior process. | |
1989 | This is only relevant if @code{FETCH_INFERIOR_REGISTERS} is not | |
1990 | defined. | |
1991 | ||
1992 | @item CANNOT_STORE_REGISTER (regno) | |
1993 | A C expression that should be nonzero if @var{regno} should not be | |
1994 | written to the target. This is often the case for program counters, | |
1995 | status words, and other special registers. If this is not defined, | |
1996 | GDB will assume that all registers may be written. | |
1997 | ||
493cf018 JG |
1998 | @item CFRONT_PRODUCER |
1999 | dwarfread.c | |
54109914 FF |
2000 | |
2001 | @item DO_DEFERRED_STORES | |
493cf018 | 2002 | @item CLEAR_DEFERRED_STORES |
54109914 FF |
2003 | Define this to execute any deferred stores of registers into the inferior, |
2004 | and to cancel any deferred stores. | |
2005 | ||
2006 | Currently only implemented correctly for native Sparc configurations? | |
2007 | ||
493cf018 | 2008 | @item CPLUS_MARKER |
54109914 FF |
2009 | Define this to expand into the character that G++ uses to |
2010 | distinguish compiler-generated identifiers from programmer-specified | |
2011 | identifiers. By default, this expands into @code{'$'}. | |
2012 | Most System V targets should define this to @code{'.'}. | |
2013 | ||
493cf018 JG |
2014 | @item DBX_PARM_SYMBOL_CLASS |
2015 | stabsread.c | |
54109914 | 2016 | |
493cf018 | 2017 | @item DECR_PC_AFTER_BREAK |
54109914 FF |
2018 | Define this to be the amount by which to decrement the PC after |
2019 | the program encounters a breakpoint. | |
2020 | This is often the number of bytes in BREAKPOINT, though not always. | |
2021 | For most targets this value will be 0. | |
2022 | ||
2023 | @item DECR_PC_AFTER_HW_BREAK | |
2024 | Similarly, for hardware breakpoints. | |
2025 | ||
493cf018 JG |
2026 | @item DELTA88 |
2027 | m88k-xdep.c | |
2028 | @item DEV_TTY | |
2029 | symmisc.c | |
2030 | @item DGUX | |
2031 | m88k-xdep.c | |
54109914 FF |
2032 | |
2033 | @item DISABLE_UNSETTABLE_BREAK addr | |
2034 | If defined, this should evaluate to 1 if @var{addr} is in a shared | |
2035 | library in which breakpoints cannot be set and so should be disabled. | |
2036 | ||
493cf018 JG |
2037 | @item DO_REGISTERS_INFO |
2038 | infcmd.c | |
cdc647da | 2039 | |
493cf018 | 2040 | @item END_OF_TEXT_DEFAULT |
cdc647da SS |
2041 | This is an expression that should designate the end of the text section |
2042 | (? FIXME ?) | |
2043 | ||
493cf018 | 2044 | @item EXTRACT_RETURN_VALUE |
3a8bc841 | 2045 | tm-m68k.h |
493cf018 JG |
2046 | @item EXTRACT_STRUCT_VALUE_ADDRESS |
2047 | values.c | |
beb773f3 | 2048 | |
493cf018 | 2049 | @item EXTRA_FRAME_INFO |
beb773f3 SS |
2050 | If defined, this must be a list of slots that may be inserted into |
2051 | the @code{frame_info} structure defined in @code{frame.h}. | |
2052 | ||
493cf018 | 2053 | @item EXTRA_SYMTAB_INFO |
beb773f3 SS |
2054 | If defined, this must be a list of slots that may be inserted into |
2055 | the @code{symtab} structure defined in @code{symtab.h}. | |
2056 | ||
493cf018 JG |
2057 | @item FILES_INFO_HOOK |
2058 | target.c | |
493cf018 JG |
2059 | @item FLOAT_INFO |
2060 | infcmd.c | |
493cf018 JG |
2061 | @item FP0_REGNUM |
2062 | a68v-xdep.c | |
2063 | @item FPC_REGNUM | |
2064 | mach386-xdep.c | |
2065 | @item FP_REGNUM | |
2066 | parse.c | |
2067 | @item FRAMELESS_FUNCTION_INVOCATION | |
2068 | blockframe.c | |
2069 | @item FRAME_ARGS_ADDRESS_CORRECT | |
2070 | stack.c | |
cdc647da | 2071 | |
a5e7f259 JK |
2072 | @item FRAME_CHAIN |
2073 | Given FRAME, return a pointer to the calling frame. | |
cdc647da | 2074 | |
493cf018 JG |
2075 | @item FRAME_CHAIN_COMBINE |
2076 | blockframe.c | |
2077 | @item FRAME_CHAIN_VALID | |
2078 | frame.h | |
2079 | @item FRAME_CHAIN_VALID_ALTERNATE | |
2080 | frame.h | |
2081 | @item FRAME_FIND_SAVED_REGS | |
2082 | stack.c | |
2083 | @item FRAME_GET_BASEREG_VALUE | |
2084 | frame.h | |
cdc647da SS |
2085 | |
2086 | @item FRAME_NUM_ARGS (val, fi) | |
2087 | For the frame described by fi, set val to the number of arguments | |
2088 | that are being passed. | |
2089 | ||
493cf018 JG |
2090 | @item FRAME_SPECIFICATION_DYADIC |
2091 | stack.c | |
cdc647da | 2092 | |
a5e7f259 JK |
2093 | @item FRAME_SAVED_PC |
2094 | Given FRAME, return the pc saved there. That is, the return address. | |
cdc647da | 2095 | |
493cf018 | 2096 | @item FUNCTION_EPILOGUE_SIZE |
54109914 FF |
2097 | For some COFF targets, the @code{x_sym.x_misc.x_fsize} field of the |
2098 | function end symbol is 0. For such targets, you must define | |
2099 | @code{FUNCTION_EPILOGUE_SIZE} to expand into the standard size | |
2100 | of a function's epilogue. | |
2101 | ||
493cf018 JG |
2102 | @item GCC2_COMPILED_FLAG_SYMBOL |
2103 | dbxread.c | |
2104 | @item GCC_COMPILED_FLAG_SYMBOL | |
2105 | dbxread.c | |
2106 | @item GCC_MANGLE_BUG | |
2107 | symtab.c | |
2108 | @item GCC_PRODUCER | |
2109 | dwarfread.c | |
cdc647da | 2110 | |
968720bf RP |
2111 | @item GDB_TARGET_IS_HPPA |
2112 | This determines whether horrible kludge code in dbxread.c and partial-stab.h | |
2113 | is used to mangle multiple-symbol-table files from HPPA's. This should all | |
2114 | be ripped out, and a scheme like elfread.c used. | |
cdc647da | 2115 | |
493cf018 JG |
2116 | @item GDB_TARGET_IS_MACH386 |
2117 | mach386-xdep.c | |
2118 | @item GDB_TARGET_IS_SUN3 | |
2119 | a68v-xdep.c | |
2120 | @item GDB_TARGET_IS_SUN386 | |
2121 | sun386-xdep.c | |
cdc647da | 2122 | |
493cf018 | 2123 | @item GET_LONGJMP_TARGET |
c3bbca3a JG |
2124 | For most machines, this is a target-dependent parameter. On the DECstation |
2125 | and the Iris, this is a native-dependent parameter, since <setjmp.h> is | |
2126 | needed to define it. | |
2127 | ||
2128 | This macro determines the target PC address that longjmp() will jump | |
2129 | to, assuming that we have just stopped at a longjmp breakpoint. It | |
2130 | takes a CORE_ADDR * as argument, and stores the target PC value through | |
2131 | this pointer. It examines the current state of the machine as needed. | |
cdc647da | 2132 | |
493cf018 | 2133 | @item GET_SAVED_REGISTER |
54109914 FF |
2134 | Define this if you need to supply your own definition for the |
2135 | function @code{get_saved_register}. | |
2136 | Currently this is only done for the a29k. | |
2137 | ||
493cf018 JG |
2138 | @item GPLUS_PRODUCER |
2139 | dwarfread.c | |
54109914 | 2140 | |
493cf018 | 2141 | @item GR64_REGNUM |
54109914 FF |
2142 | Very a29k-specific. |
2143 | ||
493cf018 | 2144 | @item HAVE_REGISTER_WINDOWS |
54109914 FF |
2145 | Define this if the target has register windows. |
2146 | @item REGISTER_IN_WINDOW_P regnum | |
2147 | Define this to be an expression that is 1 is the given register is | |
2148 | in the window. | |
cdc647da | 2149 | |
493cf018 | 2150 | @item IBM6000_TARGET |
d3d6d0ff JG |
2151 | Shows that we are configured for an IBM RS/6000 target. This conditional |
2152 | should be eliminated (FIXME) and replaced by feature-specific macros. | |
2153 | It was introduced in haste and we are repenting at leisure. | |
cdc647da | 2154 | |
493cf018 | 2155 | @item IEEE_FLOAT |
54109914 FF |
2156 | Define this if the target system uses IEEE-format floating point numbers. |
2157 | ||
2158 | @item IGNORE_SYMBOL type | |
2159 | This seems to be no longer used. | |
beb773f3 SS |
2160 | |
2161 | @item INIT_EXTRA_FRAME_INFO (fromleaf, fci) | |
2162 | If defined, this should be a C expression or statement that fills | |
2163 | in the @code{EXTRA_FRAME_INFO} slots of the given frame @var{fci}. | |
2164 | ||
493cf018 JG |
2165 | @item INIT_EXTRA_SYMTAB_INFO |
2166 | symfile.c | |
beb773f3 SS |
2167 | |
2168 | @item INIT_FRAME_PC (fromleaf, prev) | |
2169 | This is a C statement that sets the pc of the frame pointed | |
2170 | to by @var{prev}. [By default...] | |
2171 | ||
493cf018 | 2172 | @item INNER_THAN |
beb773f3 SS |
2173 | Define this to be either @code{<} if the target's stack grows |
2174 | downward in memory, or @code{>} is the stack grows upwards. | |
2175 | ||
2a426d31 | 2176 | @item IN_SIGTRAMP (pc name) |
54109914 FF |
2177 | Define this to return true if the given pc and/or name indicates |
2178 | that the current function is a sigtramp. | |
2179 | ||
2a426d31 FF |
2180 | @item SIGTRAMP_START (pc) |
2181 | @item SIGTRAMP_END (pc) | |
2182 | Define these to be the start and end address of the sigtramp for the given pc. | |
2183 | On machines where the address is just a compile time constant, the macro | |
2184 | expansion will typically just ignore the supplied pc. | |
54109914 FF |
2185 | |
2186 | @item IN_SOLIB_TRAMPOLINE pc name | |
2187 | Define this to evaluate to nonzero if the program is stopped in | |
2188 | the trampoline that connects to a shared library. | |
2189 | ||
2190 | @item IS_TRAPPED_INTERNALVAR name | |
2191 | This is an ugly hook to allow the specification of special actions | |
2192 | that should occur as a side-effect of setting the value of a variable | |
2193 | internal to GDB. Currently only used by the h8500. | |
2194 | Note that this could be either a host or target conditional. | |
2195 | ||
493cf018 JG |
2196 | @item KERNEL_DEBUGGING |
2197 | tm-ultra3.h | |
2198 | @item LCC_PRODUCER | |
2199 | dwarfread.c | |
493cf018 JG |
2200 | @item L_LNNO32 |
2201 | coffread.c | |
493cf018 JG |
2202 | @item MIPSEL |
2203 | mips-tdep.c | |
493cf018 JG |
2204 | @item MOTOROLA |
2205 | xm-altos.h | |
493cf018 JG |
2206 | @item NBPG |
2207 | altos-xdep.c | |
54109914 | 2208 | |
493cf018 | 2209 | @item NEED_TEXT_START_END |
54109914 FF |
2210 | Define this if GDB should determine the start and end addresses |
2211 | of the text section. (Seems dubious.) | |
2212 | ||
493cf018 JG |
2213 | @item NOTICE_SIGNAL_HANDLING_CHANGE |
2214 | infrun.c | |
493cf018 JG |
2215 | @item NO_HIF_SUPPORT |
2216 | remote-mm.c | |
493cf018 JG |
2217 | @item NO_SIGINTERRUPT |
2218 | remote-adapt.c | |
beb773f3 | 2219 | |
493cf018 | 2220 | @item NO_SINGLE_STEP |
beb773f3 SS |
2221 | Define this if the target does not support single-stepping. |
2222 | If this is defined, you must supply, in @code{*-tdep.c}, the function | |
ed393c16 | 2223 | @code{single_step}, which takes a target_signal as argument and returns nothing. |
beb773f3 SS |
2224 | It must insert breakpoints at each possible destinations of the next |
2225 | instruction. See @code{sparc-tdep.c} and @code{rs6000-tdep.c} | |
2226 | for examples. | |
2227 | ||
493cf018 JG |
2228 | @item NUMERIC_REG_NAMES |
2229 | mips-tdep.c | |
2230 | @item N_SETV | |
2231 | dbxread.c | |
2232 | @item N_SET_MAGIC | |
2233 | hppabsd-tdep.c | |
493cf018 JG |
2234 | @item ONE_PROCESS_WRITETEXT |
2235 | breakpoint.c | |
493cf018 JG |
2236 | @item PCC_SOL_BROKEN |
2237 | dbxread.c | |
2238 | @item PC_IN_CALL_DUMMY | |
2239 | inferior.h | |
2240 | @item PC_LOAD_SEGMENT | |
2241 | stack.c | |
beb773f3 | 2242 | |
493cf018 | 2243 | @item PC_REGNUM |
beb773f3 SS |
2244 | If the program counter is kept in a register, then define this macro |
2245 | to be the number of that register. | |
2246 | This need be defined only if @code{TARGET_WRITE_PC} is not defined. | |
2247 | ||
2248 | @item NPC_REGNUM | |
2249 | The number of the ``next program counter'' register, if defined. | |
2250 | ||
2251 | @item NNPC_REGNUM | |
2252 | The number of the ``next next program counter'' register, if defined. | |
2253 | Currently, this is only defined for the Motorola 88K. | |
2254 | ||
493cf018 JG |
2255 | @item PRINT_RANDOM_SIGNAL |
2256 | infcmd.c | |
2257 | @item PRINT_REGISTER_HOOK | |
2258 | infcmd.c | |
54109914 | 2259 | |
493cf018 | 2260 | @item PRINT_TYPELESS_INTEGER |
54109914 FF |
2261 | This is an obscure substitute for @code{print_longest} that |
2262 | seems to have been defined for the Convex target. | |
2263 | ||
493cf018 JG |
2264 | @item PROCESS_LINENUMBER_HOOK |
2265 | buildsym.c | |
2266 | @item PROLOGUE_FIRSTLINE_OVERLAP | |
2267 | infrun.c | |
493cf018 JG |
2268 | @item PS_REGNUM |
2269 | parse.c | |
493cf018 JG |
2270 | @item PUSH_ARGUMENTS |
2271 | valops.c | |
2272 | @item REGISTER_BYTES | |
2273 | remote.c | |
54109914 | 2274 | |
493cf018 | 2275 | @item REGISTER_NAMES |
54109914 FF |
2276 | Define this to expand into an initializer of an array of strings. |
2277 | Each string is the name of a register. | |
2278 | [more detail] | |
2279 | ||
493cf018 JG |
2280 | @item REG_STACK_SEGMENT |
2281 | exec.c | |
2282 | @item REG_STRUCT_HAS_ADDR | |
2283 | findvar.c | |
493cf018 JG |
2284 | @item R_FP |
2285 | dwarfread.c | |
2286 | @item R_OK | |
2287 | xm-altos.h | |
cdc647da | 2288 | |
493cf018 | 2289 | @item SDB_REG_TO_REGNUM |
cdc647da | 2290 | Define this to convert sdb register numbers |
beb773f3 | 2291 | into GDB regnums. If not defined, no conversion will be done. |
cdc647da | 2292 | |
493cf018 JG |
2293 | @item SEEK_END |
2294 | state.c | |
2295 | @item SEEK_SET | |
2296 | state.c | |
2297 | @item SEM | |
2298 | coffread.c | |
493cf018 JG |
2299 | @item SHELL_COMMAND_CONCAT |
2300 | infrun.c | |
2301 | @item SHELL_FILE | |
2302 | infrun.c | |
2303 | @item SHIFT_INST_REGS | |
2304 | breakpoint.c | |
493cf018 JG |
2305 | @item SIGTRAP_STOP_AFTER_LOAD |
2306 | infrun.c | |
cdc647da | 2307 | |
493cf018 | 2308 | @item SKIP_PROLOGUE |
cdc647da SS |
2309 | A C statement that advances the PC across any function entry |
2310 | prologue instructions so as to reach ``real'' code. | |
2311 | ||
493cf018 | 2312 | @item SKIP_PROLOGUE_FRAMELESS_P |
cdc647da SS |
2313 | A C statement that should behave similarly, but that can stop |
2314 | as soon as the function is known to have a frame. | |
2315 | If not defined, @code{SKIP_PROLOGUE} will be used instead. | |
2316 | ||
beb773f3 SS |
2317 | @item SKIP_TRAMPOLINE_CODE (pc) |
2318 | If the target machine has trampoline code that sits between callers | |
2319 | and the functions being called, then define this macro to return | |
2320 | a new PC that is at the start of the real function. | |
2321 | ||
493cf018 JG |
2322 | @item SP_REGNUM |
2323 | parse.c | |
cdc647da | 2324 | |
493cf018 | 2325 | @item STAB_REG_TO_REGNUM |
cdc647da | 2326 | Define this to convert stab register numbers (as gotten from `r' declarations) |
beb773f3 | 2327 | into GDB regnums. If not defined, no conversion will be done. |
cdc647da | 2328 | |
493cf018 JG |
2329 | @item STACK_ALIGN |
2330 | valops.c | |
493cf018 JG |
2331 | @item STOP_SIGNAL |
2332 | main.c | |
cdc647da SS |
2333 | |
2334 | @item STORE_RETURN_VALUE (type, valbuf) | |
2335 | A C expression that stores a function return value of type @var{type}, | |
2336 | where @var{valbuf} is the address of the value to be stored. | |
2337 | ||
493cf018 JG |
2338 | @item SUN4_COMPILER_FEATURE |
2339 | infrun.c | |
2340 | @item SUN_FIXED_LBRAC_BUG | |
2341 | dbxread.c | |
2342 | @item SVR4_SHARED_LIBS | |
2343 | solib.c | |
493cf018 JG |
2344 | @item SYMBOL_RELOADING_DEFAULT |
2345 | symfile.c | |
cdc647da | 2346 | |
493cf018 | 2347 | @item TARGET_BYTE_ORDER |
cdc647da SS |
2348 | The ordering of bytes in the target. |
2349 | This must be defined to be either @code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}. | |
2350 | ||
493cf018 | 2351 | @item TARGET_CHAR_BIT |
cdc647da SS |
2352 | Number of bits in a char; defaults to 8. |
2353 | ||
493cf018 | 2354 | @item TARGET_COMPLEX_BIT |
cdc647da SS |
2355 | Number of bits in a complex number; defaults to @code{2 * TARGET_FLOAT_BIT}. |
2356 | ||
493cf018 | 2357 | @item TARGET_DOUBLE_BIT |
cdc647da SS |
2358 | Number of bits in a double float; defaults to @code{8 * TARGET_CHAR_BIT}. |
2359 | ||
493cf018 | 2360 | @item TARGET_DOUBLE_COMPLEX_BIT |
cdc647da SS |
2361 | Number of bits in a double complex; defaults to @code{2 * TARGET_DOUBLE_BIT}. |
2362 | ||
493cf018 | 2363 | @item TARGET_FLOAT_BIT |
cdc647da SS |
2364 | Number of bits in a float; defaults to @code{4 * TARGET_CHAR_BIT}. |
2365 | ||
493cf018 | 2366 | @item TARGET_INT_BIT |
cdc647da SS |
2367 | Number of bits in an integer; defaults to @code{4 * TARGET_CHAR_BIT}. |
2368 | ||
493cf018 | 2369 | @item TARGET_LONG_BIT |
cdc647da SS |
2370 | Number of bits in a long integer; defaults to @code{4 * TARGET_CHAR_BIT}. |
2371 | ||
493cf018 | 2372 | @item TARGET_LONG_DOUBLE_BIT |
cdc647da SS |
2373 | Number of bits in a long double float; |
2374 | defaults to @code{2 * TARGET_DOUBLE_BIT}. | |
2375 | ||
493cf018 | 2376 | @item TARGET_LONG_LONG_BIT |
cdc647da SS |
2377 | Number of bits in a long long integer; defaults to @code{2 * TARGET_LONG_BIT}. |
2378 | ||
493cf018 | 2379 | @item TARGET_PTR_BIT |
cdc647da SS |
2380 | Number of bits in a pointer; defaults to @code{TARGET_INT_BIT}. |
2381 | ||
2382 | @item TARGET_SHORT_BIT | |
2383 | Number of bits in a short integer; defaults to @code{2 * TARGET_CHAR_BIT}. | |
2384 | ||
238ffce0 | 2385 | @item TARGET_READ_PC |
beb773f3 | 2386 | @item TARGET_WRITE_PC (val, pid) |
238ffce0 JG |
2387 | @item TARGET_READ_SP |
2388 | @item TARGET_WRITE_SP | |
2389 | @item TARGET_READ_FP | |
2390 | @item TARGET_WRITE_FP | |
2391 | These change the behavior of @code{read_pc}, @code{write_pc}, | |
2392 | @code{read_sp}, @code{write_sp}, @code{read_fp} and @code{write_fp}. | |
2393 | For most targets, these may be left undefined. GDB will call the | |
2394 | read and write register functions with the relevant @code{_REGNUM} argument. | |
2395 | ||
2396 | These macros are useful when a target keeps one of these registers in a | |
2397 | hard to get at place; for example, part in a segment register and part | |
2398 | in an ordinary register. | |
2399 | ||
beb773f3 SS |
2400 | @item USE_STRUCT_CONVENTION (gcc_p, type) |
2401 | If defined, this must be an expression that is nonzero if a value | |
2402 | of the given @var{type} being returned from a function must have | |
2403 | space allocated for it on the stack. @var{gcc_p} is true if the | |
2404 | function being considered is known to have been compiled by GCC; | |
2405 | this is helpful for systems where GCC is known to use different calling | |
2406 | convention than other compilers. | |
2407 | ||
2408 | @item VARIABLES_INSIDE_BLOCK (desc, gcc_p) | |
2409 | For dbx-style debugging information, if the compiler puts variable | |
2410 | declarations inside LBRAC/RBRAC blocks, this should be defined | |
2411 | to be nonzero. @var{desc} is the value of @code{n_desc} from the | |
2412 | @code{N_RBRAC} symbol, and @var{gcc_p} is true if GDB has noticed | |
2413 | the presence of either the @code{GCC_COMPILED_SYMBOL} or the | |
2414 | @code{GCC2_COMPILED_SYMBOL}. | |
2415 | By default, this is 0. | |
2416 | ||
2417 | @item OS9K_VARIABLES_INSIDE_BLOCK (desc, gcc_p) | |
2418 | Similarly, for OS/9000. Defaults to 1. | |
2419 | ||
493cf018 JG |
2420 | @item WRS_ORIG |
2421 | remote-vx.c | |
cdc647da | 2422 | |
493cf018 | 2423 | @item test |
cdc647da SS |
2424 | (Define this to enable testing code in regex.c.) |
2425 | ||
493cf018 JG |
2426 | @end table |
2427 | ||
beb773f3 SS |
2428 | Motorola M68K target conditionals. |
2429 | ||
54109914 | 2430 | @table @code |
beb773f3 SS |
2431 | |
2432 | @item BPT_VECTOR | |
2433 | Define this to be the 4-bit location of the breakpoint trap vector. | |
2434 | If not defined, it will default to @code{0xf}. | |
2435 | ||
2436 | @item REMOTE_BPT_VECTOR | |
2437 | Defaults to @code{1}. | |
2438 | ||
2439 | @end table | |
2440 | ||
b517f124 | 2441 | @node Native Conditionals |
968720bf RP |
2442 | @chapter Native Conditionals |
2443 | ||
b517f124 JG |
2444 | When GDB is configured and compiled, various macros are defined or left |
2445 | undefined, to control compilation when the host and target systems | |
2446 | are the same. These macros should be defined (or left undefined) | |
2447 | in @file{nm-@var{system}.h}. | |
968720bf | 2448 | |
1b87a1b2 | 2449 | @table @code |
cdc647da | 2450 | |
968720bf | 2451 | @item ATTACH_DETACH |
beb773f3 | 2452 | If defined, then GDB will include support for the @code{attach} and |
968720bf | 2453 | @code{detach} commands. |
cdc647da | 2454 | |
54109914 FF |
2455 | @item CHILD_PREPARE_TO_STORE |
2456 | If the machine stores all registers at once in the child process, | |
2457 | then define this to ensure that all values are correct. | |
2458 | This usually entails a read from the child. | |
2459 | ||
2460 | [Note that this is incorrectly defined in @file{xm-@var{system}.h} | |
2461 | files currently.] | |
2462 | ||
968720bf RP |
2463 | @item FETCH_INFERIOR_REGISTERS |
2464 | Define this if the native-dependent code will provide its | |
2465 | own routines | |
2466 | @code{fetch_inferior_registers} and @code{store_inferior_registers} in | |
2467 | @file{@var{HOST}-nat.c}. | |
f8f37439 DZ |
2468 | If this symbol is @emph{not} defined, and @file{infptrace.c} |
2469 | is included in this configuration, the default routines in | |
968720bf | 2470 | @file{infptrace.c} are used for these functions. |
cdc647da | 2471 | |
c3bbca3a JG |
2472 | @item GET_LONGJMP_TARGET |
2473 | For most machines, this is a target-dependent parameter. On the DECstation | |
2474 | and the Iris, this is a native-dependent parameter, since <setjmp.h> is | |
2475 | needed to define it. | |
2476 | ||
2477 | This macro determines the target PC address that longjmp() will jump | |
2478 | to, assuming that we have just stopped at a longjmp breakpoint. It | |
2479 | takes a CORE_ADDR * as argument, and stores the target PC value through | |
2480 | this pointer. It examines the current state of the machine as needed. | |
cdc647da | 2481 | |
968720bf RP |
2482 | @item PROC_NAME_FMT |
2483 | Defines the format for the name of a @file{/proc} device. Should be | |
2484 | defined in @file{nm.h} @emph{only} in order to override the default | |
2485 | definition in @file{procfs.c}. | |
cdc647da | 2486 | |
9729ef22 JK |
2487 | @item PTRACE_FP_BUG |
2488 | mach386-xdep.c | |
cdc647da | 2489 | |
9729ef22 JK |
2490 | @item PTRACE_ARG3_TYPE |
2491 | The type of the third argument to the @code{ptrace} system call, if it exists | |
2492 | and is different from @code{int}. | |
cdc647da | 2493 | |
968720bf RP |
2494 | @item REGISTER_U_ADDR |
2495 | Defines the offset of the registers in the ``u area''; @pxref{Host}. | |
cdc647da | 2496 | |
beb773f3 SS |
2497 | @item SOLIB_ADD (filename, from_tty, targ) |
2498 | Define this to expand into an expression that will cause the symbols | |
2499 | in @var{filename} to be added to GDB's symbol table. | |
2500 | ||
cdc647da SS |
2501 | @item SOLIB_CREATE_INFERIOR_HOOK |
2502 | Define this to expand into any shared-library-relocation code | |
2503 | that you want to be run just after the child process has been forked. | |
2504 | ||
54109914 FF |
2505 | @item START_INFERIOR_TRAPS_EXPECTED |
2506 | When starting an inferior, GDB normally expects to trap twice; | |
2507 | once when the shell execs, and once when the program itself execs. | |
2508 | If the actual number of traps is something other than 2, then | |
2509 | define this macro to expand into the number expected. | |
2510 | ||
968720bf | 2511 | @item USE_PROC_FS |
f8f37439 DZ |
2512 | This determines whether small routines in @file{*-tdep.c}, which |
2513 | translate register values | |
2514 | between GDB's internal representation and the /proc representation, | |
2515 | are compiled. | |
cdc647da | 2516 | |
968720bf RP |
2517 | @item U_REGS_OFFSET |
2518 | This is the offset of the registers in the upage. It need only be | |
2519 | defined if the generic ptrace register access routines in | |
2520 | @file{infptrace.c} are being used (that is, | |
f8f37439 | 2521 | @file{infptrace.c} is configured in, and |
968720bf RP |
2522 | @code{FETCH_INFERIOR_REGISTERS} is not defined). If the default value |
2523 | from @file{infptrace.c} is good enough, leave it undefined. | |
2524 | ||
2525 | The default value means that u.u_ar0 @emph{points to} the location of the | |
2526 | registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means that | |
2527 | u.u_ar0 @emph{is} the location of the registers. | |
cdc647da | 2528 | |
54109914 FF |
2529 | @item CLEAR_SOLIB |
2530 | objfiles.c | |
2531 | ||
2532 | @item DEBUG_PTRACE | |
2533 | Define this to debug ptrace calls. | |
2534 | ||
968720bf RP |
2535 | @end table |
2536 | ||
b517f124 JG |
2537 | @node Obsolete Conditionals |
2538 | @chapter Obsolete Conditionals | |
2539 | ||
2540 | Fragments of old code in GDB sometimes reference or set the following | |
2541 | configuration macros. They should not be used by new code, and | |
2542 | old uses should be removed as those parts of the debugger are | |
2543 | otherwise touched. | |
2544 | ||
2545 | @table @code | |
54109914 | 2546 | |
b517f124 JG |
2547 | @item STACK_END_ADDR |
2548 | This macro used to define where the end of the stack appeared, for use | |
2549 | in interpreting core file formats that don't record this address in the | |
2550 | core file itself. This information is now configured in BFD, and GDB | |
2551 | gets the info portably from there. The values in GDB's configuration | |
2552 | files should be moved into BFD configuration files (if needed there), | |
2553 | and deleted from all of GDB's config files. | |
2554 | ||
2555 | Any @file{@var{foo}-xdep.c} file that references STACK_END_ADDR | |
2556 | is so old that it has never been converted to use BFD. Now that's old! | |
54109914 | 2557 | |
b517f124 | 2558 | @end table |
9729ef22 JK |
2559 | |
2560 | @node XCOFF | |
2561 | @chapter The XCOFF Object File Format | |
2562 | ||
2563 | The IBM RS/6000 running AIX uses an object file format called xcoff. | |
2564 | The COFF sections, symbols, and line numbers are used, but debugging | |
2565 | symbols are dbx-style stabs whose strings are located in the | |
238ffce0 JG |
2566 | @samp{.debug} section (rather than the string table). For more |
2567 | information, @xref{Top,,,stabs,The Stabs Debugging Format}, and search | |
2568 | for XCOFF. | |
9729ef22 JK |
2569 | |
2570 | The shared library scheme has a nice clean interface for figuring out | |
2571 | what shared libraries are in use, but the catch is that everything which | |
2572 | refers to addresses (symbol tables and breakpoints at least) needs to be | |
2573 | relocated for both shared libraries and the main executable. At least | |
2574 | using the standard mechanism this can only be done once the program has | |
2575 | been run (or the core file has been read). | |
2576 | ||
ca714d03 RP |
2577 | @contents |
2578 | @bye |