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