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