Commit | Line | Data |
---|---|---|
9742079a | 1 | \input texinfo @c -*- texinfo -*- |
c906108c | 2 | @setfilename gdbint.info |
25822942 | 3 | @include gdb-cfg.texi |
1eb7cd77 JB |
4 | @settitle @value{GDBN} Internals |
5 | @setchapternewpage off | |
03727ca6 | 6 | @dircategory Software development |
e9c75b65 | 7 | @direntry |
c906108c | 8 | * Gdb-Internals: (gdbint). The GNU debugger's internals. |
e9c75b65 | 9 | @end direntry |
c906108c | 10 | |
a67ec3f4 | 11 | @copying |
28e7fd62 | 12 | Copyright @copyright{} 1990-2013 Free Software Foundation, Inc. |
c906108c SS |
13 | Contributed by Cygnus Solutions. Written by John Gilmore. |
14 | Second Edition by Stan Shebs. | |
15 | ||
e9c75b65 | 16 | Permission is granted to copy, distribute and/or modify this document |
4f5d9f07 | 17 | under the terms of the GNU Free Documentation License, Version 1.3 or |
2a6585f0 | 18 | any later version published by the Free Software Foundation; with no |
e5249f67 AC |
19 | Invariant Sections, with no Front-Cover Texts, and with no Back-Cover |
20 | Texts. A copy of the license is included in the section entitled ``GNU | |
21 | Free Documentation License''. | |
a67ec3f4 JM |
22 | @end copying |
23 | ||
24 | @ifnottex | |
25 | This file documents the internals of the GNU debugger @value{GDBN}. | |
26 | ||
27 | @insertcopying | |
28 | @end ifnottex | |
c906108c | 29 | |
055855a4 | 30 | @syncodeindex vr fn |
56caf160 | 31 | |
c906108c | 32 | @titlepage |
25822942 | 33 | @title @value{GDBN} Internals |
984359d2 | 34 | @subtitle A guide to the internals of the GNU debugger |
c906108c SS |
35 | @author John Gilmore |
36 | @author Cygnus Solutions | |
37 | @author Second Edition: | |
38 | @author Stan Shebs | |
39 | @author Cygnus Solutions | |
40 | @page | |
41 | @tex | |
42 | \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$ | |
43 | \xdef\manvers{\$Revision$} % For use in headers, footers too | |
44 | {\parskip=0pt | |
45 | \hfill Cygnus Solutions\par | |
46 | \hfill \manvers\par | |
47 | \hfill \TeX{}info \texinfoversion\par | |
48 | } | |
49 | @end tex | |
50 | ||
51 | @vskip 0pt plus 1filll | |
a67ec3f4 | 52 | @insertcopying |
c906108c SS |
53 | @end titlepage |
54 | ||
449f3b6c | 55 | @contents |
449f3b6c | 56 | |
c906108c SS |
57 | @node Top |
58 | @c Perhaps this should be the title of the document (but only for info, | |
59 | @c not for TeX). Existing GNU manuals seem inconsistent on this point. | |
60 | @top Scope of this Document | |
61 | ||
25822942 DB |
62 | This document documents the internals of the GNU debugger, @value{GDBN}. It |
63 | includes description of @value{GDBN}'s key algorithms and operations, as well | |
64 | as the mechanisms that adapt @value{GDBN} to specific hosts and targets. | |
c906108c SS |
65 | |
66 | @menu | |
587afa38 | 67 | * Summary:: |
c906108c SS |
68 | * Overall Structure:: |
69 | * Algorithms:: | |
70 | * User Interface:: | |
89437448 | 71 | * libgdb:: |
5f5233d4 | 72 | * Values:: |
669fac23 | 73 | * Stack Frames:: |
c906108c SS |
74 | * Symbol Handling:: |
75 | * Language Support:: | |
76 | * Host Definition:: | |
77 | * Target Architecture Definition:: | |
123dc839 | 78 | * Target Descriptions:: |
c906108c SS |
79 | * Target Vector Definition:: |
80 | * Native Debugging:: | |
81 | * Support Libraries:: | |
a0e0ffdf DE |
82 | * Coding Standards:: |
83 | * Misc Guidelines:: | |
c906108c | 84 | * Porting GDB:: |
d52fe014 | 85 | * Versions and Branches:: |
55f6ca0f | 86 | * Start of New Year Procedure:: |
8973da3a | 87 | * Releasing GDB:: |
085dd6e6 | 88 | * Testsuite:: |
c906108c | 89 | * Hints:: |
aab4e0ec | 90 | |
bcd7e15f | 91 | * GDB Observers:: @value{GDBN} Currently available observers |
aab4e0ec | 92 | * GNU Free Documentation License:: The license for this documentation |
055855a4 EZ |
93 | * Concept Index:: |
94 | * Function and Variable Index:: | |
c906108c SS |
95 | @end menu |
96 | ||
587afa38 EZ |
97 | @node Summary |
98 | @chapter Summary | |
99 | ||
100 | @menu | |
101 | * Requirements:: | |
102 | * Contributors:: | |
103 | @end menu | |
c906108c | 104 | |
587afa38 EZ |
105 | @node Requirements |
106 | @section Requirements | |
56caf160 | 107 | @cindex requirements for @value{GDBN} |
c906108c SS |
108 | |
109 | Before diving into the internals, you should understand the formal | |
56caf160 EZ |
110 | requirements and other expectations for @value{GDBN}. Although some |
111 | of these may seem obvious, there have been proposals for @value{GDBN} | |
112 | that have run counter to these requirements. | |
c906108c | 113 | |
56caf160 EZ |
114 | First of all, @value{GDBN} is a debugger. It's not designed to be a |
115 | front panel for embedded systems. It's not a text editor. It's not a | |
116 | shell. It's not a programming environment. | |
c906108c | 117 | |
56caf160 EZ |
118 | @value{GDBN} is an interactive tool. Although a batch mode is |
119 | available, @value{GDBN}'s primary role is to interact with a human | |
120 | programmer. | |
c906108c | 121 | |
56caf160 EZ |
122 | @value{GDBN} should be responsive to the user. A programmer hot on |
123 | the trail of a nasty bug, and operating under a looming deadline, is | |
124 | going to be very impatient of everything, including the response time | |
125 | to debugger commands. | |
c906108c | 126 | |
56caf160 EZ |
127 | @value{GDBN} should be relatively permissive, such as for expressions. |
128 | While the compiler should be picky (or have the option to be made | |
be9c6c35 | 129 | picky), since source code lives for a long time usually, the |
56caf160 EZ |
130 | programmer doing debugging shouldn't be spending time figuring out to |
131 | mollify the debugger. | |
c906108c | 132 | |
56caf160 EZ |
133 | @value{GDBN} will be called upon to deal with really large programs. |
134 | Executable sizes of 50 to 100 megabytes occur regularly, and we've | |
135 | heard reports of programs approaching 1 gigabyte in size. | |
c906108c | 136 | |
56caf160 EZ |
137 | @value{GDBN} should be able to run everywhere. No other debugger is |
138 | available for even half as many configurations as @value{GDBN} | |
139 | supports. | |
c906108c | 140 | |
587afa38 EZ |
141 | @node Contributors |
142 | @section Contributors | |
143 | ||
144 | The first edition of this document was written by John Gilmore of | |
145 | Cygnus Solutions. The current second edition was written by Stan Shebs | |
146 | of Cygnus Solutions, who continues to update the manual. | |
147 | ||
148 | Over the years, many others have made additions and changes to this | |
149 | document. This section attempts to record the significant contributors | |
150 | to that effort. One of the virtues of free software is that everyone | |
151 | is free to contribute to it; with regret, we cannot actually | |
152 | acknowledge everyone here. | |
153 | ||
154 | @quotation | |
155 | @emph{Plea:} This section has only been added relatively recently (four | |
156 | years after publication of the second edition). Additions to this | |
157 | section are particularly welcome. If you or your friends (or enemies, | |
158 | to be evenhanded) have been unfairly omitted from this list, we would | |
159 | like to add your names! | |
160 | @end quotation | |
161 | ||
162 | A document such as this relies on being kept up to date by numerous | |
163 | small updates by contributing engineers as they make changes to the | |
164 | code base. The file @file{ChangeLog} in the @value{GDBN} distribution | |
165 | approximates a blow-by-blow account. The most prolific contributors to | |
166 | this important, but low profile task are Andrew Cagney (responsible | |
167 | for over half the entries), Daniel Jacobowitz, Mark Kettenis, Jim | |
168 | Blandy and Eli Zaretskii. | |
169 | ||
170 | Eli Zaretskii and Daniel Jacobowitz wrote the sections documenting | |
171 | watchpoints. | |
172 | ||
173 | Jeremy Bennett updated the sections on initializing a new architecture | |
174 | and register representation, and added the section on Frame Interpretation. | |
175 | ||
c906108c SS |
176 | |
177 | @node Overall Structure | |
178 | ||
179 | @chapter Overall Structure | |
180 | ||
56caf160 EZ |
181 | @value{GDBN} consists of three major subsystems: user interface, |
182 | symbol handling (the @dfn{symbol side}), and target system handling (the | |
183 | @dfn{target side}). | |
c906108c | 184 | |
2e685b93 | 185 | The user interface consists of several actual interfaces, plus |
c906108c SS |
186 | supporting code. |
187 | ||
188 | The symbol side consists of object file readers, debugging info | |
189 | interpreters, symbol table management, source language expression | |
190 | parsing, type and value printing. | |
191 | ||
192 | The target side consists of execution control, stack frame analysis, and | |
193 | physical target manipulation. | |
194 | ||
195 | The target side/symbol side division is not formal, and there are a | |
196 | number of exceptions. For instance, core file support involves symbolic | |
197 | elements (the basic core file reader is in BFD) and target elements (it | |
198 | supplies the contents of memory and the values of registers). Instead, | |
199 | this division is useful for understanding how the minor subsystems | |
200 | should fit together. | |
201 | ||
202 | @section The Symbol Side | |
203 | ||
56caf160 EZ |
204 | The symbolic side of @value{GDBN} can be thought of as ``everything |
205 | you can do in @value{GDBN} without having a live program running''. | |
206 | For instance, you can look at the types of variables, and evaluate | |
207 | many kinds of expressions. | |
c906108c SS |
208 | |
209 | @section The Target Side | |
210 | ||
56caf160 EZ |
211 | The target side of @value{GDBN} is the ``bits and bytes manipulator''. |
212 | Although it may make reference to symbolic info here and there, most | |
213 | of the target side will run with only a stripped executable | |
214 | available---or even no executable at all, in remote debugging cases. | |
c906108c SS |
215 | |
216 | Operations such as disassembly, stack frame crawls, and register | |
217 | display, are able to work with no symbolic info at all. In some cases, | |
25822942 | 218 | such as disassembly, @value{GDBN} will use symbolic info to present addresses |
c906108c SS |
219 | relative to symbols rather than as raw numbers, but it will work either |
220 | way. | |
221 | ||
222 | @section Configurations | |
223 | ||
56caf160 EZ |
224 | @cindex host |
225 | @cindex target | |
25822942 | 226 | @dfn{Host} refers to attributes of the system where @value{GDBN} runs. |
c906108c SS |
227 | @dfn{Target} refers to the system where the program being debugged |
228 | executes. In most cases they are the same machine, in which case a | |
229 | third type of @dfn{Native} attributes come into play. | |
230 | ||
1f70da6a SS |
231 | Defines and include files needed to build on the host are host |
232 | support. Examples are tty support, system defined types, host byte | |
233 | order, host float format. These are all calculated by @code{autoconf} | |
234 | when the debugger is built. | |
c906108c SS |
235 | |
236 | Defines and information needed to handle the target format are target | |
237 | dependent. Examples are the stack frame format, instruction set, | |
238 | breakpoint instruction, registers, and how to set up and tear down the stack | |
239 | to call a function. | |
240 | ||
241 | Information that is only needed when the host and target are the same, | |
242 | is native dependent. One example is Unix child process support; if the | |
1f70da6a | 243 | host and target are not the same, calling @code{fork} to start the target |
c906108c SS |
244 | process is a bad idea. The various macros needed for finding the |
245 | registers in the @code{upage}, running @code{ptrace}, and such are all | |
246 | in the native-dependent files. | |
247 | ||
248 | Another example of native-dependent code is support for features that | |
249 | are really part of the target environment, but which require | |
250 | @code{#include} files that are only available on the host system. Core | |
251 | file handling and @code{setjmp} handling are two common cases. | |
252 | ||
1f70da6a SS |
253 | When you want to make @value{GDBN} work as the traditional native debugger |
254 | on a system, you will need to supply both target and native information. | |
c906108c | 255 | |
25ab7e6d EZ |
256 | @section Source Tree Structure |
257 | @cindex @value{GDBN} source tree structure | |
258 | ||
259 | The @value{GDBN} source directory has a mostly flat structure---there | |
260 | are only a few subdirectories. A file's name usually gives a hint as | |
261 | to what it does; for example, @file{stabsread.c} reads stabs, | |
7ce59000 | 262 | @file{dwarf2read.c} reads @sc{DWARF 2}, etc. |
25ab7e6d EZ |
263 | |
264 | Files that are related to some common task have names that share | |
265 | common substrings. For example, @file{*-thread.c} files deal with | |
266 | debugging threads on various platforms; @file{*read.c} files deal with | |
267 | reading various kinds of symbol and object files; @file{inf*.c} files | |
268 | deal with direct control of the @dfn{inferior program} (@value{GDBN} | |
269 | parlance for the program being debugged). | |
270 | ||
271 | There are several dozens of files in the @file{*-tdep.c} family. | |
272 | @samp{tdep} stands for @dfn{target-dependent code}---each of these | |
273 | files implements debug support for a specific target architecture | |
274 | (sparc, mips, etc). Usually, only one of these will be used in a | |
275 | specific @value{GDBN} configuration (sometimes two, closely related). | |
276 | ||
277 | Similarly, there are many @file{*-nat.c} files, each one for native | |
278 | debugging on a specific system (e.g., @file{sparc-linux-nat.c} is for | |
279 | native debugging of Sparc machines running the Linux kernel). | |
280 | ||
281 | The few subdirectories of the source tree are: | |
282 | ||
283 | @table @file | |
284 | @item cli | |
285 | Code that implements @dfn{CLI}, the @value{GDBN} Command-Line | |
286 | Interpreter. @xref{User Interface, Command Interpreter}. | |
287 | ||
288 | @item gdbserver | |
289 | Code for the @value{GDBN} remote server. | |
290 | ||
291 | @item gdbtk | |
292 | Code for Insight, the @value{GDBN} TK-based GUI front-end. | |
293 | ||
294 | @item mi | |
295 | The @dfn{GDB/MI}, the @value{GDBN} Machine Interface interpreter. | |
296 | ||
297 | @item signals | |
298 | Target signal translation code. | |
299 | ||
300 | @item tui | |
301 | Code for @dfn{TUI}, the @value{GDBN} Text-mode full-screen User | |
302 | Interface. @xref{User Interface, TUI}. | |
303 | @end table | |
c906108c SS |
304 | |
305 | @node Algorithms | |
306 | ||
307 | @chapter Algorithms | |
56caf160 | 308 | @cindex algorithms |
c906108c | 309 | |
56caf160 EZ |
310 | @value{GDBN} uses a number of debugging-specific algorithms. They are |
311 | often not very complicated, but get lost in the thicket of special | |
312 | cases and real-world issues. This chapter describes the basic | |
313 | algorithms and mentions some of the specific target definitions that | |
314 | they use. | |
c906108c | 315 | |
7d30c22d JB |
316 | @section Prologue Analysis |
317 | ||
318 | @cindex prologue analysis | |
319 | @cindex call frame information | |
320 | @cindex CFI (call frame information) | |
321 | To produce a backtrace and allow the user to manipulate older frames' | |
322 | variables and arguments, @value{GDBN} needs to find the base addresses | |
323 | of older frames, and discover where those frames' registers have been | |
324 | saved. Since a frame's ``callee-saves'' registers get saved by | |
325 | younger frames if and when they're reused, a frame's registers may be | |
326 | scattered unpredictably across younger frames. This means that | |
327 | changing the value of a register-allocated variable in an older frame | |
328 | may actually entail writing to a save slot in some younger frame. | |
329 | ||
330 | Modern versions of GCC emit Dwarf call frame information (``CFI''), | |
331 | which describes how to find frame base addresses and saved registers. | |
332 | But CFI is not always available, so as a fallback @value{GDBN} uses a | |
333 | technique called @dfn{prologue analysis} to find frame sizes and saved | |
334 | registers. A prologue analyzer disassembles the function's machine | |
335 | code starting from its entry point, and looks for instructions that | |
336 | allocate frame space, save the stack pointer in a frame pointer | |
337 | register, save registers, and so on. Obviously, this can't be done | |
b247355e | 338 | accurately in general, but it's tractable to do well enough to be very |
7d30c22d JB |
339 | helpful. Prologue analysis predates the GNU toolchain's support for |
340 | CFI; at one time, prologue analysis was the only mechanism | |
341 | @value{GDBN} used for stack unwinding at all, when the function | |
342 | calling conventions didn't specify a fixed frame layout. | |
343 | ||
344 | In the olden days, function prologues were generated by hand-written, | |
345 | target-specific code in GCC, and treated as opaque and untouchable by | |
346 | optimizers. Looking at this code, it was usually straightforward to | |
347 | write a prologue analyzer for @value{GDBN} that would accurately | |
348 | understand all the prologues GCC would generate. However, over time | |
349 | GCC became more aggressive about instruction scheduling, and began to | |
350 | understand more about the semantics of the prologue instructions | |
351 | themselves; in response, @value{GDBN}'s analyzers became more complex | |
352 | and fragile. Keeping the prologue analyzers working as GCC (and the | |
353 | instruction sets themselves) evolved became a substantial task. | |
354 | ||
355 | @cindex @file{prologue-value.c} | |
356 | @cindex abstract interpretation of function prologues | |
357 | @cindex pseudo-evaluation of function prologues | |
358 | To try to address this problem, the code in @file{prologue-value.h} | |
359 | and @file{prologue-value.c} provides a general framework for writing | |
360 | prologue analyzers that are simpler and more robust than ad-hoc | |
361 | analyzers. When we analyze a prologue using the prologue-value | |
362 | framework, we're really doing ``abstract interpretation'' or | |
363 | ``pseudo-evaluation'': running the function's code in simulation, but | |
364 | using conservative approximations of the values registers and memory | |
365 | would hold when the code actually runs. For example, if our function | |
366 | starts with the instruction: | |
367 | ||
368 | @example | |
369 | addi r1, 42 # add 42 to r1 | |
370 | @end example | |
371 | @noindent | |
372 | we don't know exactly what value will be in @code{r1} after executing | |
373 | this instruction, but we do know it'll be 42 greater than its original | |
374 | value. | |
375 | ||
376 | If we then see an instruction like: | |
377 | ||
378 | @example | |
379 | addi r1, 22 # add 22 to r1 | |
380 | @end example | |
381 | @noindent | |
382 | we still don't know what @code{r1's} value is, but again, we can say | |
383 | it is now 64 greater than its original value. | |
384 | ||
385 | If the next instruction were: | |
386 | ||
387 | @example | |
388 | mov r2, r1 # set r2 to r1's value | |
389 | @end example | |
390 | @noindent | |
391 | then we can say that @code{r2's} value is now the original value of | |
392 | @code{r1} plus 64. | |
393 | ||
394 | It's common for prologues to save registers on the stack, so we'll | |
395 | need to track the values of stack frame slots, as well as the | |
396 | registers. So after an instruction like this: | |
397 | ||
398 | @example | |
399 | mov (fp+4), r2 | |
400 | @end example | |
401 | @noindent | |
402 | then we'd know that the stack slot four bytes above the frame pointer | |
403 | holds the original value of @code{r1} plus 64. | |
404 | ||
405 | And so on. | |
406 | ||
407 | Of course, this can only go so far before it gets unreasonable. If we | |
408 | wanted to be able to say anything about the value of @code{r1} after | |
409 | the instruction: | |
410 | ||
411 | @example | |
412 | xor r1, r3 # exclusive-or r1 and r3, place result in r1 | |
413 | @end example | |
414 | @noindent | |
415 | then things would get pretty complex. But remember, we're just doing | |
416 | a conservative approximation; if exclusive-or instructions aren't | |
417 | relevant to prologues, we can just say @code{r1}'s value is now | |
418 | ``unknown''. We can ignore things that are too complex, if that loss of | |
419 | information is acceptable for our application. | |
420 | ||
421 | So when we say ``conservative approximation'' here, what we mean is an | |
422 | approximation that is either accurate, or marked ``unknown'', but | |
423 | never inaccurate. | |
424 | ||
425 | Using this framework, a prologue analyzer is simply an interpreter for | |
426 | machine code, but one that uses conservative approximations for the | |
427 | contents of registers and memory instead of actual values. Starting | |
428 | from the function's entry point, you simulate instructions up to the | |
429 | current PC, or an instruction that you don't know how to simulate. | |
430 | Now you can examine the state of the registers and stack slots you've | |
431 | kept track of. | |
432 | ||
433 | @itemize @bullet | |
434 | ||
435 | @item | |
436 | To see how large your stack frame is, just check the value of the | |
437 | stack pointer register; if it's the original value of the SP | |
438 | minus a constant, then that constant is the stack frame's size. | |
439 | If the SP's value has been marked as ``unknown'', then that means | |
440 | the prologue has done something too complex for us to track, and | |
441 | we don't know the frame size. | |
442 | ||
443 | @item | |
444 | To see where we've saved the previous frame's registers, we just | |
445 | search the values we've tracked --- stack slots, usually, but | |
446 | registers, too, if you want --- for something equal to the register's | |
447 | original value. If the calling conventions suggest a standard place | |
448 | to save a given register, then we can check there first, but really, | |
449 | anything that will get us back the original value will probably work. | |
450 | @end itemize | |
451 | ||
452 | This does take some work. But prologue analyzers aren't | |
453 | quick-and-simple pattern patching to recognize a few fixed prologue | |
454 | forms any more; they're big, hairy functions. Along with inferior | |
455 | function calls, prologue analysis accounts for a substantial portion | |
456 | of the time needed to stabilize a @value{GDBN} port. So it's | |
457 | worthwhile to look for an approach that will be easier to understand | |
458 | and maintain. In the approach described above: | |
459 | ||
460 | @itemize @bullet | |
461 | ||
462 | @item | |
463 | It's easier to see that the analyzer is correct: you just see | |
b247355e | 464 | whether the analyzer properly (albeit conservatively) simulates |
7d30c22d JB |
465 | the effect of each instruction. |
466 | ||
467 | @item | |
468 | It's easier to extend the analyzer: you can add support for new | |
469 | instructions, and know that you haven't broken anything that | |
470 | wasn't already broken before. | |
471 | ||
472 | @item | |
473 | It's orthogonal: to gather new information, you don't need to | |
474 | complicate the code for each instruction. As long as your domain | |
475 | of conservative values is already detailed enough to tell you | |
476 | what you need, then all the existing instruction simulations are | |
477 | already gathering the right data for you. | |
478 | ||
479 | @end itemize | |
480 | ||
481 | The file @file{prologue-value.h} contains detailed comments explaining | |
482 | the framework and how to use it. | |
483 | ||
484 | ||
c906108c SS |
485 | @section Breakpoint Handling |
486 | ||
56caf160 | 487 | @cindex breakpoints |
c906108c SS |
488 | In general, a breakpoint is a user-designated location in the program |
489 | where the user wants to regain control if program execution ever reaches | |
490 | that location. | |
491 | ||
492 | There are two main ways to implement breakpoints; either as ``hardware'' | |
493 | breakpoints or as ``software'' breakpoints. | |
494 | ||
56caf160 EZ |
495 | @cindex hardware breakpoints |
496 | @cindex program counter | |
c906108c SS |
497 | Hardware breakpoints are sometimes available as a builtin debugging |
498 | features with some chips. Typically these work by having dedicated | |
499 | register into which the breakpoint address may be stored. If the PC | |
56caf160 | 500 | (shorthand for @dfn{program counter}) |
c906108c | 501 | ever matches a value in a breakpoint registers, the CPU raises an |
56caf160 EZ |
502 | exception and reports it to @value{GDBN}. |
503 | ||
504 | Another possibility is when an emulator is in use; many emulators | |
505 | include circuitry that watches the address lines coming out from the | |
506 | processor, and force it to stop if the address matches a breakpoint's | |
507 | address. | |
508 | ||
509 | A third possibility is that the target already has the ability to do | |
510 | breakpoints somehow; for instance, a ROM monitor may do its own | |
511 | software breakpoints. So although these are not literally ``hardware | |
512 | breakpoints'', from @value{GDBN}'s point of view they work the same; | |
50e3ee83 | 513 | @value{GDBN} need not do anything more than set the breakpoint and wait |
56caf160 | 514 | for something to happen. |
c906108c SS |
515 | |
516 | Since they depend on hardware resources, hardware breakpoints may be | |
56caf160 | 517 | limited in number; when the user asks for more, @value{GDBN} will |
9742079a | 518 | start trying to set software breakpoints. (On some architectures, |
937f164b | 519 | notably the 32-bit x86 platforms, @value{GDBN} cannot always know |
9742079a EZ |
520 | whether there's enough hardware resources to insert all the hardware |
521 | breakpoints and watchpoints. On those platforms, @value{GDBN} prints | |
522 | an error message only when the program being debugged is continued.) | |
56caf160 EZ |
523 | |
524 | @cindex software breakpoints | |
525 | Software breakpoints require @value{GDBN} to do somewhat more work. | |
526 | The basic theory is that @value{GDBN} will replace a program | |
527 | instruction with a trap, illegal divide, or some other instruction | |
528 | that will cause an exception, and then when it's encountered, | |
529 | @value{GDBN} will take the exception and stop the program. When the | |
530 | user says to continue, @value{GDBN} will restore the original | |
c906108c SS |
531 | instruction, single-step, re-insert the trap, and continue on. |
532 | ||
533 | Since it literally overwrites the program being tested, the program area | |
be9c6c35 | 534 | must be writable, so this technique won't work on programs in ROM. It |
c906108c | 535 | can also distort the behavior of programs that examine themselves, |
56caf160 | 536 | although such a situation would be highly unusual. |
c906108c SS |
537 | |
538 | Also, the software breakpoint instruction should be the smallest size of | |
539 | instruction, so it doesn't overwrite an instruction that might be a jump | |
540 | target, and cause disaster when the program jumps into the middle of the | |
541 | breakpoint instruction. (Strictly speaking, the breakpoint must be no | |
542 | larger than the smallest interval between instructions that may be jump | |
543 | targets; perhaps there is an architecture where only even-numbered | |
544 | instructions may jumped to.) Note that it's possible for an instruction | |
545 | set not to have any instructions usable for a software breakpoint, | |
546 | although in practice only the ARC has failed to define such an | |
547 | instruction. | |
548 | ||
c906108c SS |
549 | Basic breakpoint object handling is in @file{breakpoint.c}. However, |
550 | much of the interesting breakpoint action is in @file{infrun.c}. | |
551 | ||
8181d85f DJ |
552 | @table @code |
553 | @cindex insert or remove software breakpoint | |
554 | @findex target_remove_breakpoint | |
555 | @findex target_insert_breakpoint | |
556 | @item target_remove_breakpoint (@var{bp_tgt}) | |
557 | @itemx target_insert_breakpoint (@var{bp_tgt}) | |
558 | Insert or remove a software breakpoint at address | |
559 | @code{@var{bp_tgt}->placed_address}. Returns zero for success, | |
560 | non-zero for failure. On input, @var{bp_tgt} contains the address of the | |
561 | breakpoint, and is otherwise initialized to zero. The fields of the | |
562 | @code{struct bp_target_info} pointed to by @var{bp_tgt} are updated | |
563 | to contain other information about the breakpoint on output. The field | |
564 | @code{placed_address} may be updated if the breakpoint was placed at a | |
565 | related address; the field @code{shadow_contents} contains the real | |
566 | contents of the bytes where the breakpoint has been inserted, | |
567 | if reading memory would return the breakpoint instead of the | |
568 | underlying memory; the field @code{shadow_len} is the length of | |
569 | memory cached in @code{shadow_contents}, if any; and the field | |
570 | @code{placed_size} is optionally set and used by the target, if | |
571 | it could differ from @code{shadow_len}. | |
572 | ||
573 | For example, the remote target @samp{Z0} packet does not require | |
574 | shadowing memory, so @code{shadow_len} is left at zero. However, | |
4a9bb1df | 575 | the length reported by @code{gdbarch_breakpoint_from_pc} is cached in |
8181d85f DJ |
576 | @code{placed_size}, so that a matching @samp{z0} packet can be |
577 | used to remove the breakpoint. | |
578 | ||
579 | @cindex insert or remove hardware breakpoint | |
580 | @findex target_remove_hw_breakpoint | |
581 | @findex target_insert_hw_breakpoint | |
582 | @item target_remove_hw_breakpoint (@var{bp_tgt}) | |
583 | @itemx target_insert_hw_breakpoint (@var{bp_tgt}) | |
584 | Insert or remove a hardware-assisted breakpoint at address | |
585 | @code{@var{bp_tgt}->placed_address}. Returns zero for success, | |
586 | non-zero for failure. See @code{target_insert_breakpoint} for | |
587 | a description of the @code{struct bp_target_info} pointed to by | |
588 | @var{bp_tgt}; the @code{shadow_contents} and | |
589 | @code{shadow_len} members are not used for hardware breakpoints, | |
590 | but @code{placed_size} may be. | |
591 | @end table | |
592 | ||
c906108c SS |
593 | @section Single Stepping |
594 | ||
595 | @section Signal Handling | |
596 | ||
597 | @section Thread Handling | |
598 | ||
599 | @section Inferior Function Calls | |
600 | ||
601 | @section Longjmp Support | |
602 | ||
56caf160 | 603 | @cindex @code{longjmp} debugging |
25822942 | 604 | @value{GDBN} has support for figuring out that the target is doing a |
c906108c SS |
605 | @code{longjmp} and for stopping at the target of the jump, if we are |
606 | stepping. This is done with a few specialized internal breakpoints, | |
56caf160 EZ |
607 | which are visible in the output of the @samp{maint info breakpoint} |
608 | command. | |
c906108c | 609 | |
4a9bb1df UW |
610 | @findex gdbarch_get_longjmp_target |
611 | To make this work, you need to define a function called | |
1f70da6a SS |
612 | @code{gdbarch_get_longjmp_target}, which will examine the |
613 | @code{jmp_buf} structure and extract the @code{longjmp} target address. | |
614 | Since @code{jmp_buf} is target specific and typically defined in a | |
615 | target header not available to @value{GDBN}, you will need to | |
616 | determine the offset of the PC manually and return that; many targets | |
617 | define a @code{jb_pc_offset} field in the tdep structure to save the | |
618 | value once calculated. | |
c906108c | 619 | |
9742079a EZ |
620 | @section Watchpoints |
621 | @cindex watchpoints | |
622 | ||
623 | Watchpoints are a special kind of breakpoints (@pxref{Algorithms, | |
624 | breakpoints}) which break when data is accessed rather than when some | |
625 | instruction is executed. When you have data which changes without | |
626 | your knowing what code does that, watchpoints are the silver bullet to | |
627 | hunt down and kill such bugs. | |
628 | ||
629 | @cindex hardware watchpoints | |
630 | @cindex software watchpoints | |
631 | Watchpoints can be either hardware-assisted or not; the latter type is | |
632 | known as ``software watchpoints.'' @value{GDBN} always uses | |
633 | hardware-assisted watchpoints if they are available, and falls back on | |
634 | software watchpoints otherwise. Typical situations where @value{GDBN} | |
635 | will use software watchpoints are: | |
636 | ||
637 | @itemize @bullet | |
638 | @item | |
639 | The watched memory region is too large for the underlying hardware | |
640 | watchpoint support. For example, each x86 debug register can watch up | |
641 | to 4 bytes of memory, so trying to watch data structures whose size is | |
642 | more than 16 bytes will cause @value{GDBN} to use software | |
643 | watchpoints. | |
644 | ||
645 | @item | |
646 | The value of the expression to be watched depends on data held in | |
647 | registers (as opposed to memory). | |
648 | ||
649 | @item | |
650 | Too many different watchpoints requested. (On some architectures, | |
651 | this situation is impossible to detect until the debugged program is | |
652 | resumed.) Note that x86 debug registers are used both for hardware | |
653 | breakpoints and for watchpoints, so setting too many hardware | |
654 | breakpoints might cause watchpoint insertion to fail. | |
655 | ||
656 | @item | |
657 | No hardware-assisted watchpoints provided by the target | |
658 | implementation. | |
659 | @end itemize | |
660 | ||
661 | Software watchpoints are very slow, since @value{GDBN} needs to | |
662 | single-step the program being debugged and test the value of the | |
663 | watched expression(s) after each instruction. The rest of this | |
664 | section is mostly irrelevant for software watchpoints. | |
665 | ||
b6b8ece6 EZ |
666 | When the inferior stops, @value{GDBN} tries to establish, among other |
667 | possible reasons, whether it stopped due to a watchpoint being hit. | |
d983da9c DJ |
668 | It first uses @code{STOPPED_BY_WATCHPOINT} to see if any watchpoint |
669 | was hit. If not, all watchpoint checking is skipped. | |
670 | ||
671 | Then @value{GDBN} calls @code{target_stopped_data_address} exactly | |
672 | once. This method returns the address of the watchpoint which | |
673 | triggered, if the target can determine it. If the triggered address | |
674 | is available, @value{GDBN} compares the address returned by this | |
675 | method with each watched memory address in each active watchpoint. | |
676 | For data-read and data-access watchpoints, @value{GDBN} announces | |
677 | every watchpoint that watches the triggered address as being hit. | |
678 | For this reason, data-read and data-access watchpoints | |
679 | @emph{require} that the triggered address be available; if not, read | |
680 | and access watchpoints will never be considered hit. For data-write | |
681 | watchpoints, if the triggered address is available, @value{GDBN} | |
682 | considers only those watchpoints which match that address; | |
683 | otherwise, @value{GDBN} considers all data-write watchpoints. For | |
684 | each data-write watchpoint that @value{GDBN} considers, it evaluates | |
685 | the expression whose value is being watched, and tests whether the | |
686 | watched value has changed. Watchpoints whose watched values have | |
687 | changed are announced as hit. | |
b6b8ece6 | 688 | |
1f70da6a SS |
689 | @c FIXME move these to the main lists of target/native defns |
690 | ||
9742079a EZ |
691 | @value{GDBN} uses several macros and primitives to support hardware |
692 | watchpoints: | |
693 | ||
694 | @table @code | |
9742079a EZ |
695 | @findex TARGET_CAN_USE_HARDWARE_WATCHPOINT |
696 | @item TARGET_CAN_USE_HARDWARE_WATCHPOINT (@var{type}, @var{count}, @var{other}) | |
697 | Return the number of hardware watchpoints of type @var{type} that are | |
698 | possible to be set. The value is positive if @var{count} watchpoints | |
699 | of this type can be set, zero if setting watchpoints of this type is | |
700 | not supported, and negative if @var{count} is more than the maximum | |
701 | number of watchpoints of type @var{type} that can be set. @var{other} | |
702 | is non-zero if other types of watchpoints are currently enabled (there | |
703 | are architectures which cannot set watchpoints of different types at | |
704 | the same time). | |
705 | ||
706 | @findex TARGET_REGION_OK_FOR_HW_WATCHPOINT | |
707 | @item TARGET_REGION_OK_FOR_HW_WATCHPOINT (@var{addr}, @var{len}) | |
708 | Return non-zero if hardware watchpoints can be used to watch a region | |
709 | whose address is @var{addr} and whose length in bytes is @var{len}. | |
710 | ||
b6b8ece6 | 711 | @cindex insert or remove hardware watchpoint |
9742079a EZ |
712 | @findex target_insert_watchpoint |
713 | @findex target_remove_watchpoint | |
714 | @item target_insert_watchpoint (@var{addr}, @var{len}, @var{type}) | |
715 | @itemx target_remove_watchpoint (@var{addr}, @var{len}, @var{type}) | |
716 | Insert or remove a hardware watchpoint starting at @var{addr}, for | |
717 | @var{len} bytes. @var{type} is the watchpoint type, one of the | |
718 | possible values of the enumerated data type @code{target_hw_bp_type}, | |
719 | defined by @file{breakpoint.h} as follows: | |
720 | ||
474c8240 | 721 | @smallexample |
9742079a EZ |
722 | enum target_hw_bp_type |
723 | @{ | |
724 | hw_write = 0, /* Common (write) HW watchpoint */ | |
725 | hw_read = 1, /* Read HW watchpoint */ | |
726 | hw_access = 2, /* Access (read or write) HW watchpoint */ | |
727 | hw_execute = 3 /* Execute HW breakpoint */ | |
728 | @}; | |
474c8240 | 729 | @end smallexample |
9742079a EZ |
730 | |
731 | @noindent | |
732 | These two macros should return 0 for success, non-zero for failure. | |
733 | ||
9742079a | 734 | @findex target_stopped_data_address |
ac77d04f JJ |
735 | @item target_stopped_data_address (@var{addr_p}) |
736 | If the inferior has some watchpoint that triggered, place the address | |
737 | associated with the watchpoint at the location pointed to by | |
d983da9c DJ |
738 | @var{addr_p} and return non-zero. Otherwise, return zero. This |
739 | is required for data-read and data-access watchpoints. It is | |
740 | not required for data-write watchpoints, but @value{GDBN} uses | |
741 | it to improve handling of those also. | |
742 | ||
743 | @value{GDBN} will only call this method once per watchpoint stop, | |
744 | immediately after calling @code{STOPPED_BY_WATCHPOINT}. If the | |
745 | target's watchpoint indication is sticky, i.e., stays set after | |
746 | resuming, this method should clear it. For instance, the x86 debug | |
747 | control register has sticky triggered flags. | |
9742079a | 748 | |
5009afc5 AS |
749 | @findex target_watchpoint_addr_within_range |
750 | @item target_watchpoint_addr_within_range (@var{target}, @var{addr}, @var{start}, @var{length}) | |
751 | Check whether @var{addr} (as returned by @code{target_stopped_data_address}) | |
752 | lies within the hardware-defined watchpoint region described by | |
753 | @var{start} and @var{length}. This only needs to be provided if the | |
754 | granularity of a watchpoint is greater than one byte, i.e., if the | |
755 | watchpoint can also trigger on nearby addresses outside of the watched | |
756 | region. | |
757 | ||
9742079a EZ |
758 | @findex HAVE_STEPPABLE_WATCHPOINT |
759 | @item HAVE_STEPPABLE_WATCHPOINT | |
760 | If defined to a non-zero value, it is not necessary to disable a | |
5009afc5 | 761 | watchpoint to step over it. Like @code{gdbarch_have_nonsteppable_watchpoint}, |
d983da9c DJ |
762 | this is usually set when watchpoints trigger at the instruction |
763 | which will perform an interesting read or write. It should be | |
764 | set if there is a temporary disable bit which allows the processor | |
765 | to step over the interesting instruction without raising the | |
766 | watchpoint exception again. | |
9742079a | 767 | |
4a9bb1df UW |
768 | @findex gdbarch_have_nonsteppable_watchpoint |
769 | @item int gdbarch_have_nonsteppable_watchpoint (@var{gdbarch}) | |
770 | If it returns a non-zero value, @value{GDBN} should disable a | |
d983da9c DJ |
771 | watchpoint to step the inferior over it. This is usually set when |
772 | watchpoints trigger at the instruction which will perform an | |
773 | interesting read or write. | |
9742079a EZ |
774 | |
775 | @findex HAVE_CONTINUABLE_WATCHPOINT | |
776 | @item HAVE_CONTINUABLE_WATCHPOINT | |
777 | If defined to a non-zero value, it is possible to continue the | |
d983da9c DJ |
778 | inferior after a watchpoint has been hit. This is usually set |
779 | when watchpoints trigger at the instruction following an interesting | |
780 | read or write. | |
9742079a | 781 | |
9742079a EZ |
782 | @findex STOPPED_BY_WATCHPOINT |
783 | @item STOPPED_BY_WATCHPOINT (@var{wait_status}) | |
784 | Return non-zero if stopped by a watchpoint. @var{wait_status} is of | |
785 | the type @code{struct target_waitstatus}, defined by @file{target.h}. | |
b6b8ece6 EZ |
786 | Normally, this macro is defined to invoke the function pointed to by |
787 | the @code{to_stopped_by_watchpoint} member of the structure (of the | |
788 | type @code{target_ops}, defined on @file{target.h}) that describes the | |
789 | target-specific operations; @code{to_stopped_by_watchpoint} ignores | |
790 | the @var{wait_status} argument. | |
791 | ||
792 | @value{GDBN} does not require the non-zero value returned by | |
793 | @code{STOPPED_BY_WATCHPOINT} to be 100% correct, so if a target cannot | |
794 | determine for sure whether the inferior stopped due to a watchpoint, | |
795 | it could return non-zero ``just in case''. | |
9742079a EZ |
796 | @end table |
797 | ||
d983da9c DJ |
798 | @subsection Watchpoints and Threads |
799 | @cindex watchpoints, with threads | |
800 | ||
801 | @value{GDBN} only supports process-wide watchpoints, which trigger | |
802 | in all threads. @value{GDBN} uses the thread ID to make watchpoints | |
803 | act as if they were thread-specific, but it cannot set hardware | |
804 | watchpoints that only trigger in a specific thread. Therefore, even | |
805 | if the target supports threads, per-thread debug registers, and | |
806 | watchpoints which only affect a single thread, it should set the | |
807 | per-thread debug registers for all threads to the same value. On | |
808 | @sc{gnu}/Linux native targets, this is accomplished by using | |
809 | @code{ALL_LWPS} in @code{target_insert_watchpoint} and | |
810 | @code{target_remove_watchpoint} and by using | |
811 | @code{linux_set_new_thread} to register a handler for newly created | |
812 | threads. | |
813 | ||
814 | @value{GDBN}'s @sc{gnu}/Linux support only reports a single event | |
815 | at a time, although multiple events can trigger simultaneously for | |
816 | multi-threaded programs. When multiple events occur, @file{linux-nat.c} | |
817 | queues subsequent events and returns them the next time the program | |
818 | is resumed. This means that @code{STOPPED_BY_WATCHPOINT} and | |
819 | @code{target_stopped_data_address} only need to consult the current | |
820 | thread's state---the thread indicated by @code{inferior_ptid}. If | |
821 | two threads have hit watchpoints simultaneously, those routines | |
822 | will be called a second time for the second thread. | |
823 | ||
9742079a EZ |
824 | @subsection x86 Watchpoints |
825 | @cindex x86 debug registers | |
826 | @cindex watchpoints, on x86 | |
827 | ||
828 | The 32-bit Intel x86 (a.k.a.@: ia32) processors feature special debug | |
829 | registers designed to facilitate debugging. @value{GDBN} provides a | |
830 | generic library of functions that x86-based ports can use to implement | |
831 | support for watchpoints and hardware-assisted breakpoints. This | |
832 | subsection documents the x86 watchpoint facilities in @value{GDBN}. | |
833 | ||
1f70da6a SS |
834 | (At present, the library functions read and write debug registers directly, and are |
835 | thus only available for native configurations.) | |
836 | ||
9742079a EZ |
837 | To use the generic x86 watchpoint support, a port should do the |
838 | following: | |
839 | ||
840 | @itemize @bullet | |
841 | @findex I386_USE_GENERIC_WATCHPOINTS | |
842 | @item | |
843 | Define the macro @code{I386_USE_GENERIC_WATCHPOINTS} somewhere in the | |
844 | target-dependent headers. | |
845 | ||
846 | @item | |
847 | Include the @file{config/i386/nm-i386.h} header file @emph{after} | |
848 | defining @code{I386_USE_GENERIC_WATCHPOINTS}. | |
849 | ||
850 | @item | |
851 | Add @file{i386-nat.o} to the value of the Make variable | |
f0323ca0 | 852 | @code{NATDEPFILES} (@pxref{Native Debugging, NATDEPFILES}). |
9742079a EZ |
853 | |
854 | @item | |
855 | Provide implementations for the @code{I386_DR_LOW_*} macros described | |
856 | below. Typically, each macro should call a target-specific function | |
857 | which does the real work. | |
858 | @end itemize | |
859 | ||
860 | The x86 watchpoint support works by maintaining mirror images of the | |
861 | debug registers. Values are copied between the mirror images and the | |
862 | real debug registers via a set of macros which each target needs to | |
863 | provide: | |
864 | ||
865 | @table @code | |
866 | @findex I386_DR_LOW_SET_CONTROL | |
867 | @item I386_DR_LOW_SET_CONTROL (@var{val}) | |
868 | Set the Debug Control (DR7) register to the value @var{val}. | |
869 | ||
870 | @findex I386_DR_LOW_SET_ADDR | |
871 | @item I386_DR_LOW_SET_ADDR (@var{idx}, @var{addr}) | |
872 | Put the address @var{addr} into the debug register number @var{idx}. | |
873 | ||
874 | @findex I386_DR_LOW_RESET_ADDR | |
875 | @item I386_DR_LOW_RESET_ADDR (@var{idx}) | |
876 | Reset (i.e.@: zero out) the address stored in the debug register | |
877 | number @var{idx}. | |
878 | ||
879 | @findex I386_DR_LOW_GET_STATUS | |
880 | @item I386_DR_LOW_GET_STATUS | |
881 | Return the value of the Debug Status (DR6) register. This value is | |
882 | used immediately after it is returned by | |
883 | @code{I386_DR_LOW_GET_STATUS}, so as to support per-thread status | |
884 | register values. | |
885 | @end table | |
886 | ||
887 | For each one of the 4 debug registers (whose indices are from 0 to 3) | |
888 | that store addresses, a reference count is maintained by @value{GDBN}, | |
889 | to allow sharing of debug registers by several watchpoints. This | |
890 | allows users to define several watchpoints that watch the same | |
891 | expression, but with different conditions and/or commands, without | |
892 | wasting debug registers which are in short supply. @value{GDBN} | |
893 | maintains the reference counts internally, targets don't have to do | |
894 | anything to use this feature. | |
895 | ||
896 | The x86 debug registers can each watch a region that is 1, 2, or 4 | |
897 | bytes long. The ia32 architecture requires that each watched region | |
898 | be appropriately aligned: 2-byte region on 2-byte boundary, 4-byte | |
899 | region on 4-byte boundary. However, the x86 watchpoint support in | |
900 | @value{GDBN} can watch unaligned regions and regions larger than 4 | |
901 | bytes (up to 16 bytes) by allocating several debug registers to watch | |
902 | a single region. This allocation of several registers per a watched | |
903 | region is also done automatically without target code intervention. | |
904 | ||
905 | The generic x86 watchpoint support provides the following API for the | |
906 | @value{GDBN}'s application code: | |
907 | ||
908 | @table @code | |
909 | @findex i386_region_ok_for_watchpoint | |
910 | @item i386_region_ok_for_watchpoint (@var{addr}, @var{len}) | |
911 | The macro @code{TARGET_REGION_OK_FOR_HW_WATCHPOINT} is set to call | |
912 | this function. It counts the number of debug registers required to | |
913 | watch a given region, and returns a non-zero value if that number is | |
914 | less than 4, the number of debug registers available to x86 | |
915 | processors. | |
916 | ||
917 | @findex i386_stopped_data_address | |
ac77d04f JJ |
918 | @item i386_stopped_data_address (@var{addr_p}) |
919 | The target function | |
920 | @code{target_stopped_data_address} is set to call this function. | |
921 | This | |
9742079a EZ |
922 | function examines the breakpoint condition bits in the DR6 Debug |
923 | Status register, as returned by the @code{I386_DR_LOW_GET_STATUS} | |
924 | macro, and returns the address associated with the first bit that is | |
925 | set in DR6. | |
926 | ||
ac77d04f JJ |
927 | @findex i386_stopped_by_watchpoint |
928 | @item i386_stopped_by_watchpoint (void) | |
929 | The macro @code{STOPPED_BY_WATCHPOINT} | |
930 | is set to call this function. The | |
931 | argument passed to @code{STOPPED_BY_WATCHPOINT} is ignored. This | |
932 | function examines the breakpoint condition bits in the DR6 Debug | |
933 | Status register, as returned by the @code{I386_DR_LOW_GET_STATUS} | |
934 | macro, and returns true if any bit is set. Otherwise, false is | |
935 | returned. | |
936 | ||
9742079a EZ |
937 | @findex i386_insert_watchpoint |
938 | @findex i386_remove_watchpoint | |
939 | @item i386_insert_watchpoint (@var{addr}, @var{len}, @var{type}) | |
940 | @itemx i386_remove_watchpoint (@var{addr}, @var{len}, @var{type}) | |
941 | Insert or remove a watchpoint. The macros | |
942 | @code{target_insert_watchpoint} and @code{target_remove_watchpoint} | |
943 | are set to call these functions. @code{i386_insert_watchpoint} first | |
944 | looks for a debug register which is already set to watch the same | |
945 | region for the same access types; if found, it just increments the | |
946 | reference count of that debug register, thus implementing debug | |
947 | register sharing between watchpoints. If no such register is found, | |
937f164b FF |
948 | the function looks for a vacant debug register, sets its mirrored |
949 | value to @var{addr}, sets the mirrored value of DR7 Debug Control | |
9742079a EZ |
950 | register as appropriate for the @var{len} and @var{type} parameters, |
951 | and then passes the new values of the debug register and DR7 to the | |
952 | inferior by calling @code{I386_DR_LOW_SET_ADDR} and | |
953 | @code{I386_DR_LOW_SET_CONTROL}. If more than one debug register is | |
954 | required to cover the given region, the above process is repeated for | |
955 | each debug register. | |
956 | ||
957 | @code{i386_remove_watchpoint} does the opposite: it resets the address | |
937f164b FF |
958 | in the mirrored value of the debug register and its read/write and |
959 | length bits in the mirrored value of DR7, then passes these new | |
9742079a EZ |
960 | values to the inferior via @code{I386_DR_LOW_RESET_ADDR} and |
961 | @code{I386_DR_LOW_SET_CONTROL}. If a register is shared by several | |
962 | watchpoints, each time a @code{i386_remove_watchpoint} is called, it | |
963 | decrements the reference count, and only calls | |
964 | @code{I386_DR_LOW_RESET_ADDR} and @code{I386_DR_LOW_SET_CONTROL} when | |
965 | the count goes to zero. | |
966 | ||
967 | @findex i386_insert_hw_breakpoint | |
968 | @findex i386_remove_hw_breakpoint | |
8181d85f DJ |
969 | @item i386_insert_hw_breakpoint (@var{bp_tgt}) |
970 | @itemx i386_remove_hw_breakpoint (@var{bp_tgt}) | |
9742079a EZ |
971 | These functions insert and remove hardware-assisted breakpoints. The |
972 | macros @code{target_insert_hw_breakpoint} and | |
973 | @code{target_remove_hw_breakpoint} are set to call these functions. | |
8181d85f DJ |
974 | The argument is a @code{struct bp_target_info *}, as described in |
975 | the documentation for @code{target_insert_breakpoint}. | |
9742079a EZ |
976 | These functions work like @code{i386_insert_watchpoint} and |
977 | @code{i386_remove_watchpoint}, respectively, except that they set up | |
978 | the debug registers to watch instruction execution, and each | |
979 | hardware-assisted breakpoint always requires exactly one debug | |
980 | register. | |
981 | ||
9742079a EZ |
982 | @findex i386_cleanup_dregs |
983 | @item i386_cleanup_dregs (void) | |
984 | This function clears all the reference counts, addresses, and control | |
985 | bits in the mirror images of the debug registers. It doesn't affect | |
986 | the actual debug registers in the inferior process. | |
987 | @end table | |
988 | ||
989 | @noindent | |
990 | @strong{Notes:} | |
991 | @enumerate 1 | |
992 | @item | |
993 | x86 processors support setting watchpoints on I/O reads or writes. | |
994 | However, since no target supports this (as of March 2001), and since | |
995 | @code{enum target_hw_bp_type} doesn't even have an enumeration for I/O | |
996 | watchpoints, this feature is not yet available to @value{GDBN} running | |
997 | on x86. | |
998 | ||
999 | @item | |
1000 | x86 processors can enable watchpoints locally, for the current task | |
1001 | only, or globally, for all the tasks. For each debug register, | |
1002 | there's a bit in the DR7 Debug Control register that determines | |
1003 | whether the associated address is watched locally or globally. The | |
1004 | current implementation of x86 watchpoint support in @value{GDBN} | |
1005 | always sets watchpoints to be locally enabled, since global | |
1006 | watchpoints might interfere with the underlying OS and are probably | |
1007 | unavailable in many platforms. | |
1008 | @end enumerate | |
1009 | ||
5c95884b MS |
1010 | @section Checkpoints |
1011 | @cindex checkpoints | |
1012 | @cindex restart | |
1013 | In the abstract, a checkpoint is a point in the execution history of | |
1014 | the program, which the user may wish to return to at some later time. | |
1015 | ||
1016 | Internally, a checkpoint is a saved copy of the program state, including | |
1017 | whatever information is required in order to restore the program to that | |
1018 | state at a later time. This can be expected to include the state of | |
1019 | registers and memory, and may include external state such as the state | |
1020 | of open files and devices. | |
1021 | ||
1022 | There are a number of ways in which checkpoints may be implemented | |
b247355e | 1023 | in gdb, e.g.@: as corefiles, as forked processes, and as some opaque |
5c95884b MS |
1024 | method implemented on the target side. |
1025 | ||
1026 | A corefile can be used to save an image of target memory and register | |
1027 | state, which can in principle be restored later --- but corefiles do | |
1028 | not typically include information about external entities such as | |
1029 | open files. Currently this method is not implemented in gdb. | |
1030 | ||
1031 | A forked process can save the state of user memory and registers, | |
1032 | as well as some subset of external (kernel) state. This method | |
1033 | is used to implement checkpoints on Linux, and in principle might | |
1034 | be used on other systems. | |
1035 | ||
b247355e | 1036 | Some targets, e.g.@: simulators, might have their own built-in |
5c95884b MS |
1037 | method for saving checkpoints, and gdb might be able to take |
1038 | advantage of that capability without necessarily knowing any | |
1039 | details of how it is done. | |
1040 | ||
1041 | ||
bcd7e15f JB |
1042 | @section Observing changes in @value{GDBN} internals |
1043 | @cindex observer pattern interface | |
1044 | @cindex notifications about changes in internals | |
1045 | ||
1046 | In order to function properly, several modules need to be notified when | |
1047 | some changes occur in the @value{GDBN} internals. Traditionally, these | |
1048 | modules have relied on several paradigms, the most common ones being | |
1049 | hooks and gdb-events. Unfortunately, none of these paradigms was | |
1050 | versatile enough to become the standard notification mechanism in | |
1051 | @value{GDBN}. The fact that they only supported one ``client'' was also | |
1052 | a strong limitation. | |
1053 | ||
1054 | A new paradigm, based on the Observer pattern of the @cite{Design | |
1055 | Patterns} book, has therefore been implemented. The goal was to provide | |
1056 | a new interface overcoming the issues with the notification mechanisms | |
1057 | previously available. This new interface needed to be strongly typed, | |
1058 | easy to extend, and versatile enough to be used as the standard | |
1059 | interface when adding new notifications. | |
1060 | ||
1061 | See @ref{GDB Observers} for a brief description of the observers | |
1062 | currently implemented in GDB. The rationale for the current | |
1063 | implementation is also briefly discussed. | |
1064 | ||
c906108c SS |
1065 | @node User Interface |
1066 | ||
1067 | @chapter User Interface | |
1068 | ||
1f70da6a SS |
1069 | @value{GDBN} has several user interfaces, of which the traditional |
1070 | command-line interface is perhaps the most familiar. | |
c906108c SS |
1071 | |
1072 | @section Command Interpreter | |
1073 | ||
56caf160 | 1074 | @cindex command interpreter |
0ee54786 | 1075 | @cindex CLI |
25822942 | 1076 | The command interpreter in @value{GDBN} is fairly simple. It is designed to |
c906108c SS |
1077 | allow for the set of commands to be augmented dynamically, and also |
1078 | has a recursive subcommand capability, where the first argument to | |
1079 | a command may itself direct a lookup on a different command list. | |
1080 | ||
56caf160 EZ |
1081 | For instance, the @samp{set} command just starts a lookup on the |
1082 | @code{setlist} command list, while @samp{set thread} recurses | |
c906108c SS |
1083 | to the @code{set_thread_cmd_list}. |
1084 | ||
56caf160 EZ |
1085 | @findex add_cmd |
1086 | @findex add_com | |
c906108c SS |
1087 | To add commands in general, use @code{add_cmd}. @code{add_com} adds to |
1088 | the main command list, and should be used for those commands. The usual | |
cfeada60 | 1089 | place to add commands is in the @code{_initialize_@var{xyz}} routines at |
9742079a | 1090 | the ends of most source files. |
cfeada60 | 1091 | |
40dd2248 TT |
1092 | @findex add_setshow_cmd |
1093 | @findex add_setshow_cmd_full | |
1094 | To add paired @samp{set} and @samp{show} commands, use | |
1095 | @code{add_setshow_cmd} or @code{add_setshow_cmd_full}. The former is | |
1096 | a slightly simpler interface which is useful when you don't need to | |
1097 | further modify the new command structures, while the latter returns | |
1098 | the new command structures for manipulation. | |
1099 | ||
56caf160 EZ |
1100 | @cindex deprecating commands |
1101 | @findex deprecate_cmd | |
cfeada60 FN |
1102 | Before removing commands from the command set it is a good idea to |
1103 | deprecate them for some time. Use @code{deprecate_cmd} on commands or | |
1104 | aliases to set the deprecated flag. @code{deprecate_cmd} takes a | |
1105 | @code{struct cmd_list_element} as it's first argument. You can use the | |
1106 | return value from @code{add_com} or @code{add_cmd} to deprecate the | |
1107 | command immediately after it is created. | |
1108 | ||
c72e7388 | 1109 | The first time a command is used the user will be warned and offered a |
cfeada60 | 1110 | replacement (if one exists). Note that the replacement string passed to |
d3e8051b | 1111 | @code{deprecate_cmd} should be the full name of the command, i.e., the |
cfeada60 | 1112 | entire string the user should type at the command line. |
c906108c | 1113 | |
587afa38 | 1114 | @anchor{UI-Independent Output} |
0ee54786 EZ |
1115 | @section UI-Independent Output---the @code{ui_out} Functions |
1116 | @c This section is based on the documentation written by Fernando | |
1117 | @c Nasser <fnasser@redhat.com>. | |
1118 | ||
1119 | @cindex @code{ui_out} functions | |
1120 | The @code{ui_out} functions present an abstraction level for the | |
1121 | @value{GDBN} output code. They hide the specifics of different user | |
1122 | interfaces supported by @value{GDBN}, and thus free the programmer | |
1123 | from the need to write several versions of the same code, one each for | |
1124 | every UI, to produce output. | |
1125 | ||
1126 | @subsection Overview and Terminology | |
1127 | ||
1128 | In general, execution of each @value{GDBN} command produces some sort | |
1129 | of output, and can even generate an input request. | |
1130 | ||
1131 | Output can be generated for the following purposes: | |
1132 | ||
1133 | @itemize @bullet | |
1134 | @item | |
1135 | to display a @emph{result} of an operation; | |
1136 | ||
1137 | @item | |
1138 | to convey @emph{info} or produce side-effects of a requested | |
1139 | operation; | |
1140 | ||
1141 | @item | |
1142 | to provide a @emph{notification} of an asynchronous event (including | |
1143 | progress indication of a prolonged asynchronous operation); | |
1144 | ||
1145 | @item | |
1146 | to display @emph{error messages} (including warnings); | |
1147 | ||
1148 | @item | |
1149 | to show @emph{debug data}; | |
1150 | ||
1151 | @item | |
1152 | to @emph{query} or prompt a user for input (a special case). | |
1153 | @end itemize | |
1154 | ||
1155 | @noindent | |
1156 | This section mainly concentrates on how to build result output, | |
1157 | although some of it also applies to other kinds of output. | |
1158 | ||
1159 | Generation of output that displays the results of an operation | |
1160 | involves one or more of the following: | |
1161 | ||
1162 | @itemize @bullet | |
1163 | @item | |
1164 | output of the actual data | |
1165 | ||
1166 | @item | |
1167 | formatting the output as appropriate for console output, to make it | |
1168 | easily readable by humans | |
1169 | ||
1170 | @item | |
1171 | machine oriented formatting--a more terse formatting to allow for easy | |
1172 | parsing by programs which read @value{GDBN}'s output | |
1173 | ||
1174 | @item | |
c72e7388 AC |
1175 | annotation, whose purpose is to help legacy GUIs to identify interesting |
1176 | parts in the output | |
0ee54786 EZ |
1177 | @end itemize |
1178 | ||
1179 | The @code{ui_out} routines take care of the first three aspects. | |
c72e7388 AC |
1180 | Annotations are provided by separate annotation routines. Note that use |
1181 | of annotations for an interface between a GUI and @value{GDBN} is | |
0ee54786 EZ |
1182 | deprecated. |
1183 | ||
c72e7388 AC |
1184 | Output can be in the form of a single item, which we call a @dfn{field}; |
1185 | a @dfn{list} consisting of identical fields; a @dfn{tuple} consisting of | |
1186 | non-identical fields; or a @dfn{table}, which is a tuple consisting of a | |
1187 | header and a body. In a BNF-like form: | |
0ee54786 | 1188 | |
c72e7388 AC |
1189 | @table @code |
1190 | @item <table> @expansion{} | |
1191 | @code{<header> <body>} | |
1192 | @item <header> @expansion{} | |
1193 | @code{@{ <column> @}} | |
1194 | @item <column> @expansion{} | |
1195 | @code{<width> <alignment> <title>} | |
1196 | @item <body> @expansion{} | |
1197 | @code{@{<row>@}} | |
1198 | @end table | |
0ee54786 EZ |
1199 | |
1200 | ||
1201 | @subsection General Conventions | |
1202 | ||
c72e7388 AC |
1203 | Most @code{ui_out} routines are of type @code{void}, the exceptions are |
1204 | @code{ui_out_stream_new} (which returns a pointer to the newly created | |
1205 | object) and the @code{make_cleanup} routines. | |
0ee54786 | 1206 | |
c72e7388 AC |
1207 | The first parameter is always the @code{ui_out} vector object, a pointer |
1208 | to a @code{struct ui_out}. | |
0ee54786 | 1209 | |
c72e7388 AC |
1210 | The @var{format} parameter is like in @code{printf} family of functions. |
1211 | When it is present, there must also be a variable list of arguments | |
1212 | sufficient used to satisfy the @code{%} specifiers in the supplied | |
0ee54786 EZ |
1213 | format. |
1214 | ||
c72e7388 AC |
1215 | When a character string argument is not used in a @code{ui_out} function |
1216 | call, a @code{NULL} pointer has to be supplied instead. | |
0ee54786 EZ |
1217 | |
1218 | ||
c72e7388 | 1219 | @subsection Table, Tuple and List Functions |
0ee54786 EZ |
1220 | |
1221 | @cindex list output functions | |
1222 | @cindex table output functions | |
c72e7388 AC |
1223 | @cindex tuple output functions |
1224 | This section introduces @code{ui_out} routines for building lists, | |
1225 | tuples and tables. The routines to output the actual data items | |
1226 | (fields) are presented in the next section. | |
0ee54786 | 1227 | |
c72e7388 AC |
1228 | To recap: A @dfn{tuple} is a sequence of @dfn{fields}, each field |
1229 | containing information about an object; a @dfn{list} is a sequence of | |
1230 | fields where each field describes an identical object. | |
0ee54786 | 1231 | |
c72e7388 AC |
1232 | Use the @dfn{table} functions when your output consists of a list of |
1233 | rows (tuples) and the console output should include a heading. Use this | |
1234 | even when you are listing just one object but you still want the header. | |
0ee54786 EZ |
1235 | |
1236 | @cindex nesting level in @code{ui_out} functions | |
c72e7388 AC |
1237 | Tables can not be nested. Tuples and lists can be nested up to a |
1238 | maximum of five levels. | |
0ee54786 EZ |
1239 | |
1240 | The overall structure of the table output code is something like this: | |
1241 | ||
474c8240 | 1242 | @smallexample |
0ee54786 EZ |
1243 | ui_out_table_begin |
1244 | ui_out_table_header | |
c72e7388 | 1245 | @dots{} |
0ee54786 | 1246 | ui_out_table_body |
c72e7388 | 1247 | ui_out_tuple_begin |
0ee54786 | 1248 | ui_out_field_* |
c72e7388 AC |
1249 | @dots{} |
1250 | ui_out_tuple_end | |
1251 | @dots{} | |
0ee54786 | 1252 | ui_out_table_end |
474c8240 | 1253 | @end smallexample |
0ee54786 | 1254 | |
c72e7388 | 1255 | Here is the description of table-, tuple- and list-related @code{ui_out} |
0ee54786 EZ |
1256 | functions: |
1257 | ||
c72e7388 AC |
1258 | @deftypefun void ui_out_table_begin (struct ui_out *@var{uiout}, int @var{nbrofcols}, int @var{nr_rows}, const char *@var{tblid}) |
1259 | The function @code{ui_out_table_begin} marks the beginning of the output | |
1260 | of a table. It should always be called before any other @code{ui_out} | |
1261 | function for a given table. @var{nbrofcols} is the number of columns in | |
1262 | the table. @var{nr_rows} is the number of rows in the table. | |
1263 | @var{tblid} is an optional string identifying the table. The string | |
1264 | pointed to by @var{tblid} is copied by the implementation of | |
1265 | @code{ui_out_table_begin}, so the application can free the string if it | |
1266 | was @code{malloc}ed. | |
0ee54786 EZ |
1267 | |
1268 | The companion function @code{ui_out_table_end}, described below, marks | |
1269 | the end of the table's output. | |
1270 | @end deftypefun | |
1271 | ||
c72e7388 AC |
1272 | @deftypefun void ui_out_table_header (struct ui_out *@var{uiout}, int @var{width}, enum ui_align @var{alignment}, const char *@var{colhdr}) |
1273 | @code{ui_out_table_header} provides the header information for a single | |
1274 | table column. You call this function several times, one each for every | |
1275 | column of the table, after @code{ui_out_table_begin}, but before | |
1276 | @code{ui_out_table_body}. | |
0ee54786 EZ |
1277 | |
1278 | The value of @var{width} gives the column width in characters. The | |
1279 | value of @var{alignment} is one of @code{left}, @code{center}, and | |
1280 | @code{right}, and it specifies how to align the header: left-justify, | |
1281 | center, or right-justify it. @var{colhdr} points to a string that | |
1282 | specifies the column header; the implementation copies that string, so | |
c72e7388 AC |
1283 | column header strings in @code{malloc}ed storage can be freed after the |
1284 | call. | |
0ee54786 EZ |
1285 | @end deftypefun |
1286 | ||
1287 | @deftypefun void ui_out_table_body (struct ui_out *@var{uiout}) | |
c72e7388 | 1288 | This function delimits the table header from the table body. |
0ee54786 EZ |
1289 | @end deftypefun |
1290 | ||
1291 | @deftypefun void ui_out_table_end (struct ui_out *@var{uiout}) | |
c72e7388 AC |
1292 | This function signals the end of a table's output. It should be called |
1293 | after the table body has been produced by the list and field output | |
1294 | functions. | |
0ee54786 EZ |
1295 | |
1296 | There should be exactly one call to @code{ui_out_table_end} for each | |
c72e7388 AC |
1297 | call to @code{ui_out_table_begin}, otherwise the @code{ui_out} functions |
1298 | will signal an internal error. | |
0ee54786 EZ |
1299 | @end deftypefun |
1300 | ||
c72e7388 | 1301 | The output of the tuples that represent the table rows must follow the |
0ee54786 | 1302 | call to @code{ui_out_table_body} and precede the call to |
c72e7388 AC |
1303 | @code{ui_out_table_end}. You build a tuple by calling |
1304 | @code{ui_out_tuple_begin} and @code{ui_out_tuple_end}, with suitable | |
0ee54786 EZ |
1305 | calls to functions which actually output fields between them. |
1306 | ||
c72e7388 AC |
1307 | @deftypefun void ui_out_tuple_begin (struct ui_out *@var{uiout}, const char *@var{id}) |
1308 | This function marks the beginning of a tuple output. @var{id} points | |
1309 | to an optional string that identifies the tuple; it is copied by the | |
1310 | implementation, and so strings in @code{malloc}ed storage can be freed | |
1311 | after the call. | |
1312 | @end deftypefun | |
1313 | ||
1314 | @deftypefun void ui_out_tuple_end (struct ui_out *@var{uiout}) | |
1315 | This function signals an end of a tuple output. There should be exactly | |
1316 | one call to @code{ui_out_tuple_end} for each call to | |
1317 | @code{ui_out_tuple_begin}, otherwise an internal @value{GDBN} error will | |
1318 | be signaled. | |
1319 | @end deftypefun | |
1320 | ||
587afa38 | 1321 | @deftypefun {struct cleanup *} make_cleanup_ui_out_tuple_begin_end (struct ui_out *@var{uiout}, const char *@var{id}) |
c72e7388 | 1322 | This function first opens the tuple and then establishes a cleanup |
a0e0ffdf DE |
1323 | (@pxref{Misc Guidelines, Cleanups}) to close the tuple. |
1324 | It provides a convenient and correct implementation of the | |
1325 | non-portable@footnote{The function cast is not portable ISO C.} code sequence: | |
c72e7388 AC |
1326 | @smallexample |
1327 | struct cleanup *old_cleanup; | |
1328 | ui_out_tuple_begin (uiout, "..."); | |
1329 | old_cleanup = make_cleanup ((void(*)(void *)) ui_out_tuple_end, | |
1330 | uiout); | |
1331 | @end smallexample | |
1332 | @end deftypefun | |
1333 | ||
1334 | @deftypefun void ui_out_list_begin (struct ui_out *@var{uiout}, const char *@var{id}) | |
1335 | This function marks the beginning of a list output. @var{id} points to | |
1336 | an optional string that identifies the list; it is copied by the | |
1337 | implementation, and so strings in @code{malloc}ed storage can be freed | |
1338 | after the call. | |
0ee54786 EZ |
1339 | @end deftypefun |
1340 | ||
1341 | @deftypefun void ui_out_list_end (struct ui_out *@var{uiout}) | |
c72e7388 AC |
1342 | This function signals an end of a list output. There should be exactly |
1343 | one call to @code{ui_out_list_end} for each call to | |
1344 | @code{ui_out_list_begin}, otherwise an internal @value{GDBN} error will | |
1345 | be signaled. | |
1346 | @end deftypefun | |
1347 | ||
587afa38 | 1348 | @deftypefun {struct cleanup *} make_cleanup_ui_out_list_begin_end (struct ui_out *@var{uiout}, const char *@var{id}) |
c72e7388 | 1349 | Similar to @code{make_cleanup_ui_out_tuple_begin_end}, this function |
a0e0ffdf DE |
1350 | opens a list and then establishes cleanup |
1351 | (@pxref{Misc Guidelines, Cleanups}) | |
f66d1690 | 1352 | that will close the list. |
0ee54786 EZ |
1353 | @end deftypefun |
1354 | ||
1355 | @subsection Item Output Functions | |
1356 | ||
1357 | @cindex item output functions | |
1358 | @cindex field output functions | |
1359 | @cindex data output | |
1360 | The functions described below produce output for the actual data | |
1361 | items, or fields, which contain information about the object. | |
1362 | ||
1363 | Choose the appropriate function accordingly to your particular needs. | |
1364 | ||
1365 | @deftypefun void ui_out_field_fmt (struct ui_out *@var{uiout}, char *@var{fldname}, char *@var{format}, ...) | |
1366 | This is the most general output function. It produces the | |
1367 | representation of the data in the variable-length argument list | |
1368 | according to formatting specifications in @var{format}, a | |
1369 | @code{printf}-like format string. The optional argument @var{fldname} | |
1370 | supplies the name of the field. The data items themselves are | |
1371 | supplied as additional arguments after @var{format}. | |
1372 | ||
1373 | This generic function should be used only when it is not possible to | |
1374 | use one of the specialized versions (see below). | |
1375 | @end deftypefun | |
1376 | ||
c72e7388 | 1377 | @deftypefun void ui_out_field_int (struct ui_out *@var{uiout}, const char *@var{fldname}, int @var{value}) |
0ee54786 EZ |
1378 | This function outputs a value of an @code{int} variable. It uses the |
1379 | @code{"%d"} output conversion specification. @var{fldname} specifies | |
1380 | the name of the field. | |
1381 | @end deftypefun | |
8d19fbd2 JJ |
1382 | |
1383 | @deftypefun void ui_out_field_fmt_int (struct ui_out *@var{uiout}, int @var{width}, enum ui_align @var{alignment}, const char *@var{fldname}, int @var{value}) | |
1384 | This function outputs a value of an @code{int} variable. It differs from | |
1385 | @code{ui_out_field_int} in that the caller specifies the desired @var{width} and @var{alignment} of the output. | |
1386 | @var{fldname} specifies | |
1387 | the name of the field. | |
1388 | @end deftypefun | |
0ee54786 | 1389 | |
5af949e3 UW |
1390 | @deftypefun void ui_out_field_core_addr (struct ui_out *@var{uiout}, const char *@var{fldname}, struct gdbarch *@var{gdbarch}, CORE_ADDR @var{address}) |
1391 | This function outputs an address as appropriate for @var{gdbarch}. | |
0ee54786 EZ |
1392 | @end deftypefun |
1393 | ||
c72e7388 | 1394 | @deftypefun void ui_out_field_string (struct ui_out *@var{uiout}, const char *@var{fldname}, const char *@var{string}) |
0ee54786 EZ |
1395 | This function outputs a string using the @code{"%s"} conversion |
1396 | specification. | |
1397 | @end deftypefun | |
1398 | ||
1399 | Sometimes, there's a need to compose your output piece by piece using | |
1400 | functions that operate on a stream, such as @code{value_print} or | |
1401 | @code{fprintf_symbol_filtered}. These functions accept an argument of | |
1402 | the type @code{struct ui_file *}, a pointer to a @code{ui_file} object | |
1403 | used to store the data stream used for the output. When you use one | |
1404 | of these functions, you need a way to pass their results stored in a | |
1405 | @code{ui_file} object to the @code{ui_out} functions. To this end, | |
1406 | you first create a @code{ui_stream} object by calling | |
1407 | @code{ui_out_stream_new}, pass the @code{stream} member of that | |
1408 | @code{ui_stream} object to @code{value_print} and similar functions, | |
1409 | and finally call @code{ui_out_field_stream} to output the field you | |
1410 | constructed. When the @code{ui_stream} object is no longer needed, | |
1411 | you should destroy it and free its memory by calling | |
1412 | @code{ui_out_stream_delete}. | |
1413 | ||
587afa38 | 1414 | @deftypefun {struct ui_stream *} ui_out_stream_new (struct ui_out *@var{uiout}) |
0ee54786 EZ |
1415 | This function creates a new @code{ui_stream} object which uses the |
1416 | same output methods as the @code{ui_out} object whose pointer is | |
1417 | passed in @var{uiout}. It returns a pointer to the newly created | |
1418 | @code{ui_stream} object. | |
1419 | @end deftypefun | |
1420 | ||
1421 | @deftypefun void ui_out_stream_delete (struct ui_stream *@var{streambuf}) | |
1422 | This functions destroys a @code{ui_stream} object specified by | |
1423 | @var{streambuf}. | |
1424 | @end deftypefun | |
1425 | ||
c72e7388 | 1426 | @deftypefun void ui_out_field_stream (struct ui_out *@var{uiout}, const char *@var{fieldname}, struct ui_stream *@var{streambuf}) |
0ee54786 EZ |
1427 | This function consumes all the data accumulated in |
1428 | @code{streambuf->stream} and outputs it like | |
1429 | @code{ui_out_field_string} does. After a call to | |
1430 | @code{ui_out_field_stream}, the accumulated data no longer exists, but | |
1431 | the stream is still valid and may be used for producing more fields. | |
1432 | @end deftypefun | |
1433 | ||
1434 | @strong{Important:} If there is any chance that your code could bail | |
1435 | out before completing output generation and reaching the point where | |
1436 | @code{ui_out_stream_delete} is called, it is necessary to set up a | |
1437 | cleanup, to avoid leaking memory and other resources. Here's a | |
1438 | skeleton code to do that: | |
1439 | ||
1440 | @smallexample | |
1441 | struct ui_stream *mybuf = ui_out_stream_new (uiout); | |
1442 | struct cleanup *old = make_cleanup (ui_out_stream_delete, mybuf); | |
1443 | ... | |
1444 | do_cleanups (old); | |
1445 | @end smallexample | |
1446 | ||
1447 | If the function already has the old cleanup chain set (for other kinds | |
1448 | of cleanups), you just have to add your cleanup to it: | |
1449 | ||
1450 | @smallexample | |
1451 | mybuf = ui_out_stream_new (uiout); | |
1452 | make_cleanup (ui_out_stream_delete, mybuf); | |
1453 | @end smallexample | |
1454 | ||
1455 | Note that with cleanups in place, you should not call | |
1456 | @code{ui_out_stream_delete} directly, or you would attempt to free the | |
1457 | same buffer twice. | |
1458 | ||
1459 | @subsection Utility Output Functions | |
1460 | ||
c72e7388 | 1461 | @deftypefun void ui_out_field_skip (struct ui_out *@var{uiout}, const char *@var{fldname}) |
0ee54786 EZ |
1462 | This function skips a field in a table. Use it if you have to leave |
1463 | an empty field without disrupting the table alignment. The argument | |
1464 | @var{fldname} specifies a name for the (missing) filed. | |
1465 | @end deftypefun | |
1466 | ||
c72e7388 | 1467 | @deftypefun void ui_out_text (struct ui_out *@var{uiout}, const char *@var{string}) |
0ee54786 EZ |
1468 | This function outputs the text in @var{string} in a way that makes it |
1469 | easy to be read by humans. For example, the console implementation of | |
1470 | this method filters the text through a built-in pager, to prevent it | |
1471 | from scrolling off the visible portion of the screen. | |
1472 | ||
1473 | Use this function for printing relatively long chunks of text around | |
1474 | the actual field data: the text it produces is not aligned according | |
1475 | to the table's format. Use @code{ui_out_field_string} to output a | |
1476 | string field, and use @code{ui_out_message}, described below, to | |
1477 | output short messages. | |
1478 | @end deftypefun | |
1479 | ||
1480 | @deftypefun void ui_out_spaces (struct ui_out *@var{uiout}, int @var{nspaces}) | |
1481 | This function outputs @var{nspaces} spaces. It is handy to align the | |
1482 | text produced by @code{ui_out_text} with the rest of the table or | |
1483 | list. | |
1484 | @end deftypefun | |
1485 | ||
c72e7388 | 1486 | @deftypefun void ui_out_message (struct ui_out *@var{uiout}, int @var{verbosity}, const char *@var{format}, ...) |
0ee54786 EZ |
1487 | This function produces a formatted message, provided that the current |
1488 | verbosity level is at least as large as given by @var{verbosity}. The | |
1489 | current verbosity level is specified by the user with the @samp{set | |
1490 | verbositylevel} command.@footnote{As of this writing (April 2001), | |
1491 | setting verbosity level is not yet implemented, and is always returned | |
1492 | as zero. So calling @code{ui_out_message} with a @var{verbosity} | |
1493 | argument more than zero will cause the message to never be printed.} | |
1494 | @end deftypefun | |
1495 | ||
1496 | @deftypefun void ui_out_wrap_hint (struct ui_out *@var{uiout}, char *@var{indent}) | |
1497 | This function gives the console output filter (a paging filter) a hint | |
1498 | of where to break lines which are too long. Ignored for all other | |
1499 | output consumers. @var{indent}, if non-@code{NULL}, is the string to | |
1500 | be printed to indent the wrapped text on the next line; it must remain | |
1501 | accessible until the next call to @code{ui_out_wrap_hint}, or until an | |
1502 | explicit newline is produced by one of the other functions. If | |
1503 | @var{indent} is @code{NULL}, the wrapped text will not be indented. | |
1504 | @end deftypefun | |
1505 | ||
1506 | @deftypefun void ui_out_flush (struct ui_out *@var{uiout}) | |
1507 | This function flushes whatever output has been accumulated so far, if | |
1508 | the UI buffers output. | |
1509 | @end deftypefun | |
1510 | ||
1511 | ||
1512 | @subsection Examples of Use of @code{ui_out} functions | |
1513 | ||
1514 | @cindex using @code{ui_out} functions | |
1515 | @cindex @code{ui_out} functions, usage examples | |
1516 | This section gives some practical examples of using the @code{ui_out} | |
1517 | functions to generalize the old console-oriented code in | |
1518 | @value{GDBN}. The examples all come from functions defined on the | |
1519 | @file{breakpoints.c} file. | |
1520 | ||
1521 | This example, from the @code{breakpoint_1} function, shows how to | |
1522 | produce a table. | |
1523 | ||
1524 | The original code was: | |
1525 | ||
474c8240 | 1526 | @smallexample |
0ee54786 EZ |
1527 | if (!found_a_breakpoint++) |
1528 | @{ | |
1529 | annotate_breakpoints_headers (); | |
1530 | ||
1531 | annotate_field (0); | |
1532 | printf_filtered ("Num "); | |
1533 | annotate_field (1); | |
1534 | printf_filtered ("Type "); | |
1535 | annotate_field (2); | |
1536 | printf_filtered ("Disp "); | |
1537 | annotate_field (3); | |
1538 | printf_filtered ("Enb "); | |
1539 | if (addressprint) | |
1540 | @{ | |
1541 | annotate_field (4); | |
1542 | printf_filtered ("Address "); | |
1543 | @} | |
1544 | annotate_field (5); | |
1545 | printf_filtered ("What\n"); | |
1546 | ||
1547 | annotate_breakpoints_table (); | |
1548 | @} | |
474c8240 | 1549 | @end smallexample |
0ee54786 EZ |
1550 | |
1551 | Here's the new version: | |
1552 | ||
474c8240 | 1553 | @smallexample |
c72e7388 AC |
1554 | nr_printable_breakpoints = @dots{}; |
1555 | ||
1556 | if (addressprint) | |
1557 | ui_out_table_begin (ui, 6, nr_printable_breakpoints, "BreakpointTable"); | |
1558 | else | |
1559 | ui_out_table_begin (ui, 5, nr_printable_breakpoints, "BreakpointTable"); | |
1560 | ||
1561 | if (nr_printable_breakpoints > 0) | |
1562 | annotate_breakpoints_headers (); | |
1563 | if (nr_printable_breakpoints > 0) | |
1564 | annotate_field (0); | |
1565 | ui_out_table_header (uiout, 3, ui_left, "number", "Num"); /* 1 */ | |
1566 | if (nr_printable_breakpoints > 0) | |
1567 | annotate_field (1); | |
1568 | ui_out_table_header (uiout, 14, ui_left, "type", "Type"); /* 2 */ | |
1569 | if (nr_printable_breakpoints > 0) | |
1570 | annotate_field (2); | |
1571 | ui_out_table_header (uiout, 4, ui_left, "disp", "Disp"); /* 3 */ | |
1572 | if (nr_printable_breakpoints > 0) | |
1573 | annotate_field (3); | |
1574 | ui_out_table_header (uiout, 3, ui_left, "enabled", "Enb"); /* 4 */ | |
1575 | if (addressprint) | |
1576 | @{ | |
1577 | if (nr_printable_breakpoints > 0) | |
1578 | annotate_field (4); | |
a6d9a66e | 1579 | if (print_address_bits <= 32) |
c72e7388 | 1580 | ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */ |
0ee54786 | 1581 | else |
c72e7388 AC |
1582 | ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */ |
1583 | @} | |
1584 | if (nr_printable_breakpoints > 0) | |
1585 | annotate_field (5); | |
1586 | ui_out_table_header (uiout, 40, ui_noalign, "what", "What"); /* 6 */ | |
1587 | ui_out_table_body (uiout); | |
1588 | if (nr_printable_breakpoints > 0) | |
1589 | annotate_breakpoints_table (); | |
474c8240 | 1590 | @end smallexample |
0ee54786 EZ |
1591 | |
1592 | This example, from the @code{print_one_breakpoint} function, shows how | |
1593 | to produce the actual data for the table whose structure was defined | |
1594 | in the above example. The original code was: | |
1595 | ||
474c8240 | 1596 | @smallexample |
0ee54786 EZ |
1597 | annotate_record (); |
1598 | annotate_field (0); | |
1599 | printf_filtered ("%-3d ", b->number); | |
1600 | annotate_field (1); | |
1601 | if ((int)b->type > (sizeof(bptypes)/sizeof(bptypes[0])) | |
1602 | || ((int) b->type != bptypes[(int) b->type].type)) | |
1603 | internal_error ("bptypes table does not describe type #%d.", | |
1604 | (int)b->type); | |
1605 | printf_filtered ("%-14s ", bptypes[(int)b->type].description); | |
1606 | annotate_field (2); | |
1607 | printf_filtered ("%-4s ", bpdisps[(int)b->disposition]); | |
1608 | annotate_field (3); | |
1609 | printf_filtered ("%-3c ", bpenables[(int)b->enable]); | |
c72e7388 | 1610 | @dots{} |
474c8240 | 1611 | @end smallexample |
0ee54786 EZ |
1612 | |
1613 | This is the new version: | |
1614 | ||
474c8240 | 1615 | @smallexample |
0ee54786 | 1616 | annotate_record (); |
c72e7388 | 1617 | ui_out_tuple_begin (uiout, "bkpt"); |
0ee54786 EZ |
1618 | annotate_field (0); |
1619 | ui_out_field_int (uiout, "number", b->number); | |
1620 | annotate_field (1); | |
1621 | if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0]))) | |
1622 | || ((int) b->type != bptypes[(int) b->type].type)) | |
1623 | internal_error ("bptypes table does not describe type #%d.", | |
1624 | (int) b->type); | |
1625 | ui_out_field_string (uiout, "type", bptypes[(int)b->type].description); | |
1626 | annotate_field (2); | |
1627 | ui_out_field_string (uiout, "disp", bpdisps[(int)b->disposition]); | |
1628 | annotate_field (3); | |
1629 | ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)b->enable]); | |
c72e7388 | 1630 | @dots{} |
474c8240 | 1631 | @end smallexample |
0ee54786 EZ |
1632 | |
1633 | This example, also from @code{print_one_breakpoint}, shows how to | |
1634 | produce a complicated output field using the @code{print_expression} | |
1635 | functions which requires a stream to be passed. It also shows how to | |
1636 | automate stream destruction with cleanups. The original code was: | |
1637 | ||
474c8240 | 1638 | @smallexample |
0ee54786 EZ |
1639 | annotate_field (5); |
1640 | print_expression (b->exp, gdb_stdout); | |
474c8240 | 1641 | @end smallexample |
0ee54786 EZ |
1642 | |
1643 | The new version is: | |
1644 | ||
474c8240 | 1645 | @smallexample |
0ee54786 EZ |
1646 | struct ui_stream *stb = ui_out_stream_new (uiout); |
1647 | struct cleanup *old_chain = make_cleanup_ui_out_stream_delete (stb); | |
1648 | ... | |
1649 | annotate_field (5); | |
1650 | print_expression (b->exp, stb->stream); | |
1651 | ui_out_field_stream (uiout, "what", local_stream); | |
474c8240 | 1652 | @end smallexample |
0ee54786 EZ |
1653 | |
1654 | This example, also from @code{print_one_breakpoint}, shows how to use | |
1655 | @code{ui_out_text} and @code{ui_out_field_string}. The original code | |
1656 | was: | |
1657 | ||
474c8240 | 1658 | @smallexample |
0ee54786 EZ |
1659 | annotate_field (5); |
1660 | if (b->dll_pathname == NULL) | |
1661 | printf_filtered ("<any library> "); | |
1662 | else | |
1663 | printf_filtered ("library \"%s\" ", b->dll_pathname); | |
474c8240 | 1664 | @end smallexample |
0ee54786 EZ |
1665 | |
1666 | It became: | |
1667 | ||
474c8240 | 1668 | @smallexample |
0ee54786 EZ |
1669 | annotate_field (5); |
1670 | if (b->dll_pathname == NULL) | |
1671 | @{ | |
1672 | ui_out_field_string (uiout, "what", "<any library>"); | |
1673 | ui_out_spaces (uiout, 1); | |
1674 | @} | |
1675 | else | |
1676 | @{ | |
1677 | ui_out_text (uiout, "library \""); | |
1678 | ui_out_field_string (uiout, "what", b->dll_pathname); | |
1679 | ui_out_text (uiout, "\" "); | |
1680 | @} | |
474c8240 | 1681 | @end smallexample |
0ee54786 EZ |
1682 | |
1683 | The following example from @code{print_one_breakpoint} shows how to | |
1684 | use @code{ui_out_field_int} and @code{ui_out_spaces}. The original | |
1685 | code was: | |
1686 | ||
474c8240 | 1687 | @smallexample |
0ee54786 EZ |
1688 | annotate_field (5); |
1689 | if (b->forked_inferior_pid != 0) | |
1690 | printf_filtered ("process %d ", b->forked_inferior_pid); | |
474c8240 | 1691 | @end smallexample |
0ee54786 EZ |
1692 | |
1693 | It became: | |
1694 | ||
474c8240 | 1695 | @smallexample |
0ee54786 EZ |
1696 | annotate_field (5); |
1697 | if (b->forked_inferior_pid != 0) | |
1698 | @{ | |
1699 | ui_out_text (uiout, "process "); | |
1700 | ui_out_field_int (uiout, "what", b->forked_inferior_pid); | |
1701 | ui_out_spaces (uiout, 1); | |
1702 | @} | |
474c8240 | 1703 | @end smallexample |
0ee54786 EZ |
1704 | |
1705 | Here's an example of using @code{ui_out_field_string}. The original | |
1706 | code was: | |
1707 | ||
474c8240 | 1708 | @smallexample |
0ee54786 EZ |
1709 | annotate_field (5); |
1710 | if (b->exec_pathname != NULL) | |
1711 | printf_filtered ("program \"%s\" ", b->exec_pathname); | |
474c8240 | 1712 | @end smallexample |
0ee54786 EZ |
1713 | |
1714 | It became: | |
1715 | ||
474c8240 | 1716 | @smallexample |
0ee54786 EZ |
1717 | annotate_field (5); |
1718 | if (b->exec_pathname != NULL) | |
1719 | @{ | |
1720 | ui_out_text (uiout, "program \""); | |
1721 | ui_out_field_string (uiout, "what", b->exec_pathname); | |
1722 | ui_out_text (uiout, "\" "); | |
1723 | @} | |
474c8240 | 1724 | @end smallexample |
0ee54786 EZ |
1725 | |
1726 | Finally, here's an example of printing an address. The original code: | |
1727 | ||
474c8240 | 1728 | @smallexample |
0ee54786 EZ |
1729 | annotate_field (4); |
1730 | printf_filtered ("%s ", | |
15a661f3 | 1731 | hex_string_custom ((unsigned long) b->address, 8)); |
474c8240 | 1732 | @end smallexample |
0ee54786 EZ |
1733 | |
1734 | It became: | |
1735 | ||
474c8240 | 1736 | @smallexample |
0ee54786 EZ |
1737 | annotate_field (4); |
1738 | ui_out_field_core_addr (uiout, "Address", b->address); | |
474c8240 | 1739 | @end smallexample |
0ee54786 EZ |
1740 | |
1741 | ||
c906108c SS |
1742 | @section Console Printing |
1743 | ||
1744 | @section TUI | |
1745 | ||
89437448 | 1746 | @node libgdb |
c906108c | 1747 | |
89437448 AC |
1748 | @chapter libgdb |
1749 | ||
1750 | @section libgdb 1.0 | |
1751 | @cindex @code{libgdb} | |
1752 | @code{libgdb} 1.0 was an abortive project of years ago. The theory was | |
1753 | to provide an API to @value{GDBN}'s functionality. | |
1754 | ||
1755 | @section libgdb 2.0 | |
56caf160 | 1756 | @cindex @code{libgdb} |
89437448 AC |
1757 | @code{libgdb} 2.0 is an ongoing effort to update @value{GDBN} so that is |
1758 | better able to support graphical and other environments. | |
1759 | ||
1760 | Since @code{libgdb} development is on-going, its architecture is still | |
1761 | evolving. The following components have so far been identified: | |
1762 | ||
1763 | @itemize @bullet | |
1764 | @item | |
1765 | Observer - @file{gdb-events.h}. | |
1766 | @item | |
1767 | Builder - @file{ui-out.h} | |
1768 | @item | |
1769 | Event Loop - @file{event-loop.h} | |
1770 | @item | |
1771 | Library - @file{gdb.h} | |
1772 | @end itemize | |
1773 | ||
1774 | The model that ties these components together is described below. | |
1775 | ||
1776 | @section The @code{libgdb} Model | |
1777 | ||
1778 | A client of @code{libgdb} interacts with the library in two ways. | |
1779 | ||
1780 | @itemize @bullet | |
1781 | @item | |
1782 | As an observer (using @file{gdb-events}) receiving notifications from | |
1783 | @code{libgdb} of any internal state changes (break point changes, run | |
1784 | state, etc). | |
1785 | @item | |
1786 | As a client querying @code{libgdb} (using the @file{ui-out} builder) to | |
1787 | obtain various status values from @value{GDBN}. | |
1788 | @end itemize | |
1789 | ||
c1468174 | 1790 | Since @code{libgdb} could have multiple clients (e.g., a GUI supporting |
89437448 AC |
1791 | the existing @value{GDBN} CLI), those clients must co-operate when |
1792 | controlling @code{libgdb}. In particular, a client must ensure that | |
587afa38 | 1793 | @code{libgdb} is idle (i.e.@: no other client is using @code{libgdb}) |
89437448 AC |
1794 | before responding to a @file{gdb-event} by making a query. |
1795 | ||
1796 | @section CLI support | |
1797 | ||
1798 | At present @value{GDBN}'s CLI is very much entangled in with the core of | |
1799 | @code{libgdb}. Consequently, a client wishing to include the CLI in | |
1800 | their interface needs to carefully co-ordinate its own and the CLI's | |
1801 | requirements. | |
1802 | ||
1803 | It is suggested that the client set @code{libgdb} up to be bi-modal | |
1804 | (alternate between CLI and client query modes). The notes below sketch | |
1805 | out the theory: | |
1806 | ||
1807 | @itemize @bullet | |
1808 | @item | |
1809 | The client registers itself as an observer of @code{libgdb}. | |
1810 | @item | |
1811 | The client create and install @code{cli-out} builder using its own | |
1812 | versions of the @code{ui-file} @code{gdb_stderr}, @code{gdb_stdtarg} and | |
1813 | @code{gdb_stdout} streams. | |
1814 | @item | |
1815 | The client creates a separate custom @code{ui-out} builder that is only | |
1816 | used while making direct queries to @code{libgdb}. | |
1817 | @end itemize | |
1818 | ||
1819 | When the client receives input intended for the CLI, it simply passes it | |
1820 | along. Since the @code{cli-out} builder is installed by default, all | |
1821 | the CLI output in response to that command is routed (pronounced rooted) | |
1822 | through to the client controlled @code{gdb_stdout} et.@: al.@: streams. | |
1823 | At the same time, the client is kept abreast of internal changes by | |
1824 | virtue of being a @code{libgdb} observer. | |
1825 | ||
1826 | The only restriction on the client is that it must wait until | |
1827 | @code{libgdb} becomes idle before initiating any queries (using the | |
1828 | client's custom builder). | |
1829 | ||
1830 | @section @code{libgdb} components | |
1831 | ||
1832 | @subheading Observer - @file{gdb-events.h} | |
1833 | @file{gdb-events} provides the client with a very raw mechanism that can | |
1834 | be used to implement an observer. At present it only allows for one | |
1835 | observer and that observer must, internally, handle the need to delay | |
1836 | the processing of any event notifications until after @code{libgdb} has | |
1837 | finished the current command. | |
1838 | ||
1839 | @subheading Builder - @file{ui-out.h} | |
1840 | @file{ui-out} provides the infrastructure necessary for a client to | |
1841 | create a builder. That builder is then passed down to @code{libgdb} | |
1842 | when doing any queries. | |
1843 | ||
1844 | @subheading Event Loop - @file{event-loop.h} | |
1845 | @c There could be an entire section on the event-loop | |
1846 | @file{event-loop}, currently non-re-entrant, provides a simple event | |
1847 | loop. A client would need to either plug its self into this loop or, | |
587afa38 | 1848 | implement a new event-loop that @value{GDBN} would use. |
89437448 AC |
1849 | |
1850 | The event-loop will eventually be made re-entrant. This is so that | |
a9f12a31 | 1851 | @value{GDBN} can better handle the problem of some commands blocking |
89437448 AC |
1852 | instead of returning. |
1853 | ||
1854 | @subheading Library - @file{gdb.h} | |
1855 | @file{libgdb} is the most obvious component of this system. It provides | |
1856 | the query interface. Each function is parameterized by a @code{ui-out} | |
1857 | builder. The result of the query is constructed using that builder | |
1858 | before the query function returns. | |
c906108c | 1859 | |
5f5233d4 PA |
1860 | @node Values |
1861 | @chapter Values | |
1862 | @section Values | |
1863 | ||
1864 | @cindex values | |
1865 | @cindex @code{value} structure | |
1866 | @value{GDBN} uses @code{struct value}, or @dfn{values}, as an internal | |
1867 | abstraction for the representation of a variety of inferior objects | |
1868 | and @value{GDBN} convenience objects. | |
1869 | ||
1870 | Values have an associated @code{struct type}, that describes a virtual | |
1871 | view of the raw data or object stored in or accessed through the | |
1872 | value. | |
1873 | ||
1874 | A value is in addition discriminated by its lvalue-ness, given its | |
1875 | @code{enum lval_type} enumeration type: | |
1876 | ||
1877 | @cindex @code{lval_type} enumeration, for values. | |
1878 | @table @code | |
1879 | @item @code{not_lval} | |
1880 | This value is not an lval. It can't be assigned to. | |
1881 | ||
1882 | @item @code{lval_memory} | |
1883 | This value represents an object in memory. | |
1884 | ||
1885 | @item @code{lval_register} | |
1886 | This value represents an object that lives in a register. | |
1887 | ||
1888 | @item @code{lval_internalvar} | |
1889 | Represents the value of an internal variable. | |
1890 | ||
1891 | @item @code{lval_internalvar_component} | |
1892 | Represents part of a @value{GDBN} internal variable. E.g., a | |
1893 | structure field. | |
1894 | ||
1895 | @cindex computed values | |
1896 | @item @code{lval_computed} | |
1897 | These are ``computed'' values. They allow creating specialized value | |
1898 | objects for specific purposes, all abstracted away from the core value | |
1899 | support code. The creator of such a value writes specialized | |
1900 | functions to handle the reading and writing to/from the value's | |
1901 | backend data, and optionally, a ``copy operator'' and a | |
1902 | ``destructor''. | |
1903 | ||
1904 | Pointers to these functions are stored in a @code{struct lval_funcs} | |
1905 | instance (declared in @file{value.h}), and passed to the | |
1906 | @code{allocate_computed_value} function, as in the example below. | |
1907 | ||
1908 | @smallexample | |
1909 | static void | |
1910 | nil_value_read (struct value *v) | |
1911 | @{ | |
1912 | /* This callback reads data from some backend, and stores it in V. | |
1913 | In this case, we always read null data. You'll want to fill in | |
1914 | something more interesting. */ | |
1915 | ||
1916 | memset (value_contents_all_raw (v), | |
1917 | value_offset (v), | |
1918 | TYPE_LENGTH (value_type (v))); | |
1919 | @} | |
1920 | ||
1921 | static void | |
1922 | nil_value_write (struct value *v, struct value *fromval) | |
1923 | @{ | |
1924 | /* Takes the data from FROMVAL and stores it in the backend of V. */ | |
1925 | ||
1926 | to_oblivion (value_contents_all_raw (fromval), | |
1927 | value_offset (v), | |
1928 | TYPE_LENGTH (value_type (fromval))); | |
1929 | @} | |
1930 | ||
1931 | static struct lval_funcs nil_value_funcs = | |
1932 | @{ | |
1933 | nil_value_read, | |
1934 | nil_value_write | |
1935 | @}; | |
1936 | ||
1937 | struct value * | |
1938 | make_nil_value (void) | |
1939 | @{ | |
1940 | struct type *type; | |
1941 | struct value *v; | |
1942 | ||
1943 | type = make_nils_type (); | |
1944 | v = allocate_computed_value (type, &nil_value_funcs, NULL); | |
1945 | ||
1946 | return v; | |
1947 | @} | |
1948 | @end smallexample | |
1949 | ||
1950 | See the implementation of the @code{$_siginfo} convenience variable in | |
1951 | @file{infrun.c} as a real example use of lval_computed. | |
1952 | ||
1953 | @end table | |
1954 | ||
669fac23 DJ |
1955 | @node Stack Frames |
1956 | @chapter Stack Frames | |
1957 | ||
1958 | @cindex frame | |
1959 | @cindex call stack frame | |
1960 | A frame is a construct that @value{GDBN} uses to keep track of calling | |
1961 | and called functions. | |
1962 | ||
1963 | @cindex unwind frame | |
1964 | @value{GDBN}'s frame model, a fresh design, was implemented with the | |
1965 | need to support @sc{dwarf}'s Call Frame Information in mind. In fact, | |
1966 | the term ``unwind'' is taken directly from that specification. | |
1967 | Developers wishing to learn more about unwinders, are encouraged to | |
1968 | read the @sc{dwarf} specification, available from | |
1969 | @url{http://www.dwarfstd.org}. | |
1970 | ||
1971 | @findex frame_register_unwind | |
1972 | @findex get_frame_register | |
1973 | @value{GDBN}'s model is that you find a frame's registers by | |
1974 | ``unwinding'' them from the next younger frame. That is, | |
1975 | @samp{get_frame_register} which returns the value of a register in | |
1976 | frame #1 (the next-to-youngest frame), is implemented by calling frame | |
1977 | #0's @code{frame_register_unwind} (the youngest frame). But then the | |
1978 | obvious question is: how do you access the registers of the youngest | |
1979 | frame itself? | |
1980 | ||
1981 | @cindex sentinel frame | |
1982 | @findex get_frame_type | |
1983 | @vindex SENTINEL_FRAME | |
587afa38 | 1984 | To answer this question, @value{GDBN} has the @dfn{sentinel} frame, the |
669fac23 DJ |
1985 | ``-1st'' frame. Unwinding registers from the sentinel frame gives you |
1986 | the current values of the youngest real frame's registers. If @var{f} | |
1987 | is a sentinel frame, then @code{get_frame_type (@var{f}) @equiv{} | |
1988 | SENTINEL_FRAME}. | |
1989 | ||
1990 | @section Selecting an Unwinder | |
1991 | ||
1992 | @findex frame_unwind_prepend_unwinder | |
1993 | @findex frame_unwind_append_unwinder | |
1994 | The architecture registers a list of frame unwinders (@code{struct | |
1995 | frame_unwind}), using the functions | |
1996 | @code{frame_unwind_prepend_unwinder} and | |
1997 | @code{frame_unwind_append_unwinder}. Each unwinder includes a | |
1998 | sniffer. Whenever @value{GDBN} needs to unwind a frame (to fetch the | |
1999 | previous frame's registers or the current frame's ID), it calls | |
2000 | registered sniffers in order to find one which recognizes the frame. | |
2001 | The first time a sniffer returns non-zero, the corresponding unwinder | |
2002 | is assigned to the frame. | |
2003 | ||
2004 | @section Unwinding the Frame ID | |
2005 | @cindex frame ID | |
2006 | ||
2007 | Every frame has an associated ID, of type @code{struct frame_id}. | |
2008 | The ID includes the stack base and function start address for | |
2009 | the frame. The ID persists through the entire life of the frame, | |
2010 | including while other called frames are running; it is used to | |
2011 | locate an appropriate @code{struct frame_info} from the cache. | |
2012 | ||
2013 | Every time the inferior stops, and at various other times, the frame | |
2014 | cache is flushed. Because of this, parts of @value{GDBN} which need | |
2015 | to keep track of individual frames cannot use pointers to @code{struct | |
2016 | frame_info}. A frame ID provides a stable reference to a frame, even | |
2017 | when the unwinder must be run again to generate a new @code{struct | |
2018 | frame_info} for the same frame. | |
2019 | ||
2020 | The frame's unwinder's @code{this_id} method is called to find the ID. | |
2021 | Note that this is different from register unwinding, where the next | |
2022 | frame's @code{prev_register} is called to unwind this frame's | |
2023 | registers. | |
2024 | ||
2025 | Both stack base and function address are required to identify the | |
2026 | frame, because a recursive function has the same function address for | |
2027 | two consecutive frames and a leaf function may have the same stack | |
2028 | address as its caller. On some platforms, a third address is part of | |
2029 | the ID to further disambiguate frames---for instance, on IA-64 | |
2030 | the separate register stack address is included in the ID. | |
2031 | ||
005ca36a | 2032 | An invalid frame ID (@code{outer_frame_id}) returned from the |
669fac23 DJ |
2033 | @code{this_id} method means to stop unwinding after this frame. |
2034 | ||
005ca36a JB |
2035 | @code{null_frame_id} is another invalid frame ID which should be used |
2036 | when there is no frame. For instance, certain breakpoints are attached | |
2037 | to a specific frame, and that frame is identified through its frame ID | |
2038 | (we use this to implement the "finish" command). Using | |
2039 | @code{null_frame_id} as the frame ID for a given breakpoint means | |
2040 | that the breakpoint is not specific to any frame. The @code{this_id} | |
2041 | method should never return @code{null_frame_id}. | |
2042 | ||
669fac23 DJ |
2043 | @section Unwinding Registers |
2044 | ||
2045 | Each unwinder includes a @code{prev_register} method. This method | |
2046 | takes a frame, an associated cache pointer, and a register number. | |
2047 | It returns a @code{struct value *} describing the requested register, | |
2048 | as saved by this frame. This is the value of the register that is | |
2049 | current in this frame's caller. | |
2050 | ||
2051 | The returned value must have the same type as the register. It may | |
2052 | have any lvalue type. In most circumstances one of these routines | |
2053 | will generate the appropriate value: | |
2054 | ||
2055 | @table @code | |
2056 | @item frame_unwind_got_optimized | |
2057 | @findex frame_unwind_got_optimized | |
2058 | This register was not saved. | |
2059 | ||
2060 | @item frame_unwind_got_register | |
2061 | @findex frame_unwind_got_register | |
2062 | This register was copied into another register in this frame. This | |
2063 | is also used for unchanged registers; they are ``copied'' into the | |
2064 | same register. | |
2065 | ||
2066 | @item frame_unwind_got_memory | |
2067 | @findex frame_unwind_got_memory | |
2068 | This register was saved in memory. | |
2069 | ||
2070 | @item frame_unwind_got_constant | |
2071 | @findex frame_unwind_got_constant | |
2072 | This register was not saved, but the unwinder can compute the previous | |
2073 | value some other way. | |
2074 | ||
2075 | @item frame_unwind_got_address | |
2076 | @findex frame_unwind_got_address | |
2077 | Same as @code{frame_unwind_got_constant}, except that the value is a target | |
2078 | address. This is frequently used for the stack pointer, which is not | |
2079 | explicitly saved but has a known offset from this frame's stack | |
2080 | pointer. For architectures with a flat unified address space, this is | |
2081 | generally the same as @code{frame_unwind_got_constant}. | |
2082 | @end table | |
2083 | ||
c906108c SS |
2084 | @node Symbol Handling |
2085 | ||
2086 | @chapter Symbol Handling | |
2087 | ||
1f70da6a SS |
2088 | Symbols are a key part of @value{GDBN}'s operation. Symbols include |
2089 | variables, functions, and types. | |
2090 | ||
2091 | Symbol information for a large program can be truly massive, and | |
2092 | reading of symbol information is one of the major performance | |
2093 | bottlenecks in @value{GDBN}; it can take many minutes to process it | |
2094 | all. Studies have shown that nearly all the time spent is | |
2095 | computational, rather than file reading. | |
2096 | ||
2097 | One of the ways for @value{GDBN} to provide a good user experience is | |
2098 | to start up quickly, taking no more than a few seconds. It is simply | |
2099 | not possible to process all of a program's debugging info in that | |
2100 | time, and so we attempt to handle symbols incrementally. For instance, | |
2101 | we create @dfn{partial symbol tables} consisting of only selected | |
2102 | symbols, and only expand them to full symbol tables when necessary. | |
c906108c SS |
2103 | |
2104 | @section Symbol Reading | |
2105 | ||
56caf160 EZ |
2106 | @cindex symbol reading |
2107 | @cindex reading of symbols | |
2108 | @cindex symbol files | |
2109 | @value{GDBN} reads symbols from @dfn{symbol files}. The usual symbol | |
2110 | file is the file containing the program which @value{GDBN} is | |
2111 | debugging. @value{GDBN} can be directed to use a different file for | |
2112 | symbols (with the @samp{symbol-file} command), and it can also read | |
1f70da6a SS |
2113 | more symbols via the @samp{add-file} and @samp{load} commands. In |
2114 | addition, it may bring in more symbols while loading shared | |
2115 | libraries. | |
56caf160 EZ |
2116 | |
2117 | @findex find_sym_fns | |
2118 | Symbol files are initially opened by code in @file{symfile.c} using | |
2119 | the BFD library (@pxref{Support Libraries}). BFD identifies the type | |
2120 | of the file by examining its header. @code{find_sym_fns} then uses | |
2121 | this identification to locate a set of symbol-reading functions. | |
2122 | ||
2123 | @findex add_symtab_fns | |
2124 | @cindex @code{sym_fns} structure | |
2125 | @cindex adding a symbol-reading module | |
2126 | Symbol-reading modules identify themselves to @value{GDBN} by calling | |
c906108c SS |
2127 | @code{add_symtab_fns} during their module initialization. The argument |
2128 | to @code{add_symtab_fns} is a @code{struct sym_fns} which contains the | |
2129 | name (or name prefix) of the symbol format, the length of the prefix, | |
2130 | and pointers to four functions. These functions are called at various | |
56caf160 | 2131 | times to process symbol files whose identification matches the specified |
c906108c SS |
2132 | prefix. |
2133 | ||
2134 | The functions supplied by each module are: | |
2135 | ||
2136 | @table @code | |
2137 | @item @var{xyz}_symfile_init(struct sym_fns *sf) | |
2138 | ||
56caf160 | 2139 | @cindex secondary symbol file |
c906108c SS |
2140 | Called from @code{symbol_file_add} when we are about to read a new |
2141 | symbol file. This function should clean up any internal state (possibly | |
2142 | resulting from half-read previous files, for example) and prepare to | |
56caf160 EZ |
2143 | read a new symbol file. Note that the symbol file which we are reading |
2144 | might be a new ``main'' symbol file, or might be a secondary symbol file | |
c906108c SS |
2145 | whose symbols are being added to the existing symbol table. |
2146 | ||
2147 | The argument to @code{@var{xyz}_symfile_init} is a newly allocated | |
2148 | @code{struct sym_fns} whose @code{bfd} field contains the BFD for the | |
2149 | new symbol file being read. Its @code{private} field has been zeroed, | |
2150 | and can be modified as desired. Typically, a struct of private | |
2151 | information will be @code{malloc}'d, and a pointer to it will be placed | |
2152 | in the @code{private} field. | |
2153 | ||
2154 | There is no result from @code{@var{xyz}_symfile_init}, but it can call | |
2155 | @code{error} if it detects an unavoidable problem. | |
2156 | ||
2157 | @item @var{xyz}_new_init() | |
2158 | ||
2159 | Called from @code{symbol_file_add} when discarding existing symbols. | |
56caf160 EZ |
2160 | This function needs only handle the symbol-reading module's internal |
2161 | state; the symbol table data structures visible to the rest of | |
2162 | @value{GDBN} will be discarded by @code{symbol_file_add}. It has no | |
2163 | arguments and no result. It may be called after | |
2164 | @code{@var{xyz}_symfile_init}, if a new symbol table is being read, or | |
2165 | may be called alone if all symbols are simply being discarded. | |
c906108c SS |
2166 | |
2167 | @item @var{xyz}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline) | |
2168 | ||
2169 | Called from @code{symbol_file_add} to actually read the symbols from a | |
2170 | symbol-file into a set of psymtabs or symtabs. | |
2171 | ||
56caf160 | 2172 | @code{sf} points to the @code{struct sym_fns} originally passed to |
c906108c SS |
2173 | @code{@var{xyz}_sym_init} for possible initialization. @code{addr} is |
2174 | the offset between the file's specified start address and its true | |
2175 | address in memory. @code{mainline} is 1 if this is the main symbol | |
c1468174 | 2176 | table being read, and 0 if a secondary symbol file (e.g., shared library |
c906108c SS |
2177 | or dynamically loaded file) is being read.@refill |
2178 | @end table | |
2179 | ||
2180 | In addition, if a symbol-reading module creates psymtabs when | |
2181 | @var{xyz}_symfile_read is called, these psymtabs will contain a pointer | |
2182 | to a function @code{@var{xyz}_psymtab_to_symtab}, which can be called | |
25822942 | 2183 | from any point in the @value{GDBN} symbol-handling code. |
c906108c SS |
2184 | |
2185 | @table @code | |
2186 | @item @var{xyz}_psymtab_to_symtab (struct partial_symtab *pst) | |
2187 | ||
56caf160 | 2188 | Called from @code{psymtab_to_symtab} (or the @code{PSYMTAB_TO_SYMTAB} macro) if |
c906108c SS |
2189 | the psymtab has not already been read in and had its @code{pst->symtab} |
2190 | pointer set. The argument is the psymtab to be fleshed-out into a | |
56caf160 EZ |
2191 | symtab. Upon return, @code{pst->readin} should have been set to 1, and |
2192 | @code{pst->symtab} should contain a pointer to the new corresponding symtab, or | |
c906108c SS |
2193 | zero if there were no symbols in that part of the symbol file. |
2194 | @end table | |
2195 | ||
2196 | @section Partial Symbol Tables | |
2197 | ||
56caf160 | 2198 | @value{GDBN} has three types of symbol tables: |
c906108c SS |
2199 | |
2200 | @itemize @bullet | |
56caf160 EZ |
2201 | @cindex full symbol table |
2202 | @cindex symtabs | |
2203 | @item | |
2204 | Full symbol tables (@dfn{symtabs}). These contain the main | |
2205 | information about symbols and addresses. | |
c906108c | 2206 | |
56caf160 EZ |
2207 | @cindex psymtabs |
2208 | @item | |
2209 | Partial symbol tables (@dfn{psymtabs}). These contain enough | |
c906108c SS |
2210 | information to know when to read the corresponding part of the full |
2211 | symbol table. | |
2212 | ||
56caf160 EZ |
2213 | @cindex minimal symbol table |
2214 | @cindex minsymtabs | |
2215 | @item | |
2216 | Minimal symbol tables (@dfn{msymtabs}). These contain information | |
c906108c | 2217 | gleaned from non-debugging symbols. |
c906108c SS |
2218 | @end itemize |
2219 | ||
56caf160 | 2220 | @cindex partial symbol table |
c906108c SS |
2221 | This section describes partial symbol tables. |
2222 | ||
2223 | A psymtab is constructed by doing a very quick pass over an executable | |
2224 | file's debugging information. Small amounts of information are | |
56caf160 | 2225 | extracted---enough to identify which parts of the symbol table will |
c906108c | 2226 | need to be re-read and fully digested later, when the user needs the |
25822942 | 2227 | information. The speed of this pass causes @value{GDBN} to start up very |
c906108c SS |
2228 | quickly. Later, as the detailed rereading occurs, it occurs in small |
2229 | pieces, at various times, and the delay therefrom is mostly invisible to | |
2230 | the user. | |
2231 | @c (@xref{Symbol Reading}.) | |
2232 | ||
2233 | The symbols that show up in a file's psymtab should be, roughly, those | |
2234 | visible to the debugger's user when the program is not running code from | |
2235 | that file. These include external symbols and types, static symbols and | |
56caf160 | 2236 | types, and @code{enum} values declared at file scope. |
c906108c SS |
2237 | |
2238 | The psymtab also contains the range of instruction addresses that the | |
2239 | full symbol table would represent. | |
2240 | ||
56caf160 EZ |
2241 | @cindex finding a symbol |
2242 | @cindex symbol lookup | |
c906108c SS |
2243 | The idea is that there are only two ways for the user (or much of the |
2244 | code in the debugger) to reference a symbol: | |
2245 | ||
2246 | @itemize @bullet | |
56caf160 EZ |
2247 | @findex find_pc_function |
2248 | @findex find_pc_line | |
2249 | @item | |
c1468174 | 2250 | By its address (e.g., execution stops at some address which is inside a |
56caf160 EZ |
2251 | function in this file). The address will be noticed to be in the |
2252 | range of this psymtab, and the full symtab will be read in. | |
2253 | @code{find_pc_function}, @code{find_pc_line}, and other | |
2254 | @code{find_pc_@dots{}} functions handle this. | |
c906108c | 2255 | |
56caf160 EZ |
2256 | @cindex lookup_symbol |
2257 | @item | |
2258 | By its name | |
c1468174 | 2259 | (e.g., the user asks to print a variable, or set a breakpoint on a |
c906108c SS |
2260 | function). Global names and file-scope names will be found in the |
2261 | psymtab, which will cause the symtab to be pulled in. Local names will | |
2262 | have to be qualified by a global name, or a file-scope name, in which | |
2263 | case we will have already read in the symtab as we evaluated the | |
56caf160 | 2264 | qualifier. Or, a local symbol can be referenced when we are ``in'' a |
c906108c SS |
2265 | local scope, in which case the first case applies. @code{lookup_symbol} |
2266 | does most of the work here. | |
c906108c SS |
2267 | @end itemize |
2268 | ||
2269 | The only reason that psymtabs exist is to cause a symtab to be read in | |
2270 | at the right moment. Any symbol that can be elided from a psymtab, | |
2271 | while still causing that to happen, should not appear in it. Since | |
2272 | psymtabs don't have the idea of scope, you can't put local symbols in | |
2273 | them anyway. Psymtabs don't have the idea of the type of a symbol, | |
2274 | either, so types need not appear, unless they will be referenced by | |
2275 | name. | |
2276 | ||
56caf160 EZ |
2277 | It is a bug for @value{GDBN} to behave one way when only a psymtab has |
2278 | been read, and another way if the corresponding symtab has been read | |
2279 | in. Such bugs are typically caused by a psymtab that does not contain | |
2280 | all the visible symbols, or which has the wrong instruction address | |
2281 | ranges. | |
c906108c | 2282 | |
56caf160 | 2283 | The psymtab for a particular section of a symbol file (objfile) could be |
c906108c SS |
2284 | thrown away after the symtab has been read in. The symtab should always |
2285 | be searched before the psymtab, so the psymtab will never be used (in a | |
2286 | bug-free environment). Currently, psymtabs are allocated on an obstack, | |
2287 | and all the psymbols themselves are allocated in a pair of large arrays | |
2288 | on an obstack, so there is little to be gained by trying to free them | |
2289 | unless you want to do a lot more work. | |
2290 | ||
ccefe4c4 TT |
2291 | Whether or not psymtabs are created depends on the objfile's symbol |
2292 | reader. The core of @value{GDBN} hides the details of partial symbols | |
2293 | and partial symbol tables behind a set of function pointers known as | |
2294 | the @dfn{quick symbol functions}. These are documented in | |
2295 | @file{symfile.h}. | |
2296 | ||
c906108c SS |
2297 | @section Types |
2298 | ||
56caf160 | 2299 | @unnumberedsubsec Fundamental Types (e.g., @code{FT_VOID}, @code{FT_BOOLEAN}). |
c906108c | 2300 | |
56caf160 | 2301 | @cindex fundamental types |
25822942 | 2302 | These are the fundamental types that @value{GDBN} uses internally. Fundamental |
c906108c SS |
2303 | types from the various debugging formats (stabs, ELF, etc) are mapped |
2304 | into one of these. They are basically a union of all fundamental types | |
56caf160 EZ |
2305 | that @value{GDBN} knows about for all the languages that @value{GDBN} |
2306 | knows about. | |
c906108c | 2307 | |
56caf160 | 2308 | @unnumberedsubsec Type Codes (e.g., @code{TYPE_CODE_PTR}, @code{TYPE_CODE_ARRAY}). |
c906108c | 2309 | |
56caf160 EZ |
2310 | @cindex type codes |
2311 | Each time @value{GDBN} builds an internal type, it marks it with one | |
2312 | of these types. The type may be a fundamental type, such as | |
2313 | @code{TYPE_CODE_INT}, or a derived type, such as @code{TYPE_CODE_PTR} | |
2314 | which is a pointer to another type. Typically, several @code{FT_*} | |
2315 | types map to one @code{TYPE_CODE_*} type, and are distinguished by | |
2316 | other members of the type struct, such as whether the type is signed | |
2317 | or unsigned, and how many bits it uses. | |
c906108c | 2318 | |
56caf160 | 2319 | @unnumberedsubsec Builtin Types (e.g., @code{builtin_type_void}, @code{builtin_type_char}). |
c906108c SS |
2320 | |
2321 | These are instances of type structs that roughly correspond to | |
56caf160 EZ |
2322 | fundamental types and are created as global types for @value{GDBN} to |
2323 | use for various ugly historical reasons. We eventually want to | |
2324 | eliminate these. Note for example that @code{builtin_type_int} | |
2325 | initialized in @file{gdbtypes.c} is basically the same as a | |
2326 | @code{TYPE_CODE_INT} type that is initialized in @file{c-lang.c} for | |
2327 | an @code{FT_INTEGER} fundamental type. The difference is that the | |
2328 | @code{builtin_type} is not associated with any particular objfile, and | |
2329 | only one instance exists, while @file{c-lang.c} builds as many | |
2330 | @code{TYPE_CODE_INT} types as needed, with each one associated with | |
2331 | some particular objfile. | |
c906108c SS |
2332 | |
2333 | @section Object File Formats | |
56caf160 | 2334 | @cindex object file formats |
c906108c SS |
2335 | |
2336 | @subsection a.out | |
2337 | ||
56caf160 EZ |
2338 | @cindex @code{a.out} format |
2339 | The @code{a.out} format is the original file format for Unix. It | |
2340 | consists of three sections: @code{text}, @code{data}, and @code{bss}, | |
2341 | which are for program code, initialized data, and uninitialized data, | |
2342 | respectively. | |
c906108c | 2343 | |
56caf160 | 2344 | The @code{a.out} format is so simple that it doesn't have any reserved |
c906108c | 2345 | place for debugging information. (Hey, the original Unix hackers used |
56caf160 EZ |
2346 | @samp{adb}, which is a machine-language debugger!) The only debugging |
2347 | format for @code{a.out} is stabs, which is encoded as a set of normal | |
c906108c SS |
2348 | symbols with distinctive attributes. |
2349 | ||
56caf160 | 2350 | The basic @code{a.out} reader is in @file{dbxread.c}. |
c906108c SS |
2351 | |
2352 | @subsection COFF | |
2353 | ||
56caf160 | 2354 | @cindex COFF format |
c906108c SS |
2355 | The COFF format was introduced with System V Release 3 (SVR3) Unix. |
2356 | COFF files may have multiple sections, each prefixed by a header. The | |
2357 | number of sections is limited. | |
2358 | ||
2359 | The COFF specification includes support for debugging. Although this | |
1f70da6a SS |
2360 | was a step forward, the debugging information was woefully limited. |
2361 | For instance, it was not possible to represent code that came from an | |
2362 | included file. GNU's COFF-using configs often use stabs-type info, | |
2363 | encapsulated in special sections. | |
c906108c SS |
2364 | |
2365 | The COFF reader is in @file{coffread.c}. | |
2366 | ||
2367 | @subsection ECOFF | |
2368 | ||
56caf160 | 2369 | @cindex ECOFF format |
c906108c SS |
2370 | ECOFF is an extended COFF originally introduced for Mips and Alpha |
2371 | workstations. | |
2372 | ||
2373 | The basic ECOFF reader is in @file{mipsread.c}. | |
2374 | ||
2375 | @subsection XCOFF | |
2376 | ||
56caf160 | 2377 | @cindex XCOFF format |
c906108c SS |
2378 | The IBM RS/6000 running AIX uses an object file format called XCOFF. |
2379 | The COFF sections, symbols, and line numbers are used, but debugging | |
56caf160 EZ |
2380 | symbols are @code{dbx}-style stabs whose strings are located in the |
2381 | @code{.debug} section (rather than the string table). For more | |
2382 | information, see @ref{Top,,,stabs,The Stabs Debugging Format}. | |
c906108c SS |
2383 | |
2384 | The shared library scheme has a clean interface for figuring out what | |
2385 | shared libraries are in use, but the catch is that everything which | |
2386 | refers to addresses (symbol tables and breakpoints at least) needs to be | |
2387 | relocated for both shared libraries and the main executable. At least | |
2388 | using the standard mechanism this can only be done once the program has | |
2389 | been run (or the core file has been read). | |
2390 | ||
2391 | @subsection PE | |
2392 | ||
56caf160 EZ |
2393 | @cindex PE-COFF format |
2394 | Windows 95 and NT use the PE (@dfn{Portable Executable}) format for their | |
c906108c SS |
2395 | executables. PE is basically COFF with additional headers. |
2396 | ||
25822942 | 2397 | While BFD includes special PE support, @value{GDBN} needs only the basic |
c906108c SS |
2398 | COFF reader. |
2399 | ||
2400 | @subsection ELF | |
2401 | ||
56caf160 | 2402 | @cindex ELF format |
1f70da6a SS |
2403 | The ELF format came with System V Release 4 (SVR4) Unix. ELF is |
2404 | similar to COFF in being organized into a number of sections, but it | |
2405 | removes many of COFF's limitations. Debugging info may be either stabs | |
2406 | encapsulated in ELF sections, or more commonly these days, DWARF. | |
c906108c SS |
2407 | |
2408 | The basic ELF reader is in @file{elfread.c}. | |
2409 | ||
2410 | @subsection SOM | |
2411 | ||
56caf160 | 2412 | @cindex SOM format |
c906108c SS |
2413 | SOM is HP's object file and debug format (not to be confused with IBM's |
2414 | SOM, which is a cross-language ABI). | |
2415 | ||
1a92f856 | 2416 | The SOM reader is in @file{somread.c}. |
c906108c | 2417 | |
c906108c SS |
2418 | @section Debugging File Formats |
2419 | ||
2420 | This section describes characteristics of debugging information that | |
2421 | are independent of the object file format. | |
2422 | ||
2423 | @subsection stabs | |
2424 | ||
56caf160 | 2425 | @cindex stabs debugging info |
c906108c SS |
2426 | @code{stabs} started out as special symbols within the @code{a.out} |
2427 | format. Since then, it has been encapsulated into other file | |
2428 | formats, such as COFF and ELF. | |
2429 | ||
2430 | While @file{dbxread.c} does some of the basic stab processing, | |
2431 | including for encapsulated versions, @file{stabsread.c} does | |
2432 | the real work. | |
2433 | ||
2434 | @subsection COFF | |
2435 | ||
56caf160 | 2436 | @cindex COFF debugging info |
c906108c SS |
2437 | The basic COFF definition includes debugging information. The level |
2438 | of support is minimal and non-extensible, and is not often used. | |
2439 | ||
2440 | @subsection Mips debug (Third Eye) | |
2441 | ||
56caf160 | 2442 | @cindex ECOFF debugging info |
c906108c SS |
2443 | ECOFF includes a definition of a special debug format. |
2444 | ||
2445 | The file @file{mdebugread.c} implements reading for this format. | |
2446 | ||
1f70da6a SS |
2447 | @c mention DWARF 1 as a formerly-supported format |
2448 | ||
c906108c SS |
2449 | @subsection DWARF 2 |
2450 | ||
56caf160 | 2451 | @cindex DWARF 2 debugging info |
c906108c SS |
2452 | DWARF 2 is an improved but incompatible version of DWARF 1. |
2453 | ||
2454 | The DWARF 2 reader is in @file{dwarf2read.c}. | |
2455 | ||
31fffb02 CS |
2456 | @subsection Compressed DWARF 2 |
2457 | ||
2458 | @cindex Compressed DWARF 2 debugging info | |
2459 | Compressed DWARF 2 is not technically a separate debugging format, but | |
2460 | merely DWARF 2 debug information that has been compressed. In this | |
2461 | format, every object-file section holding DWARF 2 debugging | |
2462 | information is compressed and prepended with a header. (The section | |
2463 | is also typically renamed, so a section called @code{.debug_info} in a | |
2464 | DWARF 2 binary would be called @code{.zdebug_info} in a compressed | |
2465 | DWARF 2 binary.) The header is 12 bytes long: | |
2466 | ||
2467 | @itemize @bullet | |
2468 | @item | |
2469 | 4 bytes: the literal string ``ZLIB'' | |
2470 | @item | |
2471 | 8 bytes: the uncompressed size of the section, in big-endian byte | |
2472 | order. | |
2473 | @end itemize | |
2474 | ||
2475 | The same reader is used for both compressed an normal DWARF 2 info. | |
2476 | Section decompression is done in @code{zlib_decompress_section} in | |
2477 | @file{dwarf2read.c}. | |
2478 | ||
1f70da6a SS |
2479 | @subsection DWARF 3 |
2480 | ||
2481 | @cindex DWARF 3 debugging info | |
2482 | DWARF 3 is an improved version of DWARF 2. | |
2483 | ||
c906108c SS |
2484 | @subsection SOM |
2485 | ||
56caf160 | 2486 | @cindex SOM debugging info |
c906108c SS |
2487 | Like COFF, the SOM definition includes debugging information. |
2488 | ||
25822942 | 2489 | @section Adding a New Symbol Reader to @value{GDBN} |
c906108c | 2490 | |
56caf160 EZ |
2491 | @cindex adding debugging info reader |
2492 | If you are using an existing object file format (@code{a.out}, COFF, ELF, etc), | |
c906108c SS |
2493 | there is probably little to be done. |
2494 | ||
2495 | If you need to add a new object file format, you must first add it to | |
2496 | BFD. This is beyond the scope of this document. | |
2497 | ||
2498 | You must then arrange for the BFD code to provide access to the | |
1f70da6a SS |
2499 | debugging symbols. Generally @value{GDBN} will have to call swapping |
2500 | routines from BFD and a few other BFD internal routines to locate the | |
2501 | debugging information. As much as possible, @value{GDBN} should not | |
2502 | depend on the BFD internal data structures. | |
c906108c SS |
2503 | |
2504 | For some targets (e.g., COFF), there is a special transfer vector used | |
2505 | to call swapping routines, since the external data structures on various | |
2506 | platforms have different sizes and layouts. Specialized routines that | |
2507 | will only ever be implemented by one object file format may be called | |
2508 | directly. This interface should be described in a file | |
56caf160 | 2509 | @file{bfd/lib@var{xyz}.h}, which is included by @value{GDBN}. |
c906108c | 2510 | |
c91d38aa DJ |
2511 | @section Memory Management for Symbol Files |
2512 | ||
2513 | Most memory associated with a loaded symbol file is stored on | |
2514 | its @code{objfile_obstack}. This includes symbols, types, | |
2515 | namespace data, and other information produced by the symbol readers. | |
2516 | ||
2517 | Because this data lives on the objfile's obstack, it is automatically | |
2518 | released when the objfile is unloaded or reloaded. Therefore one | |
2519 | objfile must not reference symbol or type data from another objfile; | |
2520 | they could be unloaded at different times. | |
2521 | ||
2522 | User convenience variables, et cetera, have associated types. Normally | |
2523 | these types live in the associated objfile. However, when the objfile | |
2524 | is unloaded, those types are deep copied to global memory, so that | |
2525 | the values of the user variables and history items are not lost. | |
2526 | ||
c906108c SS |
2527 | |
2528 | @node Language Support | |
2529 | ||
2530 | @chapter Language Support | |
2531 | ||
56caf160 EZ |
2532 | @cindex language support |
2533 | @value{GDBN}'s language support is mainly driven by the symbol reader, | |
2534 | although it is possible for the user to set the source language | |
2535 | manually. | |
c906108c | 2536 | |
56caf160 EZ |
2537 | @value{GDBN} chooses the source language by looking at the extension |
2538 | of the file recorded in the debug info; @file{.c} means C, @file{.f} | |
2539 | means Fortran, etc. It may also use a special-purpose language | |
2540 | identifier if the debug format supports it, like with DWARF. | |
c906108c | 2541 | |
25822942 | 2542 | @section Adding a Source Language to @value{GDBN} |
c906108c | 2543 | |
56caf160 EZ |
2544 | @cindex adding source language |
2545 | To add other languages to @value{GDBN}'s expression parser, follow the | |
2546 | following steps: | |
c906108c SS |
2547 | |
2548 | @table @emph | |
2549 | @item Create the expression parser. | |
2550 | ||
56caf160 | 2551 | @cindex expression parser |
c906108c | 2552 | This should reside in a file @file{@var{lang}-exp.y}. Routines for |
56caf160 | 2553 | building parsed expressions into a @code{union exp_element} list are in |
c906108c SS |
2554 | @file{parse.c}. |
2555 | ||
56caf160 | 2556 | @cindex language parser |
c906108c SS |
2557 | Since we can't depend upon everyone having Bison, and YACC produces |
2558 | parsers that define a bunch of global names, the following lines | |
56caf160 | 2559 | @strong{must} be included at the top of the YACC parser, to prevent the |
c906108c SS |
2560 | various parsers from defining the same global names: |
2561 | ||
474c8240 | 2562 | @smallexample |
56caf160 EZ |
2563 | #define yyparse @var{lang}_parse |
2564 | #define yylex @var{lang}_lex | |
2565 | #define yyerror @var{lang}_error | |
2566 | #define yylval @var{lang}_lval | |
2567 | #define yychar @var{lang}_char | |
2568 | #define yydebug @var{lang}_debug | |
2569 | #define yypact @var{lang}_pact | |
2570 | #define yyr1 @var{lang}_r1 | |
2571 | #define yyr2 @var{lang}_r2 | |
2572 | #define yydef @var{lang}_def | |
2573 | #define yychk @var{lang}_chk | |
2574 | #define yypgo @var{lang}_pgo | |
2575 | #define yyact @var{lang}_act | |
2576 | #define yyexca @var{lang}_exca | |
2577 | #define yyerrflag @var{lang}_errflag | |
2578 | #define yynerrs @var{lang}_nerrs | |
474c8240 | 2579 | @end smallexample |
c906108c SS |
2580 | |
2581 | At the bottom of your parser, define a @code{struct language_defn} and | |
2582 | initialize it with the right values for your language. Define an | |
2583 | @code{initialize_@var{lang}} routine and have it call | |
25822942 | 2584 | @samp{add_language(@var{lang}_language_defn)} to tell the rest of @value{GDBN} |
c906108c SS |
2585 | that your language exists. You'll need some other supporting variables |
2586 | and functions, which will be used via pointers from your | |
2587 | @code{@var{lang}_language_defn}. See the declaration of @code{struct | |
2588 | language_defn} in @file{language.h}, and the other @file{*-exp.y} files, | |
2589 | for more information. | |
2590 | ||
2591 | @item Add any evaluation routines, if necessary | |
2592 | ||
56caf160 EZ |
2593 | @cindex expression evaluation routines |
2594 | @findex evaluate_subexp | |
2595 | @findex prefixify_subexp | |
2596 | @findex length_of_subexp | |
c906108c SS |
2597 | If you need new opcodes (that represent the operations of the language), |
2598 | add them to the enumerated type in @file{expression.h}. Add support | |
56caf160 EZ |
2599 | code for these operations in the @code{evaluate_subexp} function |
2600 | defined in the file @file{eval.c}. Add cases | |
c906108c | 2601 | for new opcodes in two functions from @file{parse.c}: |
56caf160 | 2602 | @code{prefixify_subexp} and @code{length_of_subexp}. These compute |
c906108c SS |
2603 | the number of @code{exp_element}s that a given operation takes up. |
2604 | ||
2605 | @item Update some existing code | |
2606 | ||
2607 | Add an enumerated identifier for your language to the enumerated type | |
2608 | @code{enum language} in @file{defs.h}. | |
2609 | ||
2610 | Update the routines in @file{language.c} so your language is included. | |
2611 | These routines include type predicates and such, which (in some cases) | |
2612 | are language dependent. If your language does not appear in the switch | |
2613 | statement, an error is reported. | |
2614 | ||
56caf160 | 2615 | @vindex current_language |
c906108c SS |
2616 | Also included in @file{language.c} is the code that updates the variable |
2617 | @code{current_language}, and the routines that translate the | |
2618 | @code{language_@var{lang}} enumerated identifier into a printable | |
2619 | string. | |
2620 | ||
56caf160 | 2621 | @findex _initialize_language |
c906108c SS |
2622 | Update the function @code{_initialize_language} to include your |
2623 | language. This function picks the default language upon startup, so is | |
25822942 | 2624 | dependent upon which languages that @value{GDBN} is built for. |
c906108c | 2625 | |
56caf160 | 2626 | @findex allocate_symtab |
c906108c SS |
2627 | Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading |
2628 | code so that the language of each symtab (source file) is set properly. | |
2629 | This is used to determine the language to use at each stack frame level. | |
2630 | Currently, the language is set based upon the extension of the source | |
2631 | file. If the language can be better inferred from the symbol | |
2632 | information, please set the language of the symtab in the symbol-reading | |
2633 | code. | |
2634 | ||
56caf160 EZ |
2635 | @findex print_subexp |
2636 | @findex op_print_tab | |
2637 | Add helper code to @code{print_subexp} (in @file{expprint.c}) to handle any new | |
c906108c SS |
2638 | expression opcodes you have added to @file{expression.h}. Also, add the |
2639 | printed representations of your operators to @code{op_print_tab}. | |
2640 | ||
2641 | @item Add a place of call | |
2642 | ||
56caf160 | 2643 | @findex parse_exp_1 |
c906108c | 2644 | Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in |
56caf160 | 2645 | @code{parse_exp_1} (defined in @file{parse.c}). |
c906108c | 2646 | |
c906108c SS |
2647 | @item Edit @file{Makefile.in} |
2648 | ||
2649 | Add dependencies in @file{Makefile.in}. Make sure you update the macro | |
2650 | variables such as @code{HFILES} and @code{OBJS}, otherwise your code may | |
2651 | not get linked in, or, worse yet, it may not get @code{tar}red into the | |
2652 | distribution! | |
c906108c SS |
2653 | @end table |
2654 | ||
2655 | ||
2656 | @node Host Definition | |
2657 | ||
2658 | @chapter Host Definition | |
2659 | ||
56caf160 | 2660 | With the advent of Autoconf, it's rarely necessary to have host |
7fd60527 AC |
2661 | definition machinery anymore. The following information is provided, |
2662 | mainly, as an historical reference. | |
c906108c SS |
2663 | |
2664 | @section Adding a New Host | |
2665 | ||
56caf160 EZ |
2666 | @cindex adding a new host |
2667 | @cindex host, adding | |
7fd60527 AC |
2668 | @value{GDBN}'s host configuration support normally happens via Autoconf. |
2669 | New host-specific definitions should not be needed. Older hosts | |
2670 | @value{GDBN} still use the host-specific definitions and files listed | |
2671 | below, but these mostly exist for historical reasons, and will | |
56caf160 | 2672 | eventually disappear. |
c906108c | 2673 | |
c906108c | 2674 | @table @file |
c906108c | 2675 | @item gdb/config/@var{arch}/@var{xyz}.mh |
1f70da6a SS |
2676 | This file is a Makefile fragment that once contained both host and |
2677 | native configuration information (@pxref{Native Debugging}) for the | |
2678 | machine @var{xyz}. The host configuration information is now handled | |
2679 | by Autoconf. | |
7fd60527 | 2680 | |
1f70da6a | 2681 | Host configuration information included definitions for @code{CC}, |
7708fa01 AC |
2682 | @code{SYSV_DEFINE}, @code{XM_CFLAGS}, @code{XM_ADD_FILES}, |
2683 | @code{XM_CLIBS}, @code{XM_CDEPS}, etc.; see @file{Makefile.in}. | |
c906108c | 2684 | |
1f70da6a | 2685 | New host-only configurations do not need this file. |
c906108c | 2686 | |
c906108c SS |
2687 | @end table |
2688 | ||
1f70da6a SS |
2689 | (Files named @file{gdb/config/@var{arch}/xm-@var{xyz}.h} were once |
2690 | used to define host-specific macros, but were no longer needed and | |
2691 | have all been removed.) | |
2692 | ||
c906108c SS |
2693 | @subheading Generic Host Support Files |
2694 | ||
56caf160 | 2695 | @cindex generic host support |
c906108c | 2696 | There are some ``generic'' versions of routines that can be used by |
1f70da6a | 2697 | various systems. |
c906108c SS |
2698 | |
2699 | @table @file | |
56caf160 EZ |
2700 | @cindex remote debugging support |
2701 | @cindex serial line support | |
c906108c | 2702 | @item ser-unix.c |
1f70da6a SS |
2703 | This contains serial line support for Unix systems. It is included by |
2704 | default on all Unix-like hosts. | |
2705 | ||
2706 | @item ser-pipe.c | |
2707 | This contains serial pipe support for Unix systems. It is included by | |
2708 | default on all Unix-like hosts. | |
2709 | ||
2710 | @item ser-mingw.c | |
2711 | This contains serial line support for 32-bit programs running under | |
2712 | Windows using MinGW. | |
c906108c SS |
2713 | |
2714 | @item ser-go32.c | |
2715 | This contains serial line support for 32-bit programs running under DOS, | |
56caf160 | 2716 | using the DJGPP (a.k.a.@: GO32) execution environment. |
c906108c | 2717 | |
56caf160 | 2718 | @cindex TCP remote support |
c906108c | 2719 | @item ser-tcp.c |
1f70da6a SS |
2720 | This contains generic TCP support using sockets. It is included by |
2721 | default on all Unix-like hosts and with MinGW. | |
c906108c SS |
2722 | @end table |
2723 | ||
2724 | @section Host Conditionals | |
2725 | ||
56caf160 EZ |
2726 | When @value{GDBN} is configured and compiled, various macros are |
2727 | defined or left undefined, to control compilation based on the | |
1f70da6a SS |
2728 | attributes of the host system. While formerly they could be set in |
2729 | host-specific header files, at present they can be changed only by | |
2730 | setting @code{CFLAGS} when building, or by editing the source code. | |
2731 | ||
2732 | These macros and their meanings (or if the meaning is not documented | |
2733 | here, then one of the source files where they are used is indicated) | |
2734 | are: | |
c906108c | 2735 | |
56caf160 | 2736 | @ftable @code |
25822942 | 2737 | @item @value{GDBN}INIT_FILENAME |
56caf160 EZ |
2738 | The default name of @value{GDBN}'s initialization file (normally |
2739 | @file{.gdbinit}). | |
c906108c | 2740 | |
c906108c | 2741 | @item CRLF_SOURCE_FILES |
56caf160 | 2742 | @cindex DOS text files |
c906108c SS |
2743 | Define this if host files use @code{\r\n} rather than @code{\n} as a |
2744 | line terminator. This will cause source file listings to omit @code{\r} | |
56caf160 EZ |
2745 | characters when printing and it will allow @code{\r\n} line endings of files |
2746 | which are ``sourced'' by gdb. It must be possible to open files in binary | |
c906108c SS |
2747 | mode using @code{O_BINARY} or, for fopen, @code{"rb"}. |
2748 | ||
2749 | @item DEFAULT_PROMPT | |
56caf160 | 2750 | @cindex prompt |
c906108c SS |
2751 | The default value of the prompt string (normally @code{"(gdb) "}). |
2752 | ||
2753 | @item DEV_TTY | |
56caf160 | 2754 | @cindex terminal device |
c906108c SS |
2755 | The name of the generic TTY device, defaults to @code{"/dev/tty"}. |
2756 | ||
c906108c SS |
2757 | @item ISATTY |
2758 | Substitute for isatty, if not available. | |
2759 | ||
1f70da6a SS |
2760 | @item FOPEN_RB |
2761 | Define this if binary files are opened the same way as text files. | |
c906108c | 2762 | |
c906108c SS |
2763 | @item PRINTF_HAS_LONG_LONG |
2764 | Define this if the host can handle printing of long long integers via | |
56caf160 EZ |
2765 | the printf format conversion specifier @code{ll}. This is set by the |
2766 | @code{configure} script. | |
c906108c | 2767 | |
c906108c SS |
2768 | @item LSEEK_NOT_LINEAR |
2769 | Define this if @code{lseek (n)} does not necessarily move to byte number | |
2770 | @code{n} in the file. This is only used when reading source files. It | |
2771 | is normally faster to define @code{CRLF_SOURCE_FILES} when possible. | |
2772 | ||
c906108c | 2773 | @item lint |
56caf160 | 2774 | Define this to help placate @code{lint} in some situations. |
c906108c SS |
2775 | |
2776 | @item volatile | |
2777 | Define this to override the defaults of @code{__volatile__} or | |
2778 | @code{/**/}. | |
56caf160 | 2779 | @end ftable |
c906108c SS |
2780 | |
2781 | ||
2782 | @node Target Architecture Definition | |
2783 | ||
2784 | @chapter Target Architecture Definition | |
2785 | ||
56caf160 EZ |
2786 | @cindex target architecture definition |
2787 | @value{GDBN}'s target architecture defines what sort of | |
2788 | machine-language programs @value{GDBN} can work with, and how it works | |
2789 | with them. | |
c906108c | 2790 | |
af6c57ea AC |
2791 | The target architecture object is implemented as the C structure |
2792 | @code{struct gdbarch *}. The structure, and its methods, are generated | |
93c2c750 | 2793 | using the Bourne shell script @file{gdbarch.sh}. |
c906108c | 2794 | |
b6fd0dfb NR |
2795 | @menu |
2796 | * OS ABI Variant Handling:: | |
2797 | * Initialize New Architecture:: | |
2798 | * Registers and Memory:: | |
2799 | * Pointers and Addresses:: | |
2800 | * Address Classes:: | |
587afa38 | 2801 | * Register Representation:: |
b6fd0dfb NR |
2802 | * Frame Interpretation:: |
2803 | * Inferior Call Setup:: | |
b39f4988 | 2804 | * Adding support for debugging core files:: |
587afa38 | 2805 | * Defining Other Architecture Features:: |
b6fd0dfb | 2806 | * Adding a New Target:: |
b6fd0dfb NR |
2807 | @end menu |
2808 | ||
2809 | @node OS ABI Variant Handling | |
70f80edf JT |
2810 | @section Operating System ABI Variant Handling |
2811 | @cindex OS ABI variants | |
2812 | ||
2813 | @value{GDBN} provides a mechanism for handling variations in OS | |
2814 | ABIs. An OS ABI variant may have influence over any number of | |
2815 | variables in the target architecture definition. There are two major | |
2816 | components in the OS ABI mechanism: sniffers and handlers. | |
2817 | ||
2818 | A @dfn{sniffer} examines a file matching a BFD architecture/flavour pair | |
2819 | (the architecture may be wildcarded) in an attempt to determine the | |
2820 | OS ABI of that file. Sniffers with a wildcarded architecture are considered | |
2821 | to be @dfn{generic}, while sniffers for a specific architecture are | |
2822 | considered to be @dfn{specific}. A match from a specific sniffer | |
2823 | overrides a match from a generic sniffer. Multiple sniffers for an | |
2824 | architecture/flavour may exist, in order to differentiate between two | |
2825 | different operating systems which use the same basic file format. The | |
2826 | OS ABI framework provides a generic sniffer for ELF-format files which | |
2827 | examines the @code{EI_OSABI} field of the ELF header, as well as note | |
2828 | sections known to be used by several operating systems. | |
2829 | ||
2830 | @cindex fine-tuning @code{gdbarch} structure | |
2831 | A @dfn{handler} is used to fine-tune the @code{gdbarch} structure for the | |
2832 | selected OS ABI. There may be only one handler for a given OS ABI | |
2833 | for each BFD architecture. | |
2834 | ||
f4b3909f | 2835 | The following OS ABI variants are defined in @file{defs.h}: |
70f80edf JT |
2836 | |
2837 | @table @code | |
2838 | ||
f4b3909f EZ |
2839 | @findex GDB_OSABI_UNINITIALIZED |
2840 | @item GDB_OSABI_UNINITIALIZED | |
2841 | Used for struct gdbarch_info if ABI is still uninitialized. | |
2842 | ||
70f80edf JT |
2843 | @findex GDB_OSABI_UNKNOWN |
2844 | @item GDB_OSABI_UNKNOWN | |
2845 | The ABI of the inferior is unknown. The default @code{gdbarch} | |
2846 | settings for the architecture will be used. | |
2847 | ||
2848 | @findex GDB_OSABI_SVR4 | |
2849 | @item GDB_OSABI_SVR4 | |
f4b3909f | 2850 | UNIX System V Release 4. |
70f80edf JT |
2851 | |
2852 | @findex GDB_OSABI_HURD | |
2853 | @item GDB_OSABI_HURD | |
f4b3909f | 2854 | GNU using the Hurd kernel. |
70f80edf JT |
2855 | |
2856 | @findex GDB_OSABI_SOLARIS | |
2857 | @item GDB_OSABI_SOLARIS | |
f4b3909f | 2858 | Sun Solaris. |
70f80edf JT |
2859 | |
2860 | @findex GDB_OSABI_OSF1 | |
2861 | @item GDB_OSABI_OSF1 | |
f4b3909f | 2862 | OSF/1, including Digital UNIX and Compaq Tru64 UNIX. |
70f80edf JT |
2863 | |
2864 | @findex GDB_OSABI_LINUX | |
2865 | @item GDB_OSABI_LINUX | |
f4b3909f | 2866 | GNU using the Linux kernel. |
70f80edf JT |
2867 | |
2868 | @findex GDB_OSABI_FREEBSD_AOUT | |
2869 | @item GDB_OSABI_FREEBSD_AOUT | |
f4b3909f | 2870 | FreeBSD using the @code{a.out} executable format. |
70f80edf JT |
2871 | |
2872 | @findex GDB_OSABI_FREEBSD_ELF | |
2873 | @item GDB_OSABI_FREEBSD_ELF | |
f4b3909f | 2874 | FreeBSD using the ELF executable format. |
70f80edf JT |
2875 | |
2876 | @findex GDB_OSABI_NETBSD_AOUT | |
2877 | @item GDB_OSABI_NETBSD_AOUT | |
f4b3909f | 2878 | NetBSD using the @code{a.out} executable format. |
70f80edf JT |
2879 | |
2880 | @findex GDB_OSABI_NETBSD_ELF | |
2881 | @item GDB_OSABI_NETBSD_ELF | |
f4b3909f EZ |
2882 | NetBSD using the ELF executable format. |
2883 | ||
2884 | @findex GDB_OSABI_OPENBSD_ELF | |
2885 | @item GDB_OSABI_OPENBSD_ELF | |
2886 | OpenBSD using the ELF executable format. | |
70f80edf JT |
2887 | |
2888 | @findex GDB_OSABI_WINCE | |
2889 | @item GDB_OSABI_WINCE | |
f4b3909f | 2890 | Windows CE. |
70f80edf | 2891 | |
1029b7fa MK |
2892 | @findex GDB_OSABI_GO32 |
2893 | @item GDB_OSABI_GO32 | |
f4b3909f | 2894 | DJGPP. |
1029b7fa | 2895 | |
f4b3909f EZ |
2896 | @findex GDB_OSABI_IRIX |
2897 | @item GDB_OSABI_IRIX | |
2898 | Irix. | |
2899 | ||
f4b3909f EZ |
2900 | @findex GDB_OSABI_INTERIX |
2901 | @item GDB_OSABI_INTERIX | |
2902 | Interix (Posix layer for MS-Windows systems). | |
1029b7fa | 2903 | |
f4b3909f EZ |
2904 | @findex GDB_OSABI_HPUX_ELF |
2905 | @item GDB_OSABI_HPUX_ELF | |
2906 | HP/UX using the ELF executable format. | |
70f80edf | 2907 | |
f4b3909f EZ |
2908 | @findex GDB_OSABI_HPUX_SOM |
2909 | @item GDB_OSABI_HPUX_SOM | |
2910 | HP/UX using the SOM executable format. | |
70f80edf | 2911 | |
f4b3909f EZ |
2912 | @findex GDB_OSABI_QNXNTO |
2913 | @item GDB_OSABI_QNXNTO | |
2914 | QNX Neutrino. | |
2915 | ||
2916 | @findex GDB_OSABI_CYGWIN | |
2917 | @item GDB_OSABI_CYGWIN | |
2918 | Cygwin. | |
2919 | ||
2920 | @findex GDB_OSABI_AIX | |
2921 | @item GDB_OSABI_AIX | |
2922 | AIX. | |
70f80edf JT |
2923 | |
2924 | @end table | |
2925 | ||
2926 | Here are the functions that make up the OS ABI framework: | |
2927 | ||
587afa38 | 2928 | @deftypefun {const char *} gdbarch_osabi_name (enum gdb_osabi @var{osabi}) |
70f80edf JT |
2929 | Return the name of the OS ABI corresponding to @var{osabi}. |
2930 | @end deftypefun | |
2931 | ||
c133ab7a | 2932 | @deftypefun void gdbarch_register_osabi (enum bfd_architecture @var{arch}, unsigned long @var{machine}, enum gdb_osabi @var{osabi}, void (*@var{init_osabi})(struct gdbarch_info @var{info}, struct gdbarch *@var{gdbarch})) |
70f80edf | 2933 | Register the OS ABI handler specified by @var{init_osabi} for the |
c133ab7a MK |
2934 | architecture, machine type and OS ABI specified by @var{arch}, |
2935 | @var{machine} and @var{osabi}. In most cases, a value of zero for the | |
2936 | machine type, which implies the architecture's default machine type, | |
2937 | will suffice. | |
70f80edf JT |
2938 | @end deftypefun |
2939 | ||
2940 | @deftypefun void gdbarch_register_osabi_sniffer (enum bfd_architecture @var{arch}, enum bfd_flavour @var{flavour}, enum gdb_osabi (*@var{sniffer})(bfd *@var{abfd})) | |
2941 | Register the OS ABI file sniffer specified by @var{sniffer} for the | |
2942 | BFD architecture/flavour pair specified by @var{arch} and @var{flavour}. | |
2943 | If @var{arch} is @code{bfd_arch_unknown}, the sniffer is considered to | |
2944 | be generic, and is allowed to examine @var{flavour}-flavoured files for | |
2945 | any architecture. | |
2946 | @end deftypefun | |
2947 | ||
587afa38 | 2948 | @deftypefun {enum gdb_osabi} gdbarch_lookup_osabi (bfd *@var{abfd}) |
70f80edf JT |
2949 | Examine the file described by @var{abfd} to determine its OS ABI. |
2950 | The value @code{GDB_OSABI_UNKNOWN} is returned if the OS ABI cannot | |
2951 | be determined. | |
2952 | @end deftypefun | |
2953 | ||
2954 | @deftypefun void gdbarch_init_osabi (struct gdbarch info @var{info}, struct gdbarch *@var{gdbarch}, enum gdb_osabi @var{osabi}) | |
2955 | Invoke the OS ABI handler corresponding to @var{osabi} to fine-tune the | |
2956 | @code{gdbarch} structure specified by @var{gdbarch}. If a handler | |
2957 | corresponding to @var{osabi} has not been registered for @var{gdbarch}'s | |
2958 | architecture, a warning will be issued and the debugging session will continue | |
2959 | with the defaults already established for @var{gdbarch}. | |
2960 | @end deftypefun | |
2961 | ||
f4b3909f EZ |
2962 | @deftypefun void generic_elf_osabi_sniff_abi_tag_sections (bfd *@var{abfd}, asection *@var{sect}, void *@var{obj}) |
2963 | Helper routine for ELF file sniffers. Examine the file described by | |
2964 | @var{abfd} and look at ABI tag note sections to determine the OS ABI | |
2965 | from the note. This function should be called via | |
2966 | @code{bfd_map_over_sections}. | |
2967 | @end deftypefun | |
2968 | ||
b6fd0dfb | 2969 | @node Initialize New Architecture |
7a107747 DJ |
2970 | @section Initializing a New Architecture |
2971 | ||
587afa38 EZ |
2972 | @menu |
2973 | * How an Architecture is Represented:: | |
2974 | * Looking Up an Existing Architecture:: | |
2975 | * Creating a New Architecture:: | |
2976 | @end menu | |
2977 | ||
2978 | @node How an Architecture is Represented | |
2979 | @subsection How an Architecture is Represented | |
2980 | @cindex architecture representation | |
2981 | @cindex representation of architecture | |
2982 | ||
7a107747 | 2983 | Each @code{gdbarch} is associated with a single @sc{bfd} architecture, |
587afa38 EZ |
2984 | via a @code{bfd_arch_@var{arch}} in the @code{bfd_architecture} |
2985 | enumeration. The @code{gdbarch} is registered by a call to | |
2986 | @code{register_gdbarch_init}, usually from the file's | |
2987 | @code{_initialize_@var{filename}} routine, which will be automatically | |
2988 | called during @value{GDBN} startup. The arguments are a @sc{bfd} | |
2989 | architecture constant and an initialization function. | |
2990 | ||
2991 | @findex _initialize_@var{arch}_tdep | |
2992 | @cindex @file{@var{arch}-tdep.c} | |
2993 | A @value{GDBN} description for a new architecture, @var{arch} is created by | |
2994 | defining a global function @code{_initialize_@var{arch}_tdep}, by | |
2995 | convention in the source file @file{@var{arch}-tdep.c}. For example, | |
2996 | in the case of the OpenRISC 1000, this function is called | |
2997 | @code{_initialize_or1k_tdep} and is found in the file | |
2998 | @file{or1k-tdep.c}. | |
2999 | ||
3000 | @cindex @file{configure.tgt} | |
3001 | @cindex @code{gdbarch} | |
3002 | @findex gdbarch_register | |
3003 | The resulting object files containing the implementation of the | |
3004 | @code{_initialize_@var{arch}_tdep} function are specified in the @value{GDBN} | |
3005 | @file{configure.tgt} file, which includes a large case statement | |
3006 | pattern matching against the @code{--target} option of the | |
3007 | @code{configure} script. The new @code{struct gdbarch} is created | |
3008 | within the @code{_initialize_@var{arch}_tdep} function by calling | |
3009 | @code{gdbarch_register}: | |
3010 | ||
3011 | @smallexample | |
3012 | void gdbarch_register (enum bfd_architecture @var{architecture}, | |
3013 | gdbarch_init_ftype *@var{init_func}, | |
3014 | gdbarch_dump_tdep_ftype *@var{tdep_dump_func}); | |
3015 | @end smallexample | |
3016 | ||
3017 | The @var{architecture} will identify the unique @sc{bfd} to be | |
3018 | associated with this @code{gdbarch}. The @var{init_func} funciton is | |
3019 | called to create and return the new @code{struct gdbarch}. The | |
3020 | @var{tdep_dump_func} function will dump the target specific details | |
3021 | associated with this architecture. | |
3022 | ||
3023 | For example the function @code{_initialize_or1k_tdep} creates its | |
3024 | architecture for 32-bit OpenRISC 1000 architectures by calling: | |
3025 | ||
3026 | @smallexample | |
3027 | gdbarch_register (bfd_arch_or32, or1k_gdbarch_init, or1k_dump_tdep); | |
3028 | @end smallexample | |
3029 | ||
3030 | @node Looking Up an Existing Architecture | |
3031 | @subsection Looking Up an Existing Architecture | |
3032 | @cindex @code{gdbarch} lookup | |
7a107747 | 3033 | |
587afa38 | 3034 | The initialization function has this prototype: |
7a107747 DJ |
3035 | |
3036 | @smallexample | |
3037 | static struct gdbarch * | |
3038 | @var{arch}_gdbarch_init (struct gdbarch_info @var{info}, | |
3039 | struct gdbarch_list *@var{arches}) | |
3040 | @end smallexample | |
3041 | ||
3042 | The @var{info} argument contains parameters used to select the correct | |
3043 | architecture, and @var{arches} is a list of architectures which | |
3044 | have already been created with the same @code{bfd_arch_@var{arch}} | |
3045 | value. | |
3046 | ||
3047 | The initialization function should first make sure that @var{info} | |
3048 | is acceptable, and return @code{NULL} if it is not. Then, it should | |
3049 | search through @var{arches} for an exact match to @var{info}, and | |
3050 | return one if found. Lastly, if no exact match was found, it should | |
3051 | create a new architecture based on @var{info} and return it. | |
3052 | ||
587afa38 EZ |
3053 | @findex gdbarch_list_lookup_by_info |
3054 | @cindex @code{gdbarch_info} | |
3055 | The lookup is done using @code{gdbarch_list_lookup_by_info}. It is | |
3056 | passed the list of existing architectures, @var{arches}, and the | |
3057 | @code{struct gdbarch_info}, @var{info}, and returns the first matching | |
3058 | architecture it finds, or @code{NULL} if none are found. If an | |
3059 | architecture is found it can be returned as the result from the | |
3060 | initialization function, otherwise a new @code{struct gdbach} will need | |
3061 | to be created. | |
3062 | ||
3063 | The struct gdbarch_info has the following components: | |
3064 | ||
3065 | @smallexample | |
3066 | struct gdbarch_info | |
3067 | @{ | |
3068 | const struct bfd_arch_info *bfd_arch_info; | |
3069 | int byte_order; | |
3070 | bfd *abfd; | |
3071 | struct gdbarch_tdep_info *tdep_info; | |
3072 | enum gdb_osabi osabi; | |
3073 | const struct target_desc *target_desc; | |
3074 | @}; | |
3075 | @end smallexample | |
3076 | ||
3077 | @vindex bfd_arch_info | |
3078 | The @code{bfd_arch_info} member holds the key details about the | |
3079 | architecture. The @code{byte_order} member is a value in an | |
3080 | enumeration indicating the endianism. The @code{abfd} member is a | |
3081 | pointer to the full @sc{bfd}, the @code{tdep_info} member is | |
3082 | additional custom target specific information, @code{osabi} identifies | |
3083 | which (if any) of a number of operating specific ABIs are used by this | |
3084 | architecture and the @code{target_desc} member is a set of name-value | |
3085 | pairs with information about register usage in this target. | |
3086 | ||
3087 | When the @code{struct gdbarch} initialization function is called, not | |
3088 | all the fields are provided---only those which can be deduced from the | |
3089 | @sc{bfd}. The @code{struct gdbarch_info}, @var{info} is used as a | |
3090 | look-up key with the list of existing architectures, @var{arches} to | |
3091 | see if a suitable architecture already exists. The @var{tdep_info}, | |
3092 | @var{osabi} and @var{target_desc} fields may be added before this | |
3093 | lookup to refine the search. | |
3094 | ||
7a107747 DJ |
3095 | Only information in @var{info} should be used to choose the new |
3096 | architecture. Historically, @var{info} could be sparse, and | |
3097 | defaults would be collected from the first element on @var{arches}. | |
3098 | However, @value{GDBN} now fills in @var{info} more thoroughly, | |
3099 | so new @code{gdbarch} initialization functions should not take | |
3100 | defaults from @var{arches}. | |
3101 | ||
587afa38 EZ |
3102 | @node Creating a New Architecture |
3103 | @subsection Creating a New Architecture | |
3104 | @cindex @code{struct gdbarch} creation | |
3105 | ||
3106 | @findex gdbarch_alloc | |
3107 | @cindex @code{gdbarch_tdep} when allocating new @code{gdbarch} | |
3108 | If no architecture is found, then a new architecture must be created, | |
3109 | by calling @code{gdbarch_alloc} using the supplied @code{@w{struct | |
3110 | gdbarch_info}} and any additional custom target specific | |
3111 | information in a @code{struct gdbarch_tdep}. The prototype for | |
3112 | @code{gdbarch_alloc} is: | |
3113 | ||
3114 | @smallexample | |
3115 | struct gdbarch *gdbarch_alloc (const struct gdbarch_info *@var{info}, | |
3116 | struct gdbarch_tdep *@var{tdep}); | |
3117 | @end smallexample | |
3118 | ||
3119 | @cindex @code{set_gdbarch} functions | |
3120 | @cindex @code{gdbarch} accessor functions | |
3121 | The newly created struct gdbarch must then be populated. Although | |
3122 | there are default values, in most cases they are not what is | |
3123 | required. | |
3124 | ||
3125 | For each element, @var{X}, there is are a pair of corresponding accessor | |
3126 | functions, one to set the value of that element, | |
3127 | @code{set_gdbarch_@var{X}}, the second to either get the value of an | |
3128 | element (if it is a variable) or to apply the element (if it is a | |
3129 | function), @code{gdbarch_@var{X}}. Note that both accessor functions | |
3130 | take a pointer to the @code{@w{struct gdbarch}} as first | |
3131 | argument. Populating the new @code{gdbarch} should use the | |
3132 | @code{set_gdbarch} functions. | |
3133 | ||
3134 | The following sections identify the main elements that should be set | |
3135 | in this way. This is not the complete list, but represents the | |
3136 | functions and elements that must commonly be specified for a new | |
3137 | architecture. Many of the functions and variables are described in the | |
3138 | header file @file{gdbarch.h}. | |
3139 | ||
3140 | This is the main work in defining a new architecture. Implementing the | |
3141 | set of functions to populate the @code{struct gdbarch}. | |
3142 | ||
3143 | @cindex @code{gdbarch_tdep} definition | |
3144 | @code{struct gdbarch_tdep} is not defined within @value{GDBN}---it is up | |
3145 | to the user to define this struct if it is needed to hold custom target | |
3146 | information that is not covered by the standard @code{@w{struct | |
3147 | gdbarch}}. For example with the OpenRISC 1000 architecture it is used to | |
3148 | hold the number of matchpoints available in the target (along with other | |
3149 | information). | |
3150 | ||
3151 | If there is no additional target specific information, it can be set to | |
3152 | @code{NULL}. | |
3153 | ||
b6fd0dfb | 3154 | @node Registers and Memory |
c906108c SS |
3155 | @section Registers and Memory |
3156 | ||
56caf160 EZ |
3157 | @value{GDBN}'s model of the target machine is rather simple. |
3158 | @value{GDBN} assumes the machine includes a bank of registers and a | |
3159 | block of memory. Each register may have a different size. | |
c906108c | 3160 | |
56caf160 EZ |
3161 | @value{GDBN} does not have a magical way to match up with the |
3162 | compiler's idea of which registers are which; however, it is critical | |
3163 | that they do match up accurately. The only way to make this work is | |
3164 | to get accurate information about the order that the compiler uses, | |
4a9bb1df | 3165 | and to reflect that in the @code{gdbarch_register_name} and related functions. |
c906108c | 3166 | |
25822942 | 3167 | @value{GDBN} can handle big-endian, little-endian, and bi-endian architectures. |
c906108c | 3168 | |
b6fd0dfb | 3169 | @node Pointers and Addresses |
93e79dbd JB |
3170 | @section Pointers Are Not Always Addresses |
3171 | @cindex pointer representation | |
3172 | @cindex address representation | |
3173 | @cindex word-addressed machines | |
3174 | @cindex separate data and code address spaces | |
3175 | @cindex spaces, separate data and code address | |
3176 | @cindex address spaces, separate data and code | |
3177 | @cindex code pointers, word-addressed | |
3178 | @cindex converting between pointers and addresses | |
3179 | @cindex D10V addresses | |
3180 | ||
3181 | On almost all 32-bit architectures, the representation of a pointer is | |
3182 | indistinguishable from the representation of some fixed-length number | |
3183 | whose value is the byte address of the object pointed to. On such | |
56caf160 | 3184 | machines, the words ``pointer'' and ``address'' can be used interchangeably. |
93e79dbd JB |
3185 | However, architectures with smaller word sizes are often cramped for |
3186 | address space, so they may choose a pointer representation that breaks this | |
3187 | identity, and allows a larger code address space. | |
3188 | ||
1f70da6a SS |
3189 | @c D10V is gone from sources - more current example? |
3190 | ||
172c2a43 | 3191 | For example, the Renesas D10V is a 16-bit VLIW processor whose |
93e79dbd JB |
3192 | instructions are 32 bits long@footnote{Some D10V instructions are |
3193 | actually pairs of 16-bit sub-instructions. However, since you can't | |
3194 | jump into the middle of such a pair, code addresses can only refer to | |
3195 | full 32 bit instructions, which is what matters in this explanation.}. | |
3196 | If the D10V used ordinary byte addresses to refer to code locations, | |
3197 | then the processor would only be able to address 64kb of instructions. | |
3198 | However, since instructions must be aligned on four-byte boundaries, the | |
56caf160 EZ |
3199 | low two bits of any valid instruction's byte address are always |
3200 | zero---byte addresses waste two bits. So instead of byte addresses, | |
3201 | the D10V uses word addresses---byte addresses shifted right two bits---to | |
93e79dbd JB |
3202 | refer to code. Thus, the D10V can use 16-bit words to address 256kb of |
3203 | code space. | |
3204 | ||
3205 | However, this means that code pointers and data pointers have different | |
3206 | forms on the D10V. The 16-bit word @code{0xC020} refers to byte address | |
3207 | @code{0xC020} when used as a data address, but refers to byte address | |
3208 | @code{0x30080} when used as a code address. | |
3209 | ||
3210 | (The D10V also uses separate code and data address spaces, which also | |
3211 | affects the correspondence between pointers and addresses, but we're | |
3212 | going to ignore that here; this example is already too long.) | |
3213 | ||
56caf160 EZ |
3214 | To cope with architectures like this---the D10V is not the only |
3215 | one!---@value{GDBN} tries to distinguish between @dfn{addresses}, which are | |
93e79dbd JB |
3216 | byte numbers, and @dfn{pointers}, which are the target's representation |
3217 | of an address of a particular type of data. In the example above, | |
3218 | @code{0xC020} is the pointer, which refers to one of the addresses | |
3219 | @code{0xC020} or @code{0x30080}, depending on the type imposed upon it. | |
3220 | @value{GDBN} provides functions for turning a pointer into an address | |
3221 | and vice versa, in the appropriate way for the current architecture. | |
3222 | ||
3223 | Unfortunately, since addresses and pointers are identical on almost all | |
3224 | processors, this distinction tends to bit-rot pretty quickly. Thus, | |
3225 | each time you port @value{GDBN} to an architecture which does | |
3226 | distinguish between pointers and addresses, you'll probably need to | |
3227 | clean up some architecture-independent code. | |
3228 | ||
3229 | Here are functions which convert between pointers and addresses: | |
3230 | ||
3231 | @deftypefun CORE_ADDR extract_typed_address (void *@var{buf}, struct type *@var{type}) | |
3232 | Treat the bytes at @var{buf} as a pointer or reference of type | |
3233 | @var{type}, and return the address it represents, in a manner | |
3234 | appropriate for the current architecture. This yields an address | |
3235 | @value{GDBN} can use to read target memory, disassemble, etc. Note that | |
3236 | @var{buf} refers to a buffer in @value{GDBN}'s memory, not the | |
3237 | inferior's. | |
3238 | ||
3239 | For example, if the current architecture is the Intel x86, this function | |
3240 | extracts a little-endian integer of the appropriate length from | |
3241 | @var{buf} and returns it. However, if the current architecture is the | |
3242 | D10V, this function will return a 16-bit integer extracted from | |
3243 | @var{buf}, multiplied by four if @var{type} is a pointer to a function. | |
3244 | ||
3245 | If @var{type} is not a pointer or reference type, then this function | |
3246 | will signal an internal error. | |
3247 | @end deftypefun | |
3248 | ||
3249 | @deftypefun CORE_ADDR store_typed_address (void *@var{buf}, struct type *@var{type}, CORE_ADDR @var{addr}) | |
3250 | Store the address @var{addr} in @var{buf}, in the proper format for a | |
3251 | pointer of type @var{type} in the current architecture. Note that | |
3252 | @var{buf} refers to a buffer in @value{GDBN}'s memory, not the | |
3253 | inferior's. | |
3254 | ||
3255 | For example, if the current architecture is the Intel x86, this function | |
3256 | stores @var{addr} unmodified as a little-endian integer of the | |
3257 | appropriate length in @var{buf}. However, if the current architecture | |
3258 | is the D10V, this function divides @var{addr} by four if @var{type} is | |
3259 | a pointer to a function, and then stores it in @var{buf}. | |
3260 | ||
3261 | If @var{type} is not a pointer or reference type, then this function | |
3262 | will signal an internal error. | |
3263 | @end deftypefun | |
3264 | ||
f23631e4 | 3265 | @deftypefun CORE_ADDR value_as_address (struct value *@var{val}) |
93e79dbd JB |
3266 | Assuming that @var{val} is a pointer, return the address it represents, |
3267 | as appropriate for the current architecture. | |
3268 | ||
3269 | This function actually works on integral values, as well as pointers. | |
3270 | For pointers, it performs architecture-specific conversions as | |
3271 | described above for @code{extract_typed_address}. | |
3272 | @end deftypefun | |
3273 | ||
3274 | @deftypefun CORE_ADDR value_from_pointer (struct type *@var{type}, CORE_ADDR @var{addr}) | |
3275 | Create and return a value representing a pointer of type @var{type} to | |
3276 | the address @var{addr}, as appropriate for the current architecture. | |
3277 | This function performs architecture-specific conversions as described | |
3278 | above for @code{store_typed_address}. | |
3279 | @end deftypefun | |
3280 | ||
4a9bb1df | 3281 | Here are two functions which architectures can define to indicate the |
93e79dbd JB |
3282 | relationship between pointers and addresses. These have default |
3283 | definitions, appropriate for architectures on which all pointers are | |
fc0c74b1 | 3284 | simple unsigned byte addresses. |
93e79dbd | 3285 | |
473f94e6 | 3286 | @deftypefun CORE_ADDR gdbarch_pointer_to_address (struct gdbarch *@var{gdbarch}, struct type *@var{type}, char *@var{buf}) |
93e79dbd JB |
3287 | Assume that @var{buf} holds a pointer of type @var{type}, in the |
3288 | appropriate format for the current architecture. Return the byte | |
3289 | address the pointer refers to. | |
3290 | ||
3291 | This function may safely assume that @var{type} is either a pointer or a | |
56caf160 | 3292 | C@t{++} reference type. |
4a9bb1df | 3293 | @end deftypefun |
93e79dbd | 3294 | |
473f94e6 | 3295 | @deftypefun void gdbarch_address_to_pointer (struct gdbarch *@var{gdbarch}, struct type *@var{type}, char *@var{buf}, CORE_ADDR @var{addr}) |
93e79dbd JB |
3296 | Store in @var{buf} a pointer of type @var{type} representing the address |
3297 | @var{addr}, in the appropriate format for the current architecture. | |
3298 | ||
3299 | This function may safely assume that @var{type} is either a pointer or a | |
56caf160 | 3300 | C@t{++} reference type. |
4a9bb1df | 3301 | @end deftypefun |
93e79dbd | 3302 | |
b6fd0dfb | 3303 | @node Address Classes |
b5b0480a KB |
3304 | @section Address Classes |
3305 | @cindex address classes | |
3306 | @cindex DW_AT_byte_size | |
3307 | @cindex DW_AT_address_class | |
3308 | ||
3309 | Sometimes information about different kinds of addresses is available | |
3310 | via the debug information. For example, some programming environments | |
3311 | define addresses of several different sizes. If the debug information | |
3312 | distinguishes these kinds of address classes through either the size | |
3313 | info (e.g, @code{DW_AT_byte_size} in @w{DWARF 2}) or through an explicit | |
3314 | address class attribute (e.g, @code{DW_AT_address_class} in @w{DWARF 2}), the | |
3315 | following macros should be defined in order to disambiguate these | |
3316 | types within @value{GDBN} as well as provide the added information to | |
3317 | a @value{GDBN} user when printing type expressions. | |
3318 | ||
473f94e6 | 3319 | @deftypefun int gdbarch_address_class_type_flags (struct gdbarch *@var{gdbarch}, int @var{byte_size}, int @var{dwarf2_addr_class}) |
b5b0480a KB |
3320 | Returns the type flags needed to construct a pointer type whose size |
3321 | is @var{byte_size} and whose address class is @var{dwarf2_addr_class}. | |
3322 | This function is normally called from within a symbol reader. See | |
3323 | @file{dwarf2read.c}. | |
4a9bb1df | 3324 | @end deftypefun |
b5b0480a | 3325 | |
473f94e6 | 3326 | @deftypefun {char *} gdbarch_address_class_type_flags_to_name (struct gdbarch *@var{gdbarch}, int @var{type_flags}) |
b5b0480a KB |
3327 | Given the type flags representing an address class qualifier, return |
3328 | its name. | |
4a9bb1df | 3329 | @end deftypefun |
473f94e6 | 3330 | @deftypefun int gdbarch_address_class_name_to_type_flags (struct gdbarch *@var{gdbarch}, int @var{name}, int *@var{type_flags_ptr}) |
d3e8051b | 3331 | Given an address qualifier name, set the @code{int} referenced by @var{type_flags_ptr} to the type flags |
b5b0480a | 3332 | for that address class qualifier. |
4a9bb1df | 3333 | @end deftypefun |
b5b0480a KB |
3334 | |
3335 | Since the need for address classes is rather rare, none of | |
4a9bb1df UW |
3336 | the address class functions are defined by default. Predicate |
3337 | functions are provided to detect when they are defined. | |
b5b0480a KB |
3338 | |
3339 | Consider a hypothetical architecture in which addresses are normally | |
3340 | 32-bits wide, but 16-bit addresses are also supported. Furthermore, | |
3341 | suppose that the @w{DWARF 2} information for this architecture simply | |
3342 | uses a @code{DW_AT_byte_size} value of 2 to indicate the use of one | |
3343 | of these "short" pointers. The following functions could be defined | |
4a9bb1df | 3344 | to implement the address class functions: |
b5b0480a KB |
3345 | |
3346 | @smallexample | |
3347 | somearch_address_class_type_flags (int byte_size, | |
3348 | int dwarf2_addr_class) | |
f2abfe65 | 3349 | @{ |
b5b0480a KB |
3350 | if (byte_size == 2) |
3351 | return TYPE_FLAG_ADDRESS_CLASS_1; | |
3352 | else | |
3353 | return 0; | |
f2abfe65 | 3354 | @} |
b5b0480a KB |
3355 | |
3356 | static char * | |
3357 | somearch_address_class_type_flags_to_name (int type_flags) | |
f2abfe65 | 3358 | @{ |
b5b0480a KB |
3359 | if (type_flags & TYPE_FLAG_ADDRESS_CLASS_1) |
3360 | return "short"; | |
3361 | else | |
3362 | return NULL; | |
f2abfe65 | 3363 | @} |
b5b0480a KB |
3364 | |
3365 | int | |
3366 | somearch_address_class_name_to_type_flags (char *name, | |
3367 | int *type_flags_ptr) | |
f2abfe65 | 3368 | @{ |
b5b0480a | 3369 | if (strcmp (name, "short") == 0) |
f2abfe65 | 3370 | @{ |
b5b0480a KB |
3371 | *type_flags_ptr = TYPE_FLAG_ADDRESS_CLASS_1; |
3372 | return 1; | |
f2abfe65 | 3373 | @} |
b5b0480a KB |
3374 | else |
3375 | return 0; | |
f2abfe65 | 3376 | @} |
b5b0480a KB |
3377 | @end smallexample |
3378 | ||
3379 | The qualifier @code{@@short} is used in @value{GDBN}'s type expressions | |
587afa38 EZ |
3380 | to indicate the presence of one of these ``short'' pointers. For |
3381 | example if the debug information indicates that @code{short_ptr_var} is | |
3382 | one of these short pointers, @value{GDBN} might show the following | |
3383 | behavior: | |
b5b0480a KB |
3384 | |
3385 | @smallexample | |
3386 | (gdb) ptype short_ptr_var | |
3387 | type = int * @@short | |
3388 | @end smallexample | |
3389 | ||
93e79dbd | 3390 | |
587afa38 EZ |
3391 | @node Register Representation |
3392 | @section Register Representation | |
3393 | ||
3394 | @menu | |
3395 | * Raw and Cooked Registers:: | |
3396 | * Register Architecture Functions & Variables:: | |
3397 | * Register Information Functions:: | |
3398 | * Register and Memory Data:: | |
3399 | * Register Caching:: | |
3400 | @end menu | |
3401 | ||
3402 | @node Raw and Cooked Registers | |
3403 | @subsection Raw and Cooked Registers | |
13d01224 | 3404 | @cindex raw register representation |
587afa38 EZ |
3405 | @cindex cooked register representation |
3406 | @cindex representations, raw and cooked registers | |
3407 | ||
3408 | @value{GDBN} considers registers to be a set with members numbered | |
3409 | linearly from 0 upwards. The first part of that set corresponds to real | |
3410 | physical registers, the second part to any @dfn{pseudo-registers}. | |
3411 | Pseudo-registers have no independent physical existence, but are useful | |
3412 | representations of information within the architecture. For example the | |
3413 | OpenRISC 1000 architecture has up to 32 general purpose registers, which | |
3414 | are typically represented as 32-bit (or 64-bit) integers. However the | |
3415 | GPRs are also used as operands to the floating point operations, and it | |
3416 | could be convenient to define a set of pseudo-registers, to show the | |
3417 | GPRs represented as floating point values. | |
3418 | ||
3419 | For any architecture, the implementer will decide on a mapping from | |
3420 | hardware to @value{GDBN} register numbers. The registers corresponding to real | |
3421 | hardware are referred to as @dfn{raw} registers, the remaining registers are | |
3422 | @dfn{pseudo-registers}. The total register set (raw and pseudo) is called | |
3423 | the @dfn{cooked} register set. | |
3424 | ||
3425 | ||
3426 | @node Register Architecture Functions & Variables | |
3427 | @subsection Functions and Variables Specifying the Register Architecture | |
3428 | @cindex @code{gdbarch} register architecture functions | |
3429 | ||
3430 | These @code{struct gdbarch} functions and variables specify the number | |
3431 | and type of registers in the architecture. | |
3432 | ||
3433 | @deftypefn {Architecture Function} CORE_ADDR read_pc (struct regcache *@var{regcache}) | |
3434 | @end deftypefn | |
3435 | @deftypefn {Architecture Function} void write_pc (struct regcache *@var{regcache}, CORE_ADDR @var{val}) | |
13d01224 | 3436 | |
587afa38 EZ |
3437 | Read or write the program counter. The default value of both |
3438 | functions is @code{NULL} (no function available). If the program | |
3439 | counter is just an ordinary register, it can be specified in | |
3440 | @code{struct gdbarch} instead (see @code{pc_regnum} below) and it will | |
3441 | be read or written using the standard routines to access registers. This | |
3442 | function need only be specified if the program counter is not an | |
3443 | ordinary register. | |
3444 | ||
3445 | Any register information can be obtained using the supplied register | |
3446 | cache, @var{regcache}. @xref{Register Caching, , Register Caching}. | |
3447 | ||
3448 | @end deftypefn | |
3449 | ||
3450 | @deftypefn {Architecture Function} void pseudo_register_read (struct gdbarch *@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum}, const gdb_byte *@var{buf}) | |
3451 | @end deftypefn | |
3452 | @deftypefn {Architecture Function} void pseudo_register_write (struct gdbarch *@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum}, const gdb_byte *@var{buf}) | |
3453 | ||
3454 | These functions should be defined if there are any pseudo-registers. | |
3455 | The default value is @code{NULL}. @var{regnum} is the number of the | |
3456 | register to read or write (which will be a @dfn{cooked} register | |
3457 | number) and @var{buf} is the buffer where the value read will be | |
3458 | placed, or from which the value to be written will be taken. The | |
3459 | value in the buffer may be converted to or from a signed or unsigned | |
3460 | integral value using one of the utility functions (@pxref{Register and | |
d0384fc4 | 3461 | Memory Data, , Using Different Register and Memory Data |
587afa38 | 3462 | Representations}). |
af6c57ea | 3463 | |
587afa38 EZ |
3464 | The access should be for the specified architecture, |
3465 | @var{gdbarch}. Any register information can be obtained using the | |
3466 | supplied register cache, @var{regcache}. @xref{Register Caching, , | |
3467 | Register Caching}. | |
9fb4dd36 | 3468 | |
587afa38 | 3469 | @end deftypefn |
13d01224 | 3470 | |
587afa38 EZ |
3471 | @deftypevr {Architecture Variable} int sp_regnum |
3472 | @vindex sp_regnum | |
3473 | @cindex stack pointer | |
3474 | @cindex @kbd{$sp} | |
9fb4dd36 | 3475 | |
587afa38 EZ |
3476 | This specifies the register holding the stack pointer, which may be a |
3477 | raw or pseudo-register. It defaults to -1 (not defined), but it is an | |
3478 | error for it not to be defined. | |
9fb4dd36 | 3479 | |
587afa38 EZ |
3480 | The value of the stack pointer register can be accessed withing |
3481 | @value{GDBN} as the variable @kbd{$sp}. | |
3482 | ||
3483 | @end deftypevr | |
3484 | ||
3485 | @deftypevr {Architecture Variable} int pc_regnum | |
3486 | @vindex pc_regnum | |
3487 | @cindex program counter | |
3488 | @cindex @kbd{$pc} | |
3489 | ||
3490 | This specifies the register holding the program counter, which may be a | |
3491 | raw or pseudo-register. It defaults to -1 (not defined). If | |
3492 | @code{pc_regnum} is not defined, then the functions @code{read_pc} and | |
3493 | @code{write_pc} (see above) must be defined. | |
3494 | ||
3495 | The value of the program counter (whether defined as a register, or | |
3496 | through @code{read_pc} and @code{write_pc}) can be accessed withing | |
3497 | @value{GDBN} as the variable @kbd{$pc}. | |
3498 | ||
3499 | @end deftypevr | |
3500 | ||
3501 | @deftypevr {Architecture Variable} int ps_regnum | |
3502 | @vindex ps_regnum | |
3503 | @cindex processor status register | |
3504 | @cindex status register | |
3505 | @cindex @kbd{$ps} | |
3506 | ||
3507 | This specifies the register holding the processor status (often called | |
3508 | the status register), which may be a raw or pseudo-register. It | |
3509 | defaults to -1 (not defined). | |
3510 | ||
3511 | If defined, the value of this register can be accessed withing | |
3512 | @value{GDBN} as the variable @kbd{$ps}. | |
3513 | ||
3514 | @end deftypevr | |
3515 | ||
3516 | @deftypevr {Architecture Variable} int fp0_regnum | |
3517 | @vindex fp0_regnum | |
3518 | @cindex first floating point register | |
3519 | ||
3520 | This specifies the first floating point register. It defaults to | |
3521 | 0. @code{fp0_regnum} is not needed unless the target offers support | |
3522 | for floating point. | |
9fb4dd36 | 3523 | |
587afa38 | 3524 | @end deftypevr |
9fb4dd36 | 3525 | |
587afa38 EZ |
3526 | @node Register Information Functions |
3527 | @subsection Functions Giving Register Information | |
3528 | @cindex @code{gdbarch} register information functions | |
9fb4dd36 | 3529 | |
587afa38 EZ |
3530 | These functions return information about registers. |
3531 | ||
3532 | @deftypefn {Architecture Function} {const char *} register_name (struct gdbarch *@var{gdbarch}, int @var{regnum}) | |
3533 | ||
3534 | This function should convert a register number (raw or pseudo) to a | |
3535 | register name (as a C @code{const char *}). This is used both to | |
3536 | determine the name of a register for output and to work out the meaning | |
3537 | of any register names used as input. The function may also return | |
3538 | @code{NULL}, to indicate that @var{regnum} is not a valid register. | |
3539 | ||
3540 | For example with the OpenRISC 1000, @value{GDBN} registers 0-31 are the | |
3541 | General Purpose Registers, register 32 is the program counter and | |
3542 | register 33 is the supervision register (i.e.@: the processor status | |
3543 | register), which map to the strings @code{"gpr00"} through | |
3544 | @code{"gpr31"}, @code{"pc"} and @code{"sr"} respectively. This means | |
3545 | that the @value{GDBN} command @kbd{print $gpr5} should print the value of | |
3546 | the OR1K general purpose register 5@footnote{ | |
3547 | @cindex frame pointer | |
3548 | @cindex @kbd{$fp} | |
3549 | Historically, @value{GDBN} always had a concept of a frame pointer | |
3550 | register, which could be accessed via the @value{GDBN} variable, | |
3551 | @kbd{$fp}. That concept is now deprecated, recognizing that not all | |
3552 | architectures have a frame pointer. However if an architecture does | |
3553 | have a frame pointer register, and defines a register or | |
3554 | pseudo-register with the name @code{"fp"}, then that register will be | |
3555 | used as the value of the @kbd{$fp} variable.}. | |
3556 | ||
3557 | The default value for this function is @code{NULL}, meaning | |
3558 | undefined. It should always be defined. | |
3559 | ||
3560 | The access should be for the specified architecture, @var{gdbarch}. | |
6f6ef15a | 3561 | |
9fb4dd36 JB |
3562 | @end deftypefn |
3563 | ||
587afa38 | 3564 | @deftypefn {Architecture Function} {struct type *} register_type (struct gdbarch *@var{gdbarch}, int @var{regnum}) |
9fb4dd36 | 3565 | |
587afa38 EZ |
3566 | Given a register number, this function identifies the type of data it |
3567 | may be holding, specified as a @code{struct type}. @value{GDBN} allows | |
3568 | creation of arbitrary types, but a number of built in types are | |
3569 | provided (@code{builtin_type_void}, @code{builtin_type_int32} etc), | |
3570 | together with functions to derive types from these. | |
3571 | ||
3572 | Typically the program counter will have a type of ``pointer to | |
3573 | function'' (it points to code), the frame pointer and stack pointer | |
3574 | will have types of ``pointer to void'' (they point to data on the stack) | |
3575 | and all other integer registers will have a type of 32-bit integer or | |
3576 | 64-bit integer. | |
3577 | ||
3578 | This information guides the formatting when displaying register | |
3579 | information. The default value is @code{NULL} meaning no information is | |
3580 | available to guide formatting when displaying registers. | |
3581 | ||
3582 | @end deftypefn | |
3583 | ||
3584 | @deftypefn {Architecture Function} void print_registers_info (struct gdbarch *@var{gdbarch}, struct ui_file *@var{file}, struct frame_info *@var{frame}, int @var{regnum}, int @var{all}) | |
3585 | ||
3586 | Define this function to print out one or all of the registers for the | |
3587 | @value{GDBN} @kbd{info registers} command. The default value is the | |
3588 | function @code{default_print_registers_info}, which uses the register | |
3589 | type information (see @code{register_type} above) to determine how each | |
3590 | register should be printed. Define a custom version of this function | |
3591 | for fuller control over how the registers are displayed. | |
3592 | ||
3593 | The access should be for the specified architecture, @var{gdbarch}, | |
7a9dd1b2 | 3594 | with output to the file specified by the User Interface |
587afa38 EZ |
3595 | Independent Output file handle, @var{file} (@pxref{UI-Independent |
3596 | Output, , UI-Independent Output---the @code{ui_out} | |
3597 | Functions}). | |
3598 | ||
3599 | The registers should show their values in the frame specified by | |
3600 | @var{frame}. If @var{regnum} is -1 and @var{all} is zero, then all | |
3601 | the ``significant'' registers should be shown (the implementer should | |
3602 | decide which registers are ``significant''). Otherwise only the value of | |
3603 | the register specified by @var{regnum} should be output. If | |
3604 | @var{regnum} is -1 and @var{all} is non-zero (true), then the value of | |
3605 | all registers should be shown. | |
3606 | ||
3607 | By default @code{default_print_registers_info} prints one register per | |
3608 | line, and if @var{all} is zero omits floating-point registers. | |
3609 | ||
3610 | @end deftypefn | |
3611 | ||
3612 | @deftypefn {Architecture Function} void print_float_info (struct gdbarch *@var{gdbarch}, struct ui_file *@var{file}, struct frame_info *@var{frame}, const char *@var{args}) | |
3613 | ||
3614 | Define this function to provide output about the floating point unit and | |
3615 | registers for the @value{GDBN} @kbd{info float} command respectively. | |
3616 | The default value is @code{NULL} (not defined), meaning no information | |
3617 | will be provided. | |
3618 | ||
3619 | The @var{gdbarch} and @var{file} and @var{frame} arguments have the same | |
3620 | meaning as in the @code{print_registers_info} function above. The string | |
3621 | @var{args} contains any supplementary arguments to the @kbd{info float} | |
3622 | command. | |
3623 | ||
3624 | Define this function if the target supports floating point operations. | |
6f6ef15a | 3625 | |
9fb4dd36 JB |
3626 | @end deftypefn |
3627 | ||
587afa38 EZ |
3628 | @deftypefn {Architecture Function} void print_vector_info (struct gdbarch *@var{gdbarch}, struct ui_file *@var{file}, struct frame_info *@var{frame}, const char *@var{args}) |
3629 | ||
3630 | Define this function to provide output about the vector unit and | |
3631 | registers for the @value{GDBN} @kbd{info vector} command respectively. | |
3632 | The default value is @code{NULL} (not defined), meaning no information | |
3633 | will be provided. | |
3634 | ||
3635 | The @var{gdbarch}, @var{file} and @var{frame} arguments have the | |
3636 | same meaning as in the @code{print_registers_info} function above. The | |
3637 | string @var{args} contains any supplementary arguments to the @kbd{info | |
3638 | vector} command. | |
3639 | ||
3640 | Define this function if the target supports vector operations. | |
9fb4dd36 | 3641 | |
9fb4dd36 JB |
3642 | @end deftypefn |
3643 | ||
587afa38 EZ |
3644 | @deftypefn {Architecture Function} int register_reggroup_p (struct gdbarch *@var{gdbarch}, int @var{regnum}, struct reggroup *@var{group}) |
3645 | ||
3646 | @value{GDBN} groups registers into different categories (general, | |
3647 | vector, floating point etc). This function, given a register, | |
3648 | @var{regnum}, and group, @var{group}, returns 1 (true) if the register | |
3649 | is in the group and 0 (false) otherwise. | |
3650 | ||
3651 | The information should be for the specified architecture, | |
3652 | @var{gdbarch} | |
3653 | ||
3654 | The default value is the function @code{default_register_reggroup_p} | |
3655 | which will do a reasonable job based on the type of the register (see | |
3656 | the function @code{register_type} above), with groups for general | |
3657 | purpose registers, floating point registers, vector registers and raw | |
3658 | (i.e not pseudo) registers. | |
3659 | ||
3660 | @end deftypefn | |
9fb4dd36 | 3661 | |
b6fd0dfb | 3662 | @node Register and Memory Data |
587afa38 | 3663 | @subsection Using Different Register and Memory Data Representations |
13d01224 AC |
3664 | @cindex register representation |
3665 | @cindex memory representation | |
3666 | @cindex representations, register and memory | |
3667 | @cindex register data formats, converting | |
3668 | @cindex @code{struct value}, converting register contents to | |
3669 | ||
587afa38 EZ |
3670 | Some architectures have different representations of data objects, |
3671 | depending whether the object is held in a register or memory. For | |
3672 | example: | |
13d01224 AC |
3673 | |
3674 | @itemize @bullet | |
3675 | ||
3676 | @item | |
3677 | The Alpha architecture can represent 32 bit integer values in | |
3678 | floating-point registers. | |
3679 | ||
3680 | @item | |
3681 | The x86 architecture supports 80-bit floating-point registers. The | |
587afa38 EZ |
3682 | @code{long double} data type occupies 96 bits in memory but only 80 |
3683 | bits when stored in a register. | |
13d01224 AC |
3684 | |
3685 | @end itemize | |
3686 | ||
3687 | In general, the register representation of a data type is determined by | |
3688 | the architecture, or @value{GDBN}'s interface to the architecture, while | |
3689 | the memory representation is determined by the Application Binary | |
3690 | Interface. | |
3691 | ||
3692 | For almost all data types on almost all architectures, the two | |
3693 | representations are identical, and no special handling is needed. | |
587afa38 EZ |
3694 | However, they do occasionally differ. An architecture may define the |
3695 | following @code{struct gdbarch} functions to request conversions | |
3696 | between the register and memory representations of a data type: | |
13d01224 | 3697 | |
587afa38 | 3698 | @deftypefn {Architecture Function} int gdbarch_convert_register_p (struct gdbarch *@var{gdbarch}, int @var{reg}) |
13d01224 | 3699 | |
587afa38 EZ |
3700 | Return non-zero (true) if the representation of a data value stored in |
3701 | this register may be different to the representation of that same data | |
3702 | value when stored in memory. The default value is @code{NULL} | |
3703 | (undefined). | |
83acabca | 3704 | |
587afa38 EZ |
3705 | If this function is defined and returns non-zero, the @code{struct |
3706 | gdbarch} functions @code{gdbarch_register_to_value} and | |
3707 | @code{gdbarch_value_to_register} (see below) should be used to perform | |
3708 | any necessary conversion. | |
13d01224 | 3709 | |
587afa38 EZ |
3710 | If defined, this function should return zero for the register's native |
3711 | type, when no conversion is necessary. | |
3712 | @end deftypefn | |
13d01224 | 3713 | |
587afa38 | 3714 | @deftypefn {Architecture Function} void gdbarch_register_to_value (struct gdbarch *@var{gdbarch}, int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to}) |
13d01224 | 3715 | |
587afa38 EZ |
3716 | Convert the value of register number @var{reg} to a data object of |
3717 | type @var{type}. The buffer at @var{from} holds the register's value | |
3718 | in raw format; the converted value should be placed in the buffer at | |
3719 | @var{to}. | |
3720 | ||
3721 | @quotation | |
3722 | @emph{Note:} @code{gdbarch_register_to_value} and | |
3723 | @code{gdbarch_value_to_register} take their @var{reg} and @var{type} | |
3724 | arguments in different orders. | |
3725 | @end quotation | |
3726 | ||
3727 | @code{gdbarch_register_to_value} should only be used with registers | |
3728 | for which the @code{gdbarch_convert_register_p} function returns a | |
3729 | non-zero value. | |
3730 | ||
3731 | @end deftypefn | |
3732 | ||
3733 | @deftypefn {Architecture Function} void gdbarch_value_to_register (struct gdbarch *@var{gdbarch}, struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to}) | |
13d01224 | 3734 | |
13d01224 AC |
3735 | Convert a data value of type @var{type} to register number @var{reg}' |
3736 | raw format. | |
3737 | ||
587afa38 EZ |
3738 | @quotation |
3739 | @emph{Note:} @code{gdbarch_register_to_value} and | |
3740 | @code{gdbarch_value_to_register} take their @var{reg} and @var{type} | |
3741 | arguments in different orders. | |
3742 | @end quotation | |
13d01224 | 3743 | |
587afa38 EZ |
3744 | @code{gdbarch_value_to_register} should only be used with registers |
3745 | for which the @code{gdbarch_convert_register_p} function returns a | |
3746 | non-zero value. | |
3747 | ||
3748 | @end deftypefn | |
3749 | ||
3750 | @node Register Caching | |
3751 | @subsection Register Caching | |
3752 | @cindex register caching | |
3753 | ||
3754 | Caching of registers is used, so that the target does not need to be | |
3755 | accessed and reanalyzed multiple times for each register in | |
3756 | circumstances where the register value cannot have changed. | |
3757 | ||
3758 | @cindex @code{struct regcache} | |
3759 | @value{GDBN} provides @code{struct regcache}, associated with a | |
3760 | particular @code{struct gdbarch} to hold the cached values of the raw | |
3761 | registers. A set of functions is provided to access both the raw | |
3762 | registers (with @code{raw} in their name) and the full set of cooked | |
3763 | registers (with @code{cooked} in their name). Functions are provided | |
3764 | to ensure the register cache is kept synchronized with the values of | |
3765 | the actual registers in the target. | |
3766 | ||
3767 | Accessing registers through the @code{struct regcache} routines will | |
3768 | ensure that the appropriate @code{struct gdbarch} functions are called | |
3769 | when necessary to access the underlying target architecture. In general | |
3770 | users should use the @dfn{cooked} functions, since these will map to the | |
3771 | @dfn{raw} functions automatically as appropriate. | |
3772 | ||
3773 | @findex regcache_cooked_read | |
3774 | @findex regcache_cooked_write | |
3775 | @cindex @code{gdb_byte} | |
3776 | @findex regcache_cooked_read_signed | |
3777 | @findex regcache_cooked_read_unsigned | |
3778 | @findex regcache_cooked_write_signed | |
3779 | @findex regcache_cooked_write_unsigned | |
3780 | The two key functions are @code{regcache_cooked_read} and | |
3781 | @code{regcache_cooked_write} which read or write a register from or to | |
3782 | a byte buffer (type @code{gdb_byte *}). For convenience the wrapper | |
3783 | functions @code{regcache_cooked_read_signed}, | |
3784 | @code{regcache_cooked_read_unsigned}, | |
3785 | @code{regcache_cooked_write_signed} and | |
3786 | @code{regcache_cooked_write_unsigned} are provided, which read or | |
3787 | write the value using the buffer and convert to or from an integral | |
3788 | value as appropriate. | |
13d01224 | 3789 | |
b6fd0dfb | 3790 | @node Frame Interpretation |
c906108c SS |
3791 | @section Frame Interpretation |
3792 | ||
587afa38 EZ |
3793 | @menu |
3794 | * All About Stack Frames:: | |
3795 | * Frame Handling Terminology:: | |
3796 | * Prologue Caches:: | |
3797 | * Functions and Variable to Analyze Frames:: | |
3798 | * Functions to Access Frame Data:: | |
3799 | * Analyzing Stacks---Frame Sniffers:: | |
3800 | @end menu | |
3801 | ||
3802 | @node All About Stack Frames | |
3803 | @subsection All About Stack Frames | |
3804 | ||
3805 | @value{GDBN} needs to understand the stack on which local (automatic) | |
3806 | variables are stored. The area of the stack containing all the local | |
3807 | variables for a function invocation is known as the @dfn{stack frame} | |
3808 | for that function (or colloquially just as the @dfn{frame}). In turn the | |
3809 | function that called the function will have its stack frame, and so on | |
3810 | back through the chain of functions that have been called. | |
3811 | ||
3812 | Almost all architectures have one register dedicated to point to the | |
3813 | end of the stack (the @dfn{stack pointer}). Many have a second register | |
3814 | which points to the start of the currently active stack frame (the | |
3815 | @dfn{frame pointer}). The specific arrangements for an architecture are | |
3816 | a key part of the ABI. | |
3817 | ||
3818 | A diagram helps to explain this. Here is a simple program to compute | |
3819 | factorials: | |
3820 | ||
3821 | @smallexample | |
3822 | #include <stdio.h> | |
3823 | int fact (int n) | |
3824 | @{ | |
3825 | if (0 == n) | |
3826 | @{ | |
3827 | return 1; | |
3828 | @} | |
3829 | else | |
3830 | @{ | |
3831 | return n * fact (n - 1); | |
3832 | @} | |
3833 | @} | |
3834 | ||
3835 | main () | |
3836 | @{ | |
3837 | int i; | |
3838 | ||
3839 | for (i = 0; i < 10; i++) | |
3840 | @{ | |
3841 | int f = fact (i); | |
3842 | printf ("%d! = %d\n", i, f); | |
3843 | @} | |
3844 | @} | |
3845 | @end smallexample | |
3846 | ||
3847 | Consider the state of the stack when the code reaches line 6 after the | |
3848 | main program has called @code{fact@w{ }(3)}. The chain of function | |
3849 | calls will be @code{main ()}, @code{fact@w{ }(3)}, @code{fact@w{ | |
3850 | }(2)}, @code{@w{fact (1)}} and @code{fact@w{ }(0)}. | |
3851 | ||
3852 | In this illustration the stack is falling (as used for example by the | |
3853 | OpenRISC 1000 ABI). The stack pointer (SP) is at the end of the stack | |
3854 | (lowest address) and the frame pointer (FP) is at the highest address | |
3855 | in the current stack frame. The following diagram shows how the stack | |
3856 | looks. | |
3857 | ||
3858 | @center @image{stack_frame,14cm} | |
3859 | ||
3860 | In each stack frame, offset 0 from the stack pointer is the frame | |
3861 | pointer of the previous frame and offset 4 (this is illustrating a | |
3862 | 32-bit architecture) from the stack pointer is the return address. | |
3863 | Local variables are indexed from the frame pointer, with negative | |
3864 | indexes. In the function @code{fact}, offset -4 from the frame | |
3865 | pointer is the argument @var{n}. In the @code{main} function, offset | |
3866 | -4 from the frame pointer is the local variable @var{i} and offset -8 | |
3867 | from the frame pointer is the local variable @var{f}@footnote{This is | |
3868 | a simplified example for illustrative purposes only. Good optimizing | |
3869 | compilers would not put anything on the stack for such simple | |
3870 | functions. Indeed they might eliminate the recursion and use of the | |
3871 | stack entirely!}. | |
3872 | ||
3873 | It is very easy to get confused when examining stacks. @value{GDBN} | |
3874 | has terminology it uses rigorously throughout. The stack frame of the | |
3875 | function currently executing, or where execution stopped is numbered | |
3876 | zero. In this example frame #0 is the stack frame of the call to | |
3877 | @code{fact@w{ }(0)}. The stack frame of its calling function | |
3878 | (@code{fact@w{ }(1)} in this case) is numbered #1 and so on back | |
3879 | through the chain of calls. | |
3880 | ||
3881 | The main @value{GDBN} data structure describing frames is | |
3882 | @code{@w{struct frame_info}}. It is not used directly, but only via | |
3883 | its accessor functions. @code{frame_info} includes information about | |
3884 | the registers in the frame and a pointer to the code of the function | |
3885 | with which the frame is associated. The entire stack is represented as | |
3886 | a linked list of @code{frame_info} structs. | |
3887 | ||
3888 | @node Frame Handling Terminology | |
3889 | @subsection Frame Handling Terminology | |
3890 | ||
3891 | It is easy to get confused when referencing stack frames. @value{GDBN} | |
3892 | uses some precise terminology. | |
3893 | ||
3894 | @itemize @bullet | |
3895 | ||
3896 | @item | |
3897 | @cindex THIS frame | |
3898 | @cindex stack frame, definition of THIS frame | |
3899 | @cindex frame, definition of THIS frame | |
3900 | @dfn{THIS} frame is the frame currently under consideration. | |
3901 | ||
3902 | @item | |
3903 | @cindex NEXT frame | |
3904 | @cindex stack frame, definition of NEXT frame | |
3905 | @cindex frame, definition of NEXT frame | |
3906 | The @dfn{NEXT} frame, also sometimes called the inner or newer frame is the | |
3907 | frame of the function called by the function of THIS frame. | |
3908 | ||
3909 | @item | |
3910 | @cindex PREVIOUS frame | |
3911 | @cindex stack frame, definition of PREVIOUS frame | |
3912 | @cindex frame, definition of PREVIOUS frame | |
3913 | The @dfn{PREVIOUS} frame, also sometimes called the outer or older frame is | |
3914 | the frame of the function which called the function of THIS frame. | |
3915 | ||
3916 | @end itemize | |
3917 | ||
3918 | So in the example in the previous section (@pxref{All About Stack | |
3919 | Frames, , All About Stack Frames}), if THIS frame is #3 (the call to | |
3920 | @code{fact@w{ }(3)}), the NEXT frame is frame #2 (the call to | |
3921 | @code{fact@w{ }(2)}) and the PREVIOUS frame is frame #4 (the call to | |
3922 | @code{main@w{ }()}). | |
3923 | ||
3924 | @cindex innermost frame | |
3925 | @cindex stack frame, definition of innermost frame | |
3926 | @cindex frame, definition of innermost frame | |
3927 | The @dfn{innermost} frame is the frame of the current executing | |
3928 | function, or where the program stopped, in this example, in the middle | |
3929 | of the call to @code{@w{fact (0))}}. It is always numbered frame #0. | |
3930 | ||
3931 | @cindex base of a frame | |
3932 | @cindex stack frame, definition of base of a frame | |
3933 | @cindex frame, definition of base of a frame | |
3934 | The @dfn{base} of a frame is the address immediately before the start | |
3935 | of the NEXT frame. For a stack which grows down in memory (a | |
3936 | @dfn{falling} stack) this will be the lowest address and for a stack | |
3937 | which grows up in memory (a @dfn{rising} stack) this will be the | |
3938 | highest address in the frame. | |
3939 | ||
3940 | @value{GDBN} functions to analyze the stack are typically given a | |
3941 | pointer to the NEXT frame to determine information about THIS | |
3942 | frame. Information about THIS frame includes data on where the | |
3943 | registers of the PREVIOUS frame are stored in this stack frame. In | |
3944 | this example the frame pointer of the PREVIOUS frame is stored at | |
3945 | offset 0 from the stack pointer of THIS frame. | |
3946 | ||
3947 | @cindex unwinding | |
3948 | @cindex stack frame, definition of unwinding | |
3949 | @cindex frame, definition of unwinding | |
3950 | The process whereby a function is given a pointer to the NEXT | |
3951 | frame to work out information about THIS frame is referred to as | |
3952 | @dfn{unwinding}. The @value{GDBN} functions involved in this typically | |
3953 | include unwind in their name. | |
3954 | ||
3955 | @cindex sniffing | |
3956 | @cindex stack frame, definition of sniffing | |
3957 | @cindex frame, definition of sniffing | |
3958 | The process of analyzing a target to determine the information that | |
3959 | should go in struct frame_info is called @dfn{sniffing}. The functions | |
3960 | that carry this out are called sniffers and typically include sniffer | |
3961 | in their name. More than one sniffer may be required to extract all | |
3962 | the information for a particular frame. | |
3963 | ||
3964 | @cindex sentinel frame | |
3965 | @cindex stack frame, definition of sentinel frame | |
3966 | @cindex frame, definition of sentinel frame | |
3967 | Because so many functions work using the NEXT frame, there is an issue | |
3968 | about addressing the innermost frame---it has no NEXT frame. To solve | |
3969 | this @value{GDBN} creates a dummy frame #-1, known as the | |
3970 | @dfn{sentinel} frame. | |
3971 | ||
3972 | @node Prologue Caches | |
3973 | @subsection Prologue Caches | |
3974 | ||
3975 | @cindex function prologue | |
3976 | @cindex prologue of a function | |
3977 | All the frame sniffing functions typically examine the code at the | |
3978 | start of the corresponding function, to determine the state of | |
3979 | registers. The ABI will save old values and set new values of key | |
3980 | registers at the start of each function in what is known as the | |
3981 | function @dfn{prologue}. | |
3982 | ||
3983 | @cindex prologue cache | |
3984 | For any particular stack frame this data does not change, so all the | |
3985 | standard unwinding functions, in addition to receiving a pointer to | |
3986 | the NEXT frame as their first argument, receive a pointer to a | |
3987 | @dfn{prologue cache} as their second argument. This can be used to store | |
3988 | values associated with a particular frame, for reuse on subsequent | |
3989 | calls involving the same frame. | |
3990 | ||
3991 | It is up to the user to define the structure used (it is a | |
3992 | @code{void@w{ }*} pointer) and arrange allocation and deallocation of | |
3993 | storage. However for general use, @value{GDBN} provides | |
3994 | @code{@w{struct trad_frame_cache}}, with a set of accessor | |
3995 | routines. This structure holds the stack and code address of | |
3996 | THIS frame, the base address of the frame, a pointer to the | |
3997 | struct @code{frame_info} for the NEXT frame and details of | |
3998 | where the registers of the PREVIOUS frame may be found in THIS | |
3999 | frame. | |
4000 | ||
4001 | Typically the first time any sniffer function is called with NEXT | |
4002 | frame, the prologue sniffer for THIS frame will be @code{NULL}. The | |
4003 | sniffer will analyze the frame, allocate a prologue cache structure | |
4004 | and populate it. Subsequent calls using the same NEXT frame will | |
4005 | pass in this prologue cache, so the data can be returned with no | |
4006 | additional analysis. | |
4007 | ||
4008 | @node Functions and Variable to Analyze Frames | |
4009 | @subsection Functions and Variable to Analyze Frames | |
4010 | ||
4011 | These struct @code{gdbarch} functions and variable should be defined | |
4012 | to provide analysis of the stack frame and allow it to be adjusted as | |
4013 | required. | |
4014 | ||
4015 | @deftypefn {Architecture Function} CORE_ADDR skip_prologue (struct gdbarch *@var{gdbarch}, CORE_ADDR @var{pc}) | |
4016 | ||
4017 | The prologue of a function is the code at the beginning of the | |
4018 | function which sets up the stack frame, saves the return address | |
4019 | etc. The code representing the behavior of the function starts after | |
4020 | the prologue. | |
4021 | ||
4022 | This function skips past the prologue of a function if the program | |
4023 | counter, @var{pc}, is within the prologue of a function. The result is | |
4024 | the program counter immediately after the prologue. With modern | |
4025 | optimizing compilers, this may be a far from trivial exercise. However | |
4026 | the required information may be within the binary as DWARF2 debugging | |
4027 | information, making the job much easier. | |
4028 | ||
4029 | The default value is @code{NULL} (not defined). This function should always | |
4030 | be provided, but can take advantage of DWARF2 debugging information, | |
4031 | if that is available. | |
4032 | ||
4033 | @end deftypefn | |
4034 | ||
4035 | @deftypefn {Architecture Function} int inner_than (CORE_ADDR @var{lhs}, CORE_ADDR @var{rhs}) | |
4036 | @findex core_addr_lessthan | |
4037 | @findex core_addr_greaterthan | |
4038 | ||
4039 | Given two frame or stack pointers, return non-zero (true) if the first | |
4040 | represents the @dfn{inner} stack frame and 0 (false) otherwise. This | |
4041 | is used to determine whether the target has a stack which grows up in | |
4042 | memory (rising stack) or grows down in memory (falling stack). | |
4043 | @xref{All About Stack Frames, , All About Stack Frames}, for an | |
4044 | explanation of @dfn{inner} frames. | |
4045 | ||
4046 | The default value of this function is @code{NULL} and it should always | |
4047 | be defined. However for almost all architectures one of the built-in | |
4048 | functions can be used: @code{core_addr_lessthan} (for stacks growing | |
4049 | down in memory) or @code{core_addr_greaterthan} (for stacks growing up | |
4050 | in memory). | |
4051 | ||
4052 | @end deftypefn | |
4053 | ||
4054 | @anchor{frame_align} | |
4055 | @deftypefn {Architecture Function} CORE_ADDR frame_align (struct gdbarch *@var{gdbarch}, CORE_ADDR @var{address}) | |
4056 | @findex align_down | |
4057 | @findex align_up | |
4058 | ||
4059 | The architecture may have constraints on how its frames are | |
4060 | aligned. For example the OpenRISC 1000 ABI requires stack frames to be | |
4061 | double-word aligned, but 32-bit versions of the architecture allocate | |
4062 | single-word values to the stack. Thus extra padding may be needed at | |
4063 | the end of a stack frame. | |
4064 | ||
4065 | Given a proposed address for the stack pointer, this function | |
4066 | returns a suitably aligned address (by expanding the stack frame). | |
4067 | ||
4068 | The default value is @code{NULL} (undefined). This function should be defined | |
4069 | for any architecture where it is possible the stack could become | |
4070 | misaligned. The utility functions @code{align_down} (for falling | |
4071 | stacks) and @code{align_up} (for rising stacks) will facilitate the | |
4072 | implementation of this function. | |
4073 | ||
4074 | @end deftypefn | |
4075 | ||
4076 | @deftypevr {Architecture Variable} int frame_red_zone_size | |
4077 | ||
4078 | Some ABIs reserve space beyond the end of the stack for use by leaf | |
4079 | functions without prologue or epilogue or by exception handlers (for | |
4080 | example the OpenRISC 1000). | |
4081 | ||
4082 | This is known as a @dfn{red zone} (AMD terminology). The @sc{amd64} | |
4083 | (nee x86-64) ABI documentation refers to the @dfn{red zone} when | |
4084 | describing this scratch area. | |
4085 | ||
4086 | The default value is 0. Set this field if the architecture has such a | |
4087 | red zone. The value must be aligned as required by the ABI (see | |
4088 | @code{frame_align} above for an explanation of stack frame alignment). | |
4089 | ||
4090 | @end deftypevr | |
4091 | ||
4092 | @node Functions to Access Frame Data | |
4093 | @subsection Functions to Access Frame Data | |
4094 | ||
4095 | These functions provide access to key registers and arguments in the | |
4096 | stack frame. | |
4097 | ||
4098 | @deftypefn {Architecture Function} CORE_ADDR unwind_pc (struct gdbarch *@var{gdbarch}, struct frame_info *@var{next_frame}) | |
4099 | ||
4100 | This function is given a pointer to the NEXT stack frame (@pxref{All | |
4101 | About Stack Frames, , All About Stack Frames}, for how frames are | |
4102 | represented) and returns the value of the program counter in the | |
4103 | PREVIOUS frame (i.e.@: the frame of the function that called THIS | |
4104 | one). This is commonly referred to as the @dfn{return address}. | |
4105 | ||
4106 | The implementation, which must be frame agnostic (work with any frame), | |
4107 | is typically no more than: | |
4108 | ||
4109 | @smallexample | |
4110 | ULONGEST pc; | |
4111 | pc = frame_unwind_register_unsigned (next_frame, @var{ARCH}_PC_REGNUM); | |
4112 | return gdbarch_addr_bits_remove (gdbarch, pc); | |
4113 | @end smallexample | |
4114 | ||
4115 | @end deftypefn | |
4116 | ||
4117 | @deftypefn {Architecture Function} CORE_ADDR unwind_sp (struct gdbarch *@var{gdbarch}, struct frame_info *@var{next_frame}) | |
4118 | ||
4119 | This function is given a pointer to the NEXT stack frame | |
4120 | (@pxref{All About Stack Frames, , All About Stack Frames} for how | |
4121 | frames are represented) and returns the value of the stack pointer in | |
4122 | the PREVIOUS frame (i.e.@: the frame of the function that called | |
4123 | THIS one). | |
4124 | ||
4125 | The implementation, which must be frame agnostic (work with any frame), | |
4126 | is typically no more than: | |
4127 | ||
4128 | @smallexample | |
4129 | ULONGEST sp; | |
4130 | sp = frame_unwind_register_unsigned (next_frame, @var{ARCH}_SP_REGNUM); | |
4131 | return gdbarch_addr_bits_remove (gdbarch, sp); | |
4132 | @end smallexample | |
4133 | ||
4134 | @end deftypefn | |
4135 | ||
4136 | @deftypefn {Architecture Function} int frame_num_args (struct gdbarch *@var{gdbarch}, struct frame_info *@var{this_frame}) | |
4137 | ||
4138 | This function is given a pointer to THIS stack frame (@pxref{All | |
4139 | About Stack Frames, , All About Stack Frames} for how frames are | |
4140 | represented), and returns the number of arguments that are being | |
4141 | passed, or -1 if not known. | |
4142 | ||
4143 | The default value is @code{NULL} (undefined), in which case the number of | |
4144 | arguments passed on any stack frame is always unknown. For many | |
4145 | architectures this will be a suitable default. | |
4146 | ||
4147 | @end deftypefn | |
4148 | ||
4149 | @node Analyzing Stacks---Frame Sniffers | |
4150 | @subsection Analyzing Stacks---Frame Sniffers | |
4151 | ||
4152 | When a program stops, @value{GDBN} needs to construct the chain of | |
4153 | struct @code{frame_info} representing the state of the stack using | |
4154 | appropriate @dfn{sniffers}. | |
4155 | ||
4156 | Each architecture requires appropriate sniffers, but they do not form | |
4157 | entries in @code{@w{struct gdbarch}}, since more than one sniffer may | |
4158 | be required and a sniffer may be suitable for more than one | |
4159 | @code{@w{struct gdbarch}}. Instead sniffers are associated with | |
4160 | architectures using the following functions. | |
4161 | ||
4162 | @itemize @bullet | |
4163 | ||
4164 | @item | |
4165 | @findex frame_unwind_append_sniffer | |
4166 | @code{frame_unwind_append_sniffer} is used to add a new sniffer to | |
4167 | analyze THIS frame when given a pointer to the NEXT frame. | |
4168 | ||
4169 | @item | |
4170 | @findex frame_base_append_sniffer | |
4171 | @code{frame_base_append_sniffer} is used to add a new sniffer | |
4172 | which can determine information about the base of a stack frame. | |
4173 | ||
4174 | @item | |
4175 | @findex frame_base_set_default | |
4176 | @code{frame_base_set_default} is used to specify the default base | |
4177 | sniffer. | |
4178 | ||
4179 | @end itemize | |
4180 | ||
4181 | These functions all take a reference to @code{@w{struct gdbarch}}, so | |
4182 | they are associated with a specific architecture. They are usually | |
4183 | called in the @code{gdbarch} initialization function, after the | |
4184 | @code{gdbarch} struct has been set up. Unless a default has been set, the | |
4185 | most recently appended sniffer will be tried first. | |
4186 | ||
4187 | The main frame unwinding sniffer (as set by | |
4188 | @code{frame_unwind_append_sniffer)} returns a structure specifying | |
4189 | a set of sniffing functions: | |
4190 | ||
4191 | @cindex @code{frame_unwind} | |
4192 | @smallexample | |
4193 | struct frame_unwind | |
4194 | @{ | |
4195 | enum frame_type type; | |
4196 | frame_this_id_ftype *this_id; | |
4197 | frame_prev_register_ftype *prev_register; | |
4198 | const struct frame_data *unwind_data; | |
4199 | frame_sniffer_ftype *sniffer; | |
4200 | frame_prev_pc_ftype *prev_pc; | |
4201 | frame_dealloc_cache_ftype *dealloc_cache; | |
4202 | @}; | |
4203 | @end smallexample | |
4204 | ||
4205 | The @code{type} field indicates the type of frame this sniffer can | |
4206 | handle: normal, dummy (@pxref{Functions Creating Dummy Frames, , | |
4207 | Functions Creating Dummy Frames}), signal handler or sentinel. Signal | |
4208 | handlers sometimes have their own simplified stack structure for | |
4209 | efficiency, so may need their own handlers. | |
4210 | ||
4211 | The @code{unwind_data} field holds additional information which may be | |
4212 | relevant to particular types of frame. For example it may hold | |
4213 | additional information for signal handler frames. | |
4214 | ||
4215 | The remaining fields define functions that yield different types of | |
4216 | information when given a pointer to the NEXT stack frame. Not all | |
4217 | functions need be provided. If an entry is @code{NULL}, the next sniffer will | |
4218 | be tried instead. | |
4219 | ||
4220 | @itemize @bullet | |
4221 | ||
4222 | @item | |
4223 | @code{this_id} determines the stack pointer and function (code | |
4224 | entry point) for THIS stack frame. | |
4225 | ||
4226 | @item | |
4227 | @code{prev_register} determines where the values of registers for | |
4228 | the PREVIOUS stack frame are stored in THIS stack frame. | |
4229 | ||
4230 | @item | |
4231 | @code{sniffer} takes a look at THIS frame's registers to | |
4232 | determine if this is the appropriate unwinder. | |
4233 | ||
4234 | @item | |
4235 | @code{prev_pc} determines the program counter for THIS | |
4236 | frame. Only needed if the program counter is not an ordinary register | |
4237 | (@pxref{Register Architecture Functions & Variables, | |
4238 | , Functions and Variables Specifying the Register Architecture}). | |
4239 | ||
4240 | @item | |
4241 | @code{dealloc_cache} frees any additional memory associated with | |
4242 | the prologue cache for this frame (@pxref{Prologue Caches, , Prologue | |
4243 | Caches}). | |
4244 | ||
4245 | @end itemize | |
4246 | ||
4247 | In general it is only the @code{this_id} and @code{prev_register} | |
4248 | fields that need be defined for custom sniffers. | |
4249 | ||
4250 | The frame base sniffer is much simpler. It is a @code{@w{struct | |
4251 | frame_base}}, which refers to the corresponding @code{frame_unwind} | |
4252 | struct and whose fields refer to functions yielding various addresses | |
4253 | within the frame. | |
4254 | ||
4255 | @cindex @code{frame_base} | |
4256 | @smallexample | |
4257 | struct frame_base | |
4258 | @{ | |
4259 | const struct frame_unwind *unwind; | |
4260 | frame_this_base_ftype *this_base; | |
4261 | frame_this_locals_ftype *this_locals; | |
4262 | frame_this_args_ftype *this_args; | |
4263 | @}; | |
4264 | @end smallexample | |
4265 | ||
4266 | All the functions referred to take a pointer to the NEXT frame as | |
4267 | argument. The function referred to by @code{this_base} returns the | |
4268 | base address of THIS frame, the function referred to by | |
4269 | @code{this_locals} returns the base address of local variables in THIS | |
4270 | frame and the function referred to by @code{this_args} returns the | |
4271 | base address of the function arguments in this frame. | |
4272 | ||
4273 | As described above, the base address of a frame is the address | |
4274 | immediately before the start of the NEXT frame. For a falling | |
4275 | stack, this is the lowest address in the frame and for a rising stack | |
4276 | it is the highest address in the frame. For most architectures the | |
4277 | same address is also the base address for local variables and | |
4278 | arguments, in which case the same function can be used for all three | |
4279 | entries@footnote{It is worth noting that if it cannot be determined in any | |
4280 | other way (for example by there being a register with the name | |
4281 | @code{"fp"}), then the result of the @code{this_base} function will be | |
4282 | used as the value of the frame pointer variable @kbd{$fp} in | |
4283 | @value{GDBN}. This is very often not correct (for example with the | |
4284 | OpenRISC 1000, this value is the stack pointer, @kbd{$sp}). In this | |
4285 | case a register (raw or pseudo) with the name @code{"fp"} should be | |
4286 | defined. It will be used in preference as the value of @kbd{$fp}.}. | |
4287 | ||
b6fd0dfb | 4288 | @node Inferior Call Setup |
c906108c | 4289 | @section Inferior Call Setup |
587afa38 EZ |
4290 | @cindex calls to the inferior |
4291 | ||
4292 | @menu | |
4293 | * About Dummy Frames:: | |
4294 | * Functions Creating Dummy Frames:: | |
4295 | @end menu | |
4296 | ||
4297 | @node About Dummy Frames | |
4298 | @subsection About Dummy Frames | |
4299 | @cindex dummy frames | |
4300 | ||
4301 | @value{GDBN} can call functions in the target code (for example by | |
4302 | using the @kbd{call} or @kbd{print} commands). These functions may be | |
4303 | breakpointed, and it is essential that if a function does hit a | |
4304 | breakpoint, commands like @kbd{backtrace} work correctly. | |
4305 | ||
4306 | This is achieved by making the stack look as though the function had | |
4307 | been called from the point where @value{GDBN} had previously stopped. | |
4308 | This requires that @value{GDBN} can set up stack frames appropriate for | |
4309 | such function calls. | |
4310 | ||
4311 | @node Functions Creating Dummy Frames | |
4312 | @subsection Functions Creating Dummy Frames | |
4313 | ||
4314 | The following functions provide the functionality to set up such | |
4315 | @dfn{dummy} stack frames. | |
4316 | ||
4317 | @deftypefn {Architecture Function} CORE_ADDR push_dummy_call (struct gdbarch *@var{gdbarch}, struct value *@var{function}, struct regcache *@var{regcache}, CORE_ADDR @var{bp_addr}, int @var{nargs}, struct value **@var{args}, CORE_ADDR @var{sp}, int @var{struct_return}, CORE_ADDR @var{struct_addr}) | |
4318 | ||
4319 | This function sets up a dummy stack frame for the function about to be | |
4320 | called. @code{push_dummy_call} is given the arguments to be passed | |
4321 | and must copy them into registers or push them on to the stack as | |
4322 | appropriate for the ABI. | |
4323 | ||
4324 | @var{function} is a pointer to the function | |
4325 | that will be called and @var{regcache} the register cache from which | |
4326 | values should be obtained. @var{bp_addr} is the address to which the | |
4327 | function should return (which is breakpointed, so @value{GDBN} can | |
4328 | regain control, hence the name). @var{nargs} is the number of | |
4329 | arguments to pass and @var{args} an array containing the argument | |
4330 | values. @var{struct_return} is non-zero (true) if the function returns | |
4331 | a structure, and if so @var{struct_addr} is the address in which the | |
4332 | structure should be returned. | |
4333 | ||
4334 | After calling this function, @value{GDBN} will pass control to the | |
4335 | target at the address of the function, which will find the stack and | |
4336 | registers set up just as expected. | |
4337 | ||
4338 | The default value of this function is @code{NULL} (undefined). If the | |
4339 | function is not defined, then @value{GDBN} will not allow the user to | |
4340 | call functions within the target being debugged. | |
4341 | ||
4342 | @end deftypefn | |
4343 | ||
4344 | @deftypefn {Architecture Function} {struct frame_id} unwind_dummy_id (struct gdbarch *@var{gdbarch}, struct frame_info *@var{next_frame}) | |
4345 | ||
4346 | This is the inverse of @code{push_dummy_call} which restores the stack | |
4347 | pointer and program counter after a call to evaluate a function using | |
4348 | a dummy stack frame. The result is a @code{@w{struct frame_id}}, which | |
4349 | contains the value of the stack pointer and program counter to be | |
4350 | used. | |
4351 | ||
4352 | The NEXT frame pointer is provided as argument, | |
4353 | @var{next_frame}. THIS frame is the frame of the dummy function, | |
4354 | which can be unwound, to yield the required stack pointer and program | |
4355 | counter from the PREVIOUS frame. | |
4356 | ||
4357 | The default value is @code{NULL} (undefined). If @code{push_dummy_call} is | |
4358 | defined, then this function should also be defined. | |
c906108c | 4359 | |
587afa38 EZ |
4360 | @end deftypefn |
4361 | ||
4362 | @deftypefn {Architecture Function} CORE_ADDR push_dummy_code (struct gdbarch *@var{gdbarch}, CORE_ADDR @var{sp}, CORE_ADDR @var{funaddr}, struct value **@var{args}, int @var{nargs}, struct type *@var{value_type}, CORE_ADDR *@var{real_pc}, CORE_ADDR *@var{bp_addr}, struct regcache *@var{regcache}) | |
4363 | ||
4364 | If this function is not defined (its default value is @code{NULL}), a dummy | |
4365 | call will use the entry point of the currently loaded code on the | |
4366 | target as its return address. A temporary breakpoint will be set | |
4367 | there, so the location must be writable and have room for a | |
4368 | breakpoint. | |
c906108c | 4369 | |
587afa38 EZ |
4370 | It is possible that this default is not suitable. It might not be |
4371 | writable (in ROM possibly), or the ABI might require code to be | |
4372 | executed on return from a call to unwind the stack before the | |
4373 | breakpoint is encountered. | |
c906108c | 4374 | |
587afa38 EZ |
4375 | If either of these is the case, then push_dummy_code should be defined |
4376 | to push an instruction sequence onto the end of the stack to which the | |
4377 | dummy call should return. | |
4378 | ||
4379 | The arguments are essentially the same as those to | |
4380 | @code{push_dummy_call}. However the function is provided with the | |
4381 | type of the function result, @var{value_type}, @var{bp_addr} is used | |
4382 | to return a value (the address at which the breakpoint instruction | |
4383 | should be inserted) and @var{real pc} is used to specify the resume | |
4384 | address when starting the call sequence. The function should return | |
4385 | the updated innermost stack address. | |
4386 | ||
4387 | @quotation | |
4388 | @emph{Note:} This does require that code in the stack can be executed. | |
4389 | Some Harvard architectures may not allow this. | |
4390 | @end quotation | |
4391 | ||
4392 | @end deftypefn | |
4393 | ||
b39f4988 JB |
4394 | @node Adding support for debugging core files |
4395 | @section Adding support for debugging core files | |
4396 | @cindex core files | |
4397 | ||
4398 | The prerequisite for adding core file support in @value{GDBN} is to have | |
4399 | core file support in BFD. | |
4400 | ||
4401 | Once BFD support is available, writing the apropriate | |
4402 | @code{regset_from_core_section} architecture function should be all | |
4403 | that is needed in order to add support for core files in @value{GDBN}. | |
4404 | ||
587afa38 EZ |
4405 | @node Defining Other Architecture Features |
4406 | @section Defining Other Architecture Features | |
4407 | ||
4408 | This section describes other functions and values in @code{gdbarch}, | |
4409 | together with some useful macros, that you can use to define the | |
4410 | target architecture. | |
c906108c SS |
4411 | |
4412 | @table @code | |
4413 | ||
4a9bb1df UW |
4414 | @item CORE_ADDR gdbarch_addr_bits_remove (@var{gdbarch}, @var{addr}) |
4415 | @findex gdbarch_addr_bits_remove | |
adf40b2e | 4416 | If a raw machine instruction address includes any bits that are not |
4a9bb1df UW |
4417 | really part of the address, then this function is used to zero those bits in |
4418 | @var{addr}. This is only used for addresses of instructions, and even then not | |
4419 | in all contexts. | |
adf40b2e JM |
4420 | |
4421 | For example, the two low-order bits of the PC on the Hewlett-Packard PA | |
4422 | 2.0 architecture contain the privilege level of the corresponding | |
4423 | instruction. Since instructions must always be aligned on four-byte | |
4424 | boundaries, the processor masks out these bits to generate the actual | |
4a9bb1df UW |
4425 | address of the instruction. @code{gdbarch_addr_bits_remove} would then for |
4426 | example look like that: | |
4427 | @smallexample | |
4428 | arch_addr_bits_remove (CORE_ADDR addr) | |
4429 | @{ | |
4430 | return (addr &= ~0x3); | |
4431 | @} | |
4432 | @end smallexample | |
c906108c | 4433 | |
4a9bb1df UW |
4434 | @item int address_class_name_to_type_flags (@var{gdbarch}, @var{name}, @var{type_flags_ptr}) |
4435 | @findex address_class_name_to_type_flags | |
b5b0480a KB |
4436 | If @var{name} is a valid address class qualifier name, set the @code{int} |
4437 | referenced by @var{type_flags_ptr} to the mask representing the qualifier | |
4438 | and return 1. If @var{name} is not a valid address class qualifier name, | |
4439 | return 0. | |
4440 | ||
4441 | The value for @var{type_flags_ptr} should be one of | |
4442 | @code{TYPE_FLAG_ADDRESS_CLASS_1}, @code{TYPE_FLAG_ADDRESS_CLASS_2}, or | |
4443 | possibly some combination of these values or'd together. | |
4444 | @xref{Target Architecture Definition, , Address Classes}. | |
4445 | ||
4a9bb1df UW |
4446 | @item int address_class_name_to_type_flags_p (@var{gdbarch}) |
4447 | @findex address_class_name_to_type_flags_p | |
4448 | Predicate which indicates whether @code{address_class_name_to_type_flags} | |
b5b0480a KB |
4449 | has been defined. |
4450 | ||
4a9bb1df UW |
4451 | @item int gdbarch_address_class_type_flags (@var{gdbarch}, @var{byte_size}, @var{dwarf2_addr_class}) |
4452 | @findex gdbarch_address_class_type_flags | |
b5b0480a KB |
4453 | Given a pointers byte size (as described by the debug information) and |
4454 | the possible @code{DW_AT_address_class} value, return the type flags | |
4455 | used by @value{GDBN} to represent this address class. The value | |
4456 | returned should be one of @code{TYPE_FLAG_ADDRESS_CLASS_1}, | |
4457 | @code{TYPE_FLAG_ADDRESS_CLASS_2}, or possibly some combination of these | |
4458 | values or'd together. | |
4459 | @xref{Target Architecture Definition, , Address Classes}. | |
4460 | ||
4a9bb1df UW |
4461 | @item int gdbarch_address_class_type_flags_p (@var{gdbarch}) |
4462 | @findex gdbarch_address_class_type_flags_p | |
4463 | Predicate which indicates whether @code{gdbarch_address_class_type_flags_p} has | |
b5b0480a KB |
4464 | been defined. |
4465 | ||
4a9bb1df UW |
4466 | @item const char *gdbarch_address_class_type_flags_to_name (@var{gdbarch}, @var{type_flags}) |
4467 | @findex gdbarch_address_class_type_flags_to_name | |
b5b0480a KB |
4468 | Return the name of the address class qualifier associated with the type |
4469 | flags given by @var{type_flags}. | |
4470 | ||
4a9bb1df UW |
4471 | @item int gdbarch_address_class_type_flags_to_name_p (@var{gdbarch}) |
4472 | @findex gdbarch_address_class_type_flags_to_name_p | |
4473 | Predicate which indicates whether @code{gdbarch_address_class_type_flags_to_name} has been defined. | |
b5b0480a KB |
4474 | @xref{Target Architecture Definition, , Address Classes}. |
4475 | ||
4a9bb1df UW |
4476 | @item void gdbarch_address_to_pointer (@var{gdbarch}, @var{type}, @var{buf}, @var{addr}) |
4477 | @findex gdbarch_address_to_pointer | |
93e79dbd JB |
4478 | Store in @var{buf} a pointer of type @var{type} representing the address |
4479 | @var{addr}, in the appropriate format for the current architecture. | |
4a9bb1df | 4480 | This function may safely assume that @var{type} is either a pointer or a |
56caf160 | 4481 | C@t{++} reference type. |
93e79dbd JB |
4482 | @xref{Target Architecture Definition, , Pointers Are Not Always Addresses}. |
4483 | ||
4a9bb1df UW |
4484 | @item int gdbarch_believe_pcc_promotion (@var{gdbarch}) |
4485 | @findex gdbarch_believe_pcc_promotion | |
4486 | Used to notify if the compiler promotes a @code{short} or @code{char} | |
56caf160 EZ |
4487 | parameter to an @code{int}, but still reports the parameter as its |
4488 | original type, rather than the promoted type. | |
c906108c | 4489 | |
32c9a795 MD |
4490 | @item gdbarch_bits_big_endian (@var{gdbarch}) |
4491 | @findex gdbarch_bits_big_endian | |
4492 | This is used if the numbering of bits in the targets does @strong{not} match | |
587afa38 | 4493 | the endianism of the target byte order. A value of 1 means that the bits |
56caf160 | 4494 | are numbered in a big-endian bit order, 0 means little-endian. |
c906108c | 4495 | |
32c9a795 MD |
4496 | @item set_gdbarch_bits_big_endian (@var{gdbarch}, @var{bits_big_endian}) |
4497 | @findex set_gdbarch_bits_big_endian | |
4498 | Calling set_gdbarch_bits_big_endian with a value of 1 indicates that the | |
4499 | bits in the target are numbered in a big-endian bit order, 0 indicates | |
4500 | little-endian. | |
4501 | ||
c906108c | 4502 | @item BREAKPOINT |
56caf160 | 4503 | @findex BREAKPOINT |
c906108c SS |
4504 | This is the character array initializer for the bit pattern to put into |
4505 | memory where a breakpoint is set. Although it's common to use a trap | |
4506 | instruction for a breakpoint, it's not required; for instance, the bit | |
4507 | pattern could be an invalid instruction. The breakpoint must be no | |
4508 | longer than the shortest instruction of the architecture. | |
4509 | ||
56caf160 | 4510 | @code{BREAKPOINT} has been deprecated in favor of |
4a9bb1df | 4511 | @code{gdbarch_breakpoint_from_pc}. |
7a292a7a | 4512 | |
c906108c | 4513 | @item BIG_BREAKPOINT |
56caf160 EZ |
4514 | @itemx LITTLE_BREAKPOINT |
4515 | @findex LITTLE_BREAKPOINT | |
4516 | @findex BIG_BREAKPOINT | |
c906108c SS |
4517 | Similar to BREAKPOINT, but used for bi-endian targets. |
4518 | ||
56caf160 | 4519 | @code{BIG_BREAKPOINT} and @code{LITTLE_BREAKPOINT} have been deprecated in |
4a9bb1df | 4520 | favor of @code{gdbarch_breakpoint_from_pc}. |
7a292a7a | 4521 | |
4a9bb1df UW |
4522 | @item const gdb_byte *gdbarch_breakpoint_from_pc (@var{gdbarch}, @var{pcptr}, @var{lenptr}) |
4523 | @findex gdbarch_breakpoint_from_pc | |
4524 | @anchor{gdbarch_breakpoint_from_pc} Use the program counter to determine the | |
2dd0da42 | 4525 | contents and size of a breakpoint instruction. It returns a pointer to |
a655d424 | 4526 | a static string of bytes that encode a breakpoint instruction, stores the |
2dd0da42 AC |
4527 | length of the string to @code{*@var{lenptr}}, and adjusts the program |
4528 | counter (if necessary) to point to the actual memory location where the | |
121c73f3 JK |
4529 | breakpoint should be inserted. On input, the program counter |
4530 | (@code{*@var{pcptr}} is the encoded inferior's PC register. If software | |
4531 | breakpoints are supported, the function sets this argument to the PC's | |
4532 | plain address. If software breakpoints are not supported, the function | |
4533 | returns NULL instead of the encoded breakpoint instruction. | |
c906108c SS |
4534 | |
4535 | Although it is common to use a trap instruction for a breakpoint, it's | |
4536 | not required; for instance, the bit pattern could be an invalid | |
4537 | instruction. The breakpoint must be no longer than the shortest | |
4538 | instruction of the architecture. | |
4539 | ||
a655d424 JK |
4540 | Provided breakpoint bytes can be also used by @code{bp_loc_is_permanent} to |
4541 | detect permanent breakpoints. @code{gdbarch_breakpoint_from_pc} should return | |
4542 | an unchanged memory copy if it was called for a location with permanent | |
4543 | breakpoint as some architectures use breakpoint instructions containing | |
4544 | arbitrary parameter value. | |
4545 | ||
7a292a7a SS |
4546 | Replaces all the other @var{BREAKPOINT} macros. |
4547 | ||
4a9bb1df UW |
4548 | @item int gdbarch_memory_insert_breakpoint (@var{gdbarch}, @var{bp_tgt}) |
4549 | @itemx gdbarch_memory_remove_breakpoint (@var{gdbarch}, @var{bp_tgt}) | |
4550 | @findex gdbarch_memory_remove_breakpoint | |
4551 | @findex gdbarch_memory_insert_breakpoint | |
917317f4 JM |
4552 | Insert or remove memory based breakpoints. Reasonable defaults |
4553 | (@code{default_memory_insert_breakpoint} and | |
4554 | @code{default_memory_remove_breakpoint} respectively) have been | |
4a9bb1df UW |
4555 | provided so that it is not necessary to set these for most |
4556 | architectures. Architectures which may want to set | |
4557 | @code{gdbarch_memory_insert_breakpoint} and @code{gdbarch_memory_remove_breakpoint} will likely have instructions that are oddly sized or are not stored in a | |
917317f4 JM |
4558 | conventional manner. |
4559 | ||
4560 | It may also be desirable (from an efficiency standpoint) to define | |
4561 | custom breakpoint insertion and removal routines if | |
4a9bb1df | 4562 | @code{gdbarch_breakpoint_from_pc} needs to read the target's memory for some |
917317f4 JM |
4563 | reason. |
4564 | ||
4a9bb1df UW |
4565 | @item CORE_ADDR gdbarch_adjust_breakpoint_address (@var{gdbarch}, @var{bpaddr}) |
4566 | @findex gdbarch_adjust_breakpoint_address | |
1485d690 KB |
4567 | @cindex breakpoint address adjusted |
4568 | Given an address at which a breakpoint is desired, return a breakpoint | |
4569 | address adjusted to account for architectural constraints on | |
4570 | breakpoint placement. This method is not needed by most targets. | |
4571 | ||
4572 | The FR-V target (see @file{frv-tdep.c}) requires this method. | |
4573 | The FR-V is a VLIW architecture in which a number of RISC-like | |
4574 | instructions are grouped (packed) together into an aggregate | |
4575 | instruction or instruction bundle. When the processor executes | |
4576 | one of these bundles, the component instructions are executed | |
4577 | in parallel. | |
4578 | ||
4579 | In the course of optimization, the compiler may group instructions | |
4580 | from distinct source statements into the same bundle. The line number | |
4581 | information associated with one of the latter statements will likely | |
4582 | refer to some instruction other than the first one in the bundle. So, | |
4583 | if the user attempts to place a breakpoint on one of these latter | |
4584 | statements, @value{GDBN} must be careful to @emph{not} place the break | |
4585 | instruction on any instruction other than the first one in the bundle. | |
4586 | (Remember though that the instructions within a bundle execute | |
4587 | in parallel, so the @emph{first} instruction is the instruction | |
4588 | at the lowest address and has nothing to do with execution order.) | |
4589 | ||
4a9bb1df | 4590 | The FR-V's @code{gdbarch_adjust_breakpoint_address} method will adjust a |
1485d690 KB |
4591 | breakpoint's address by scanning backwards for the beginning of |
4592 | the bundle, returning the address of the bundle. | |
4593 | ||
4594 | Since the adjustment of a breakpoint may significantly alter a user's | |
4595 | expectation, @value{GDBN} prints a warning when an adjusted breakpoint | |
4596 | is initially set and each time that that breakpoint is hit. | |
4597 | ||
4a9bb1df UW |
4598 | @item int gdbarch_call_dummy_location (@var{gdbarch}) |
4599 | @findex gdbarch_call_dummy_location | |
56caf160 | 4600 | See the file @file{inferior.h}. |
7a292a7a | 4601 | |
4a9bb1df UW |
4602 | This method has been replaced by @code{gdbarch_push_dummy_code} |
4603 | (@pxref{gdbarch_push_dummy_code}). | |
7043d8dc | 4604 | |
4a9bb1df UW |
4605 | @item int gdbarch_cannot_fetch_register (@var{gdbarch}, @var{regum}) |
4606 | @findex gdbarch_cannot_fetch_register | |
4607 | This function should return nonzero if @var{regno} cannot be fetched | |
a53f55d8 | 4608 | from an inferior process. |
c906108c | 4609 | |
4a9bb1df UW |
4610 | @item int gdbarch_cannot_store_register (@var{gdbarch}, @var{regnum}) |
4611 | @findex gdbarch_cannot_store_register | |
4612 | This function should return nonzero if @var{regno} should not be | |
c906108c | 4613 | written to the target. This is often the case for program counters, |
4a9bb1df UW |
4614 | status words, and other special registers. This function returns 0 as |
4615 | default so that @value{GDBN} will assume that all registers may be written. | |
c906108c | 4616 | |
4a9bb1df UW |
4617 | @item int gdbarch_convert_register_p (@var{gdbarch}, @var{regnum}, struct type *@var{type}) |
4618 | @findex gdbarch_convert_register_p | |
83acabca DJ |
4619 | Return non-zero if register @var{regnum} represents data values of type |
4620 | @var{type} in a non-standard form. | |
13d01224 AC |
4621 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
4622 | ||
a53f55d8 PA |
4623 | @item int gdbarch_fp0_regnum (@var{gdbarch}) |
4624 | @findex gdbarch_fp0_regnum | |
4625 | This function returns the number of the first floating point register, | |
4626 | if the machine has such registers. Otherwise, it returns -1. | |
4627 | ||
4a9bb1df UW |
4628 | @item CORE_ADDR gdbarch_decr_pc_after_break (@var{gdbarch}) |
4629 | @findex gdbarch_decr_pc_after_break | |
4630 | This function shall return the amount by which to decrement the PC after the | |
c906108c | 4631 | program encounters a breakpoint. This is often the number of bytes in |
56caf160 | 4632 | @code{BREAKPOINT}, though not always. For most targets this value will be 0. |
c906108c | 4633 | |
56caf160 EZ |
4634 | @item DISABLE_UNSETTABLE_BREAK (@var{addr}) |
4635 | @findex DISABLE_UNSETTABLE_BREAK | |
c906108c SS |
4636 | If defined, this should evaluate to 1 if @var{addr} is in a shared |
4637 | library in which breakpoints cannot be set and so should be disabled. | |
4638 | ||
4a9bb1df UW |
4639 | @item int gdbarch_dwarf2_reg_to_regnum (@var{gdbarch}, @var{dwarf2_regnr}) |
4640 | @findex gdbarch_dwarf2_reg_to_regnum | |
4641 | Convert DWARF2 register number @var{dwarf2_regnr} into @value{GDBN} regnum. | |
4642 | If not defined, no conversion will be performed. | |
0dcedd82 | 4643 | |
4a9bb1df UW |
4644 | @item int gdbarch_ecoff_reg_to_regnum (@var{gdbarch}, @var{ecoff_regnr}) |
4645 | @findex gdbarch_ecoff_reg_to_regnum | |
4646 | Convert ECOFF register number @var{ecoff_regnr} into @value{GDBN} regnum. If | |
4647 | not defined, no conversion will be performed. | |
c906108c | 4648 | |
c906108c | 4649 | @item GCC_COMPILED_FLAG_SYMBOL |
56caf160 EZ |
4650 | @itemx GCC2_COMPILED_FLAG_SYMBOL |
4651 | @findex GCC2_COMPILED_FLAG_SYMBOL | |
4652 | @findex GCC_COMPILED_FLAG_SYMBOL | |
4653 | If defined, these are the names of the symbols that @value{GDBN} will | |
4654 | look for to detect that GCC compiled the file. The default symbols | |
4655 | are @code{gcc_compiled.} and @code{gcc2_compiled.}, | |
4656 | respectively. (Currently only defined for the Delta 68.) | |
c906108c | 4657 | |
4a9bb1df UW |
4658 | @item gdbarch_get_longjmp_target |
4659 | @findex gdbarch_get_longjmp_target | |
1f70da6a SS |
4660 | This function determines the target PC address that @code{longjmp} |
4661 | will jump to, assuming that we have just stopped at a @code{longjmp} | |
4662 | breakpoint. It takes a @code{CORE_ADDR *} as argument, and stores the | |
4663 | target PC value through this pointer. It examines the current state | |
4664 | of the machine as needed, typically by using a manually-determined | |
587afa38 | 4665 | offset into the @code{jmp_buf}. (While we might like to get the offset |
1f70da6a SS |
4666 | from the target's @file{jmpbuf.h}, that header file cannot be assumed |
4667 | to be available when building a cross-debugger.) | |
c906108c | 4668 | |
268e2188 AC |
4669 | @item DEPRECATED_IBM6000_TARGET |
4670 | @findex DEPRECATED_IBM6000_TARGET | |
4671 | Shows that we are configured for an IBM RS/6000 system. This | |
c906108c | 4672 | conditional should be eliminated (FIXME) and replaced by |
1f70da6a | 4673 | feature-specific macros. It was introduced in haste and we are |
c906108c SS |
4674 | repenting at leisure. |
4675 | ||
9742079a EZ |
4676 | @item I386_USE_GENERIC_WATCHPOINTS |
4677 | An x86-based target can define this to use the generic x86 watchpoint | |
4678 | support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}. | |
4679 | ||
4a9bb1df | 4680 | @item gdbarch_in_function_epilogue_p (@var{gdbarch}, @var{addr}) |
9e5abb06 | 4681 | @findex gdbarch_in_function_epilogue_p |
4a9bb1df | 4682 | Returns non-zero if the given @var{addr} is in the epilogue of a function. |
9e5abb06 CV |
4683 | The epilogue of a function is defined as the part of a function where |
4684 | the stack frame of the function already has been destroyed up to the | |
4685 | final `return from function call' instruction. | |
4686 | ||
4a9bb1df UW |
4687 | @item int gdbarch_in_solib_return_trampoline (@var{gdbarch}, @var{pc}, @var{name}) |
4688 | @findex gdbarch_in_solib_return_trampoline | |
4689 | Define this function to return nonzero if the program is stopped in the | |
c906108c SS |
4690 | trampoline that returns from a shared library. |
4691 | ||
cfd8ab24 SS |
4692 | @item target_so_ops.in_dynsym_resolve_code (@var{pc}) |
4693 | @findex in_dynsym_resolve_code | |
4a9bb1df | 4694 | Define this to return nonzero if the program is stopped in the |
d4f3574e SS |
4695 | dynamic linker. |
4696 | ||
56caf160 EZ |
4697 | @item SKIP_SOLIB_RESOLVER (@var{pc}) |
4698 | @findex SKIP_SOLIB_RESOLVER | |
d4f3574e SS |
4699 | Define this to evaluate to the (nonzero) address at which execution |
4700 | should continue to get past the dynamic linker's symbol resolution | |
4701 | function. A zero value indicates that it is not important or necessary | |
4702 | to set a breakpoint to get through the dynamic linker and that single | |
4703 | stepping will suffice. | |
4704 | ||
4a9bb1df UW |
4705 | @item CORE_ADDR gdbarch_integer_to_address (@var{gdbarch}, @var{type}, @var{buf}) |
4706 | @findex gdbarch_integer_to_address | |
fc0c74b1 AC |
4707 | @cindex converting integers to addresses |
4708 | Define this when the architecture needs to handle non-pointer to address | |
4709 | conversions specially. Converts that value to an address according to | |
4710 | the current architectures conventions. | |
4711 | ||
4712 | @emph{Pragmatics: When the user copies a well defined expression from | |
4713 | their source code and passes it, as a parameter, to @value{GDBN}'s | |
4714 | @code{print} command, they should get the same value as would have been | |
4715 | computed by the target program. Any deviation from this rule can cause | |
4716 | major confusion and annoyance, and needs to be justified carefully. In | |
4717 | other words, @value{GDBN} doesn't really have the freedom to do these | |
4718 | conversions in clever and useful ways. It has, however, been pointed | |
4719 | out that users aren't complaining about how @value{GDBN} casts integers | |
4720 | to pointers; they are complaining that they can't take an address from a | |
4721 | disassembly listing and give it to @code{x/i}. Adding an architecture | |
4a9bb1df | 4722 | method like @code{gdbarch_integer_to_address} certainly makes it possible for |
fc0c74b1 AC |
4723 | @value{GDBN} to ``get it right'' in all circumstances.} |
4724 | ||
4725 | @xref{Target Architecture Definition, , Pointers Are Not Always | |
4726 | Addresses}. | |
4727 | ||
4a9bb1df UW |
4728 | @item CORE_ADDR gdbarch_pointer_to_address (@var{gdbarch}, @var{type}, @var{buf}) |
4729 | @findex gdbarch_pointer_to_address | |
93e79dbd JB |
4730 | Assume that @var{buf} holds a pointer of type @var{type}, in the |
4731 | appropriate format for the current architecture. Return the byte | |
4732 | address the pointer refers to. | |
4733 | @xref{Target Architecture Definition, , Pointers Are Not Always Addresses}. | |
4734 | ||
4a9bb1df UW |
4735 | @item void gdbarch_register_to_value(@var{gdbarch}, @var{frame}, @var{regnum}, @var{type}, @var{fur}) |
4736 | @findex gdbarch_register_to_value | |
13d01224 AC |
4737 | Convert the raw contents of register @var{regnum} into a value of type |
4738 | @var{type}. | |
4281a42e | 4739 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
9fb4dd36 | 4740 | |
9fb4dd36 | 4741 | @item REGISTER_CONVERT_TO_VIRTUAL(@var{reg}, @var{type}, @var{from}, @var{to}) |
56caf160 | 4742 | @findex REGISTER_CONVERT_TO_VIRTUAL |
9fb4dd36 | 4743 | Convert the value of register @var{reg} from its raw form to its virtual |
4281a42e | 4744 | form. |
13d01224 | 4745 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
9fb4dd36 JB |
4746 | |
4747 | @item REGISTER_CONVERT_TO_RAW(@var{type}, @var{reg}, @var{from}, @var{to}) | |
56caf160 | 4748 | @findex REGISTER_CONVERT_TO_RAW |
9fb4dd36 | 4749 | Convert the value of register @var{reg} from its virtual form to its raw |
4281a42e | 4750 | form. |
13d01224 | 4751 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
9fb4dd36 | 4752 | |
0ab4b752 MK |
4753 | @item const struct regset *regset_from_core_section (struct gdbarch * @var{gdbarch}, const char * @var{sect_name}, size_t @var{sect_size}) |
4754 | @findex regset_from_core_section | |
4755 | Return the appropriate register set for a core file section with name | |
4756 | @var{sect_name} and size @var{sect_size}. | |
4757 | ||
b0ed3589 | 4758 | @item SOFTWARE_SINGLE_STEP_P() |
56caf160 | 4759 | @findex SOFTWARE_SINGLE_STEP_P |
c906108c | 4760 | Define this as 1 if the target does not have a hardware single-step |
56caf160 | 4761 | mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined. |
c906108c | 4762 | |
d3e8051b | 4763 | @item SOFTWARE_SINGLE_STEP(@var{signal}, @var{insert_breakpoints_p}) |
56caf160 EZ |
4764 | @findex SOFTWARE_SINGLE_STEP |
4765 | A function that inserts or removes (depending on | |
d3e8051b | 4766 | @var{insert_breakpoints_p}) breakpoints at each possible destinations of |
587afa38 | 4767 | the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c} |
c906108c SS |
4768 | for examples. |
4769 | ||
e35879db UW |
4770 | @item set_gdbarch_sofun_address_maybe_missing (@var{gdbarch}, @var{set}) |
4771 | @findex set_gdbarch_sofun_address_maybe_missing | |
4772 | Somebody clever observed that, the more actual addresses you have in the | |
4773 | debug information, the more time the linker has to spend relocating | |
4774 | them. So whenever there's some other way the debugger could find the | |
4775 | address it needs, you should omit it from the debug info, to make | |
4776 | linking faster. | |
4777 | ||
4778 | Calling @code{set_gdbarch_sofun_address_maybe_missing} with a non-zero | |
4779 | argument @var{set} indicates that a particular set of hacks of this sort | |
4780 | are in use, affecting @code{N_SO} and @code{N_FUN} entries in stabs-format | |
4781 | debugging information. @code{N_SO} stabs mark the beginning and ending | |
4782 | addresses of compilation units in the text segment. @code{N_FUN} stabs | |
4783 | mark the starts and ends of functions. | |
4784 | ||
4785 | In this case, @value{GDBN} assumes two things: | |
4786 | ||
4787 | @itemize @bullet | |
4788 | @item | |
4789 | @code{N_FUN} stabs have an address of zero. Instead of using those | |
4790 | addresses, you should find the address where the function starts by | |
4791 | taking the function name from the stab, and then looking that up in the | |
4792 | minsyms (the linker/assembler symbol table). In other words, the stab | |
4793 | has the name, and the linker/assembler symbol table is the only place | |
4794 | that carries the address. | |
4795 | ||
4796 | @item | |
4797 | @code{N_SO} stabs have an address of zero, too. You just look at the | |
4798 | @code{N_FUN} stabs that appear before and after the @code{N_SO} stab, and | |
4799 | guess the starting and ending addresses of the compilation unit from them. | |
4800 | @end itemize | |
4801 | ||
4a9bb1df UW |
4802 | @item int gdbarch_stabs_argument_has_addr (@var{gdbarch}, @var{type}) |
4803 | @findex gdbarch_stabs_argument_has_addr | |
4a9bb1df UW |
4804 | @anchor{gdbarch_stabs_argument_has_addr} Define this function to return |
4805 | nonzero if a function argument of type @var{type} is passed by reference | |
4806 | instead of value. | |
a38c9fe6 | 4807 | |
4a9bb1df UW |
4808 | @item CORE_ADDR gdbarch_push_dummy_call (@var{gdbarch}, @var{function}, @var{regcache}, @var{bp_addr}, @var{nargs}, @var{args}, @var{sp}, @var{struct_return}, @var{struct_addr}) |
4809 | @findex gdbarch_push_dummy_call | |
4a9bb1df UW |
4810 | @anchor{gdbarch_push_dummy_call} Define this to push the dummy frame's call to |
4811 | the inferior function onto the stack. In addition to pushing @var{nargs}, the | |
4812 | code should push @var{struct_addr} (when @var{struct_return} is non-zero), and | |
121c73f3 | 4813 | the return address (@var{bp_addr}, in inferior's PC register encoding). |
c906108c | 4814 | |
86fe4aaa | 4815 | @var{function} is a pointer to a @code{struct value}; on architectures that use |
d4b6d575 RC |
4816 | function descriptors, this contains the function descriptor value. |
4817 | ||
b24da7d0 | 4818 | Returns the updated top-of-stack pointer. |
b81774d8 | 4819 | |
4a9bb1df UW |
4820 | @item CORE_ADDR gdbarch_push_dummy_code (@var{gdbarch}, @var{sp}, @var{funaddr}, @var{using_gcc}, @var{args}, @var{nargs}, @var{value_type}, @var{real_pc}, @var{bp_addr}, @var{regcache}) |
4821 | @findex gdbarch_push_dummy_code | |
4822 | @anchor{gdbarch_push_dummy_code} Given a stack based call dummy, push the | |
7043d8dc AC |
4823 | instruction sequence (including space for a breakpoint) to which the |
4824 | called function should return. | |
4825 | ||
4826 | Set @var{bp_addr} to the address at which the breakpoint instruction | |
121c73f3 JK |
4827 | should be inserted (in inferior's PC register encoding), @var{real_pc} to the |
4828 | resume address when starting the call sequence, and return the updated | |
4829 | inner-most stack address. | |
7043d8dc AC |
4830 | |
4831 | By default, the stack is grown sufficient to hold a frame-aligned | |
4832 | (@pxref{frame_align}) breakpoint, @var{bp_addr} is set to the address | |
121c73f3 JK |
4833 | reserved for that breakpoint (in inferior's PC register encoding), and |
4834 | @var{real_pc} set to @var{funaddr}. | |
7043d8dc | 4835 | |
1f70da6a | 4836 | This method replaces @w{@code{gdbarch_call_dummy_location (@var{gdbarch})}}. |
7043d8dc | 4837 | |
4a9bb1df UW |
4838 | @item int gdbarch_sdb_reg_to_regnum (@var{gdbarch}, @var{sdb_regnr}) |
4839 | @findex gdbarch_sdb_reg_to_regnum | |
4840 | Use this function to convert sdb register @var{sdb_regnr} into @value{GDBN} | |
4841 | regnum. If not defined, no conversion will be done. | |
c906108c | 4842 | |
963e2bb7 | 4843 | @item enum return_value_convention gdbarch_return_value (struct gdbarch *@var{gdbarch}, struct type *@var{valtype}, struct regcache *@var{regcache}, void *@var{readbuf}, const void *@var{writebuf}) |
92ad9cd9 AC |
4844 | @findex gdbarch_return_value |
4845 | @anchor{gdbarch_return_value} Given a function with a return-value of | |
4846 | type @var{rettype}, return which return-value convention that function | |
4847 | would use. | |
4848 | ||
4849 | @value{GDBN} currently recognizes two function return-value conventions: | |
4850 | @code{RETURN_VALUE_REGISTER_CONVENTION} where the return value is found | |
4851 | in registers; and @code{RETURN_VALUE_STRUCT_CONVENTION} where the return | |
4852 | value is found in memory and the address of that memory location is | |
4853 | passed in as the function's first parameter. | |
4854 | ||
963e2bb7 AC |
4855 | If the register convention is being used, and @var{writebuf} is |
4856 | non-@code{NULL}, also copy the return-value in @var{writebuf} into | |
92ad9cd9 AC |
4857 | @var{regcache}. |
4858 | ||
963e2bb7 | 4859 | If the register convention is being used, and @var{readbuf} is |
92ad9cd9 | 4860 | non-@code{NULL}, also copy the return value from @var{regcache} into |
963e2bb7 | 4861 | @var{readbuf} (@var{regcache} contains a copy of the registers from the |
92ad9cd9 AC |
4862 | just returned function). |
4863 | ||
92ad9cd9 AC |
4864 | @emph{Maintainer note: This method replaces separate predicate, extract, |
4865 | store methods. By having only one method, the logic needed to determine | |
4866 | the return-value convention need only be implemented in one place. If | |
4867 | @value{GDBN} were written in an @sc{oo} language, this method would | |
4868 | instead return an object that knew how to perform the register | |
4869 | return-value extract and store.} | |
4870 | ||
4871 | @emph{Maintainer note: This method does not take a @var{gcc_p} | |
4872 | parameter, and such a parameter should not be added. If an architecture | |
4873 | that requires per-compiler or per-function information be identified, | |
4874 | then the replacement of @var{rettype} with @code{struct value} | |
d3e8051b | 4875 | @var{function} should be pursued.} |
92ad9cd9 AC |
4876 | |
4877 | @emph{Maintainer note: The @var{regcache} parameter limits this methods | |
4878 | to the inner most frame. While replacing @var{regcache} with a | |
4879 | @code{struct frame_info} @var{frame} parameter would remove that | |
4880 | limitation there has yet to be a demonstrated need for such a change.} | |
4881 | ||
4a9bb1df UW |
4882 | @item void gdbarch_skip_permanent_breakpoint (@var{gdbarch}, @var{regcache}) |
4883 | @findex gdbarch_skip_permanent_breakpoint | |
25822942 | 4884 | Advance the inferior's PC past a permanent breakpoint. @value{GDBN} normally |
c2c6d25f JM |
4885 | steps over a breakpoint by removing it, stepping one instruction, and |
4886 | re-inserting the breakpoint. However, permanent breakpoints are | |
4887 | hardwired into the inferior, and can't be removed, so this strategy | |
4a9bb1df UW |
4888 | doesn't work. Calling @code{gdbarch_skip_permanent_breakpoint} adjusts the |
4889 | processor's state so that execution will resume just after the breakpoint. | |
4890 | This function does the right thing even when the breakpoint is in the delay slot | |
c2c6d25f JM |
4891 | of a branch or jump. |
4892 | ||
4a9bb1df UW |
4893 | @item CORE_ADDR gdbarch_skip_trampoline_code (@var{gdbarch}, @var{frame}, @var{pc}) |
4894 | @findex gdbarch_skip_trampoline_code | |
c906108c | 4895 | If the target machine has trampoline code that sits between callers and |
4a9bb1df | 4896 | the functions being called, then define this function to return a new PC |
c906108c SS |
4897 | that is at the start of the real function. |
4898 | ||
1f70da6a SS |
4899 | @item int gdbarch_deprecated_fp_regnum (@var{gdbarch}) |
4900 | @findex gdbarch_deprecated_fp_regnum | |
4901 | If the frame pointer is in a register, use this function to return the | |
4902 | number of that register. | |
4903 | ||
4a9bb1df UW |
4904 | @item int gdbarch_stab_reg_to_regnum (@var{gdbarch}, @var{stab_regnr}) |
4905 | @findex gdbarch_stab_reg_to_regnum | |
4906 | Use this function to convert stab register @var{stab_regnr} into @value{GDBN} | |
4907 | regnum. If not defined, no conversion will be done. | |
4908 | ||
c906108c | 4909 | @item TARGET_CHAR_BIT |
56caf160 | 4910 | @findex TARGET_CHAR_BIT |
c906108c SS |
4911 | Number of bits in a char; defaults to 8. |
4912 | ||
4a9bb1df UW |
4913 | @item int gdbarch_char_signed (@var{gdbarch}) |
4914 | @findex gdbarch_char_signed | |
c3d3ce5b JB |
4915 | Non-zero if @code{char} is normally signed on this architecture; zero if |
4916 | it should be unsigned. | |
4917 | ||
4918 | The ISO C standard requires the compiler to treat @code{char} as | |
4919 | equivalent to either @code{signed char} or @code{unsigned char}; any | |
4920 | character in the standard execution set is supposed to be positive. | |
4921 | Most compilers treat @code{char} as signed, but @code{char} is unsigned | |
4922 | on the IBM S/390, RS6000, and PowerPC targets. | |
4923 | ||
4a9bb1df UW |
4924 | @item int gdbarch_double_bit (@var{gdbarch}) |
4925 | @findex gdbarch_double_bit | |
4926 | Number of bits in a double float; defaults to @w{@code{8 * TARGET_CHAR_BIT}}. | |
c906108c | 4927 | |
4a9bb1df UW |
4928 | @item int gdbarch_float_bit (@var{gdbarch}) |
4929 | @findex gdbarch_float_bit | |
4930 | Number of bits in a float; defaults to @w{@code{4 * TARGET_CHAR_BIT}}. | |
ac9a91a7 | 4931 | |
4a9bb1df UW |
4932 | @item int gdbarch_int_bit (@var{gdbarch}) |
4933 | @findex gdbarch_int_bit | |
4934 | Number of bits in an integer; defaults to @w{@code{4 * TARGET_CHAR_BIT}}. | |
c906108c | 4935 | |
4a9bb1df UW |
4936 | @item int gdbarch_long_bit (@var{gdbarch}) |
4937 | @findex gdbarch_long_bit | |
4938 | Number of bits in a long integer; defaults to @w{@code{4 * TARGET_CHAR_BIT}}. | |
c906108c | 4939 | |
4a9bb1df UW |
4940 | @item int gdbarch_long_double_bit (@var{gdbarch}) |
4941 | @findex gdbarch_long_double_bit | |
c906108c | 4942 | Number of bits in a long double float; |
4a9bb1df UW |
4943 | defaults to @w{@code{2 * gdbarch_double_bit (@var{gdbarch})}}. |
4944 | ||
4945 | @item int gdbarch_long_long_bit (@var{gdbarch}) | |
4946 | @findex gdbarch_long_long_bit | |
4947 | Number of bits in a long long integer; defaults to | |
4948 | @w{@code{2 * gdbarch_long_bit (@var{gdbarch})}}. | |
4949 | ||
4950 | @item int gdbarch_ptr_bit (@var{gdbarch}) | |
4951 | @findex gdbarch_ptr_bit | |
4952 | Number of bits in a pointer; defaults to | |
4953 | @w{@code{gdbarch_int_bit (@var{gdbarch})}}. | |
4954 | ||
4955 | @item int gdbarch_short_bit (@var{gdbarch}) | |
4956 | @findex gdbarch_short_bit | |
4957 | Number of bits in a short integer; defaults to @w{@code{2 * TARGET_CHAR_BIT}}. | |
4958 | ||
4a9bb1df UW |
4959 | @item void gdbarch_virtual_frame_pointer (@var{gdbarch}, @var{pc}, @var{frame_regnum}, @var{frame_offset}) |
4960 | @findex gdbarch_virtual_frame_pointer | |
1f70da6a SS |
4961 | Returns a @code{(@var{register}, @var{offset})} pair representing the virtual |
4962 | frame pointer in use at the code address @var{pc}. If virtual frame | |
4963 | pointers are not used, a default definition simply returns | |
4964 | @code{gdbarch_deprecated_fp_regnum} (or @code{gdbarch_sp_regnum}, if | |
4965 | no frame pointer is defined), with an offset of zero. | |
4966 | ||
587afa38 EZ |
4967 | @c need to explain virtual frame pointers, they are recorded in agent |
4968 | @c expressions for tracepoints | |
c906108c | 4969 | |
9742079a EZ |
4970 | @item TARGET_HAS_HARDWARE_WATCHPOINTS |
4971 | If non-zero, the target has support for hardware-assisted | |
4972 | watchpoints. @xref{Algorithms, watchpoints}, for more details and | |
4973 | other related macros. | |
4974 | ||
4a9bb1df UW |
4975 | @item int gdbarch_print_insn (@var{gdbarch}, @var{vma}, @var{info}) |
4976 | @findex gdbarch_print_insn | |
7ccaa899 | 4977 | This is the function used by @value{GDBN} to print an assembly |
4a9bb1df | 4978 | instruction. It prints the instruction at address @var{vma} in |
1f70da6a SS |
4979 | debugged memory and returns the length of the instruction, in bytes. |
4980 | This usually points to a function in the @code{opcodes} library | |
4981 | (@pxref{Support Libraries, ,Opcodes}). @var{info} is a structure (of | |
4982 | type @code{disassemble_info}) defined in the header file | |
4983 | @file{include/dis-asm.h}, and used to pass information to the | |
4984 | instruction decoding routine. | |
7ccaa899 | 4985 | |
669fac23 DJ |
4986 | @item frame_id gdbarch_dummy_id (@var{gdbarch}, @var{frame}) |
4987 | @findex gdbarch_dummy_id | |
4988 | @anchor{gdbarch_dummy_id} Given @var{frame} return a @w{@code{struct | |
4a9bb1df | 4989 | frame_id}} that uniquely identifies an inferior function call's dummy |
b24da7d0 | 4990 | frame. The value returned must match the dummy frame stack value |
669fac23 | 4991 | previously saved by @code{call_function_by_hand}. |
6314f104 | 4992 | |
4a9bb1df UW |
4993 | @item void gdbarch_value_to_register (@var{gdbarch}, @var{frame}, @var{type}, @var{buf}) |
4994 | @findex gdbarch_value_to_register | |
4995 | Convert a value of type @var{type} into the raw contents of a register. | |
13d01224 AC |
4996 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
4997 | ||
c906108c SS |
4998 | @end table |
4999 | ||
5000 | Motorola M68K target conditionals. | |
5001 | ||
56caf160 | 5002 | @ftable @code |
c906108c SS |
5003 | @item BPT_VECTOR |
5004 | Define this to be the 4-bit location of the breakpoint trap vector. If | |
5005 | not defined, it will default to @code{0xf}. | |
5006 | ||
5007 | @item REMOTE_BPT_VECTOR | |
5008 | Defaults to @code{1}. | |
a23a7bf1 | 5009 | |
56caf160 | 5010 | @end ftable |
c906108c | 5011 | |
b6fd0dfb | 5012 | @node Adding a New Target |
c906108c SS |
5013 | @section Adding a New Target |
5014 | ||
56caf160 | 5015 | @cindex adding a target |
af6c57ea | 5016 | The following files add a target to @value{GDBN}: |
c906108c SS |
5017 | |
5018 | @table @file | |
f0323ca0 | 5019 | @cindex target dependent files |
c906108c | 5020 | |
c906108c SS |
5021 | @item gdb/@var{ttt}-tdep.c |
5022 | Contains any miscellaneous code required for this target machine. On | |
1f70da6a | 5023 | some machines it doesn't exist at all. |
c906108c | 5024 | |
af6c57ea AC |
5025 | @item gdb/@var{arch}-tdep.c |
5026 | @itemx gdb/@var{arch}-tdep.h | |
1f70da6a SS |
5027 | This is required to describe the basic layout of the target machine's |
5028 | processor chip (registers, stack, etc.). It can be shared among many | |
5029 | targets that use the same processor architecture. | |
af6c57ea | 5030 | |
c906108c SS |
5031 | @end table |
5032 | ||
1f70da6a SS |
5033 | (Target header files such as |
5034 | @file{gdb/config/@var{arch}/tm-@var{ttt}.h}, | |
5035 | @file{gdb/config/@var{arch}/tm-@var{arch}.h}, and | |
5036 | @file{config/tm-@var{os}.h} are no longer used.) | |
c906108c | 5037 | |
587afa38 EZ |
5038 | @findex _initialize_@var{arch}_tdep |
5039 | A @value{GDBN} description for a new architecture, arch is created by | |
5040 | defining a global function @code{_initialize_@var{arch}_tdep}, by | |
5041 | convention in the source file @file{@var{arch}-tdep.c}. For | |
5042 | example, in the case of the OpenRISC 1000, this function is called | |
5043 | @code{_initialize_or1k_tdep} and is found in the file | |
5044 | @file{or1k-tdep.c}. | |
5045 | ||
5046 | The object file resulting from compiling this source file, which will | |
5047 | contain the implementation of the | |
5048 | @code{_initialize_@var{arch}_tdep} function is specified in the | |
5049 | @value{GDBN} @file{configure.tgt} file, which includes a large case | |
5050 | statement pattern matching against the @code{--target} option of the | |
5051 | @kbd{configure} script. | |
5052 | ||
5053 | @quotation | |
5054 | @emph{Note:} If the architecture requires multiple source files, the | |
5055 | corresponding binaries should be included in | |
5056 | @file{configure.tgt}. However if there are header files, the | |
5057 | dependencies on these will not be picked up from the entries in | |
5058 | @file{configure.tgt}. The @file{Makefile.in} file will need extending to | |
5059 | show these dependencies. | |
5060 | @end quotation | |
5061 | ||
5062 | @findex gdbarch_register | |
5063 | A new struct gdbarch, defining the new architecture, is created within | |
5064 | the @code{_initialize_@var{arch}_tdep} function by calling | |
5065 | @code{gdbarch_register}: | |
5066 | ||
5067 | @smallexample | |
5068 | void gdbarch_register (enum bfd_architecture architecture, | |
5069 | gdbarch_init_ftype *init_func, | |
5070 | gdbarch_dump_tdep_ftype *tdep_dump_func); | |
5071 | @end smallexample | |
5072 | ||
5073 | This function has been described fully in an earlier | |
5074 | section. @xref{How an Architecture is Represented, , How an | |
5075 | Architecture is Represented}. | |
5076 | ||
5077 | The new @code{@w{struct gdbarch}} should contain implementations of | |
5078 | the necessary functions (described in the previous sections) to | |
5079 | describe the basic layout of the target machine's processor chip | |
5080 | (registers, stack, etc.). It can be shared among many targets that use | |
5081 | the same processor architecture. | |
5082 | ||
123dc839 DJ |
5083 | @node Target Descriptions |
5084 | @chapter Target Descriptions | |
5085 | @cindex target descriptions | |
5086 | ||
5087 | The target architecture definition (@pxref{Target Architecture Definition}) | |
5088 | contains @value{GDBN}'s hard-coded knowledge about an architecture. For | |
5089 | some platforms, it is handy to have more flexible knowledge about a specific | |
5090 | instance of the architecture---for instance, a processor or development board. | |
5091 | @dfn{Target descriptions} provide a mechanism for the user to tell @value{GDBN} | |
5092 | more about what their target supports, or for the target to tell @value{GDBN} | |
5093 | directly. | |
5094 | ||
5095 | For details on writing, automatically supplying, and manually selecting | |
5096 | target descriptions, see @ref{Target Descriptions, , , gdb, | |
5097 | Debugging with @value{GDBN}}. This section will cover some related | |
5098 | topics about the @value{GDBN} internals. | |
5099 | ||
5100 | @menu | |
5101 | * Target Descriptions Implementation:: | |
5102 | * Adding Target Described Register Support:: | |
5103 | @end menu | |
5104 | ||
5105 | @node Target Descriptions Implementation | |
5106 | @section Target Descriptions Implementation | |
5107 | @cindex target descriptions, implementation | |
5108 | ||
5109 | Before @value{GDBN} connects to a new target, or runs a new program on | |
5110 | an existing target, it discards any existing target description and | |
5111 | reverts to a default gdbarch. Then, after connecting, it looks for a | |
5112 | new target description by calling @code{target_find_description}. | |
5113 | ||
5114 | A description may come from a user specified file (XML), the remote | |
5115 | @samp{qXfer:features:read} packet (also XML), or from any custom | |
5116 | @code{to_read_description} routine in the target vector. For instance, | |
5117 | the remote target supports guessing whether a MIPS target is 32-bit or | |
5118 | 64-bit based on the size of the @samp{g} packet. | |
5119 | ||
5120 | If any target description is found, @value{GDBN} creates a new gdbarch | |
5121 | incorporating the description by calling @code{gdbarch_update_p}. Any | |
5122 | @samp{<architecture>} element is handled first, to determine which | |
5123 | architecture's gdbarch initialization routine is called to create the | |
5124 | new architecture. Then the initialization routine is called, and has | |
5125 | a chance to adjust the constructed architecture based on the contents | |
5126 | of the target description. For instance, it can recognize any | |
5127 | properties set by a @code{to_read_description} routine. Also | |
5128 | see @ref{Adding Target Described Register Support}. | |
5129 | ||
5130 | @node Adding Target Described Register Support | |
5131 | @section Adding Target Described Register Support | |
5132 | @cindex target descriptions, adding register support | |
5133 | ||
5134 | Target descriptions can report additional registers specific to an | |
5135 | instance of the target. But it takes a little work in the architecture | |
5136 | specific routines to support this. | |
5137 | ||
5138 | A target description must either have no registers or a complete | |
5139 | set---this avoids complexity in trying to merge standard registers | |
5140 | with the target defined registers. It is the architecture's | |
5141 | responsibility to validate that a description with registers has | |
5142 | everything it needs. To keep architecture code simple, the same | |
5143 | mechanism is used to assign fixed internal register numbers to | |
5144 | standard registers. | |
5145 | ||
5146 | If @code{tdesc_has_registers} returns 1, the description contains | |
5147 | registers. The architecture's @code{gdbarch_init} routine should: | |
5148 | ||
5149 | @itemize @bullet | |
5150 | ||
5151 | @item | |
5152 | Call @code{tdesc_data_alloc} to allocate storage, early, before | |
5153 | searching for a matching gdbarch or allocating a new one. | |
5154 | ||
5155 | @item | |
5156 | Use @code{tdesc_find_feature} to locate standard features by name. | |
5157 | ||
5158 | @item | |
5159 | Use @code{tdesc_numbered_register} and @code{tdesc_numbered_register_choices} | |
5160 | to locate the expected registers in the standard features. | |
5161 | ||
5162 | @item | |
5163 | Return @code{NULL} if a required feature is missing, or if any standard | |
5164 | feature is missing expected registers. This will produce a warning that | |
5165 | the description was incomplete. | |
5166 | ||
5167 | @item | |
5168 | Free the allocated data before returning, unless @code{tdesc_use_registers} | |
5169 | is called. | |
5170 | ||
5171 | @item | |
5172 | Call @code{set_gdbarch_num_regs} as usual, with a number higher than any | |
5173 | fixed number passed to @code{tdesc_numbered_register}. | |
5174 | ||
5175 | @item | |
5176 | Call @code{tdesc_use_registers} after creating a new gdbarch, before | |
5177 | returning it. | |
5178 | ||
5179 | @end itemize | |
5180 | ||
5181 | After @code{tdesc_use_registers} has been called, the architecture's | |
5182 | @code{register_name}, @code{register_type}, and @code{register_reggroup_p} | |
5183 | routines will not be called; that information will be taken from | |
5184 | the target description. @code{num_regs} may be increased to account | |
5185 | for any additional registers in the description. | |
5186 | ||
5187 | Pseudo-registers require some extra care: | |
5188 | ||
5189 | @itemize @bullet | |
5190 | ||
5191 | @item | |
5192 | Using @code{tdesc_numbered_register} allows the architecture to give | |
5193 | constant register numbers to standard architectural registers, e.g.@: | |
5194 | as an @code{enum} in @file{@var{arch}-tdep.h}. But because | |
5195 | pseudo-registers are always numbered above @code{num_regs}, | |
5196 | which may be increased by the description, constant numbers | |
5197 | can not be used for pseudos. They must be numbered relative to | |
5198 | @code{num_regs} instead. | |
5199 | ||
5200 | @item | |
5201 | The description will not describe pseudo-registers, so the | |
5202 | architecture must call @code{set_tdesc_pseudo_register_name}, | |
5203 | @code{set_tdesc_pseudo_register_type}, and | |
5204 | @code{set_tdesc_pseudo_register_reggroup_p} to supply routines | |
5205 | describing pseudo registers. These routines will be passed | |
5206 | internal register numbers, so the same routines used for the | |
5207 | gdbarch equivalents are usually suitable. | |
5208 | ||
5209 | @end itemize | |
5210 | ||
5211 | ||
c906108c SS |
5212 | @node Target Vector Definition |
5213 | ||
5214 | @chapter Target Vector Definition | |
56caf160 | 5215 | @cindex target vector |
c906108c | 5216 | |
56caf160 EZ |
5217 | The target vector defines the interface between @value{GDBN}'s |
5218 | abstract handling of target systems, and the nitty-gritty code that | |
5219 | actually exercises control over a process or a serial port. | |
5220 | @value{GDBN} includes some 30-40 different target vectors; however, | |
5221 | each configuration of @value{GDBN} includes only a few of them. | |
c906108c | 5222 | |
52bb452f DJ |
5223 | @menu |
5224 | * Managing Execution State:: | |
5225 | * Existing Targets:: | |
5226 | @end menu | |
5227 | ||
5228 | @node Managing Execution State | |
5229 | @section Managing Execution State | |
5230 | @cindex execution state | |
5231 | ||
5232 | A target vector can be completely inactive (not pushed on the target | |
5233 | stack), active but not running (pushed, but not connected to a fully | |
5234 | manifested inferior), or completely active (pushed, with an accessible | |
5235 | inferior). Most targets are only completely inactive or completely | |
d3e8051b | 5236 | active, but some support persistent connections to a target even |
52bb452f DJ |
5237 | when the target has exited or not yet started. |
5238 | ||
5239 | For example, connecting to the simulator using @code{target sim} does | |
5240 | not create a running program. Neither registers nor memory are | |
5241 | accessible until @code{run}. Similarly, after @code{kill}, the | |
5242 | program can not continue executing. But in both cases @value{GDBN} | |
5243 | remains connected to the simulator, and target-specific commands | |
5244 | are directed to the simulator. | |
5245 | ||
5246 | A target which only supports complete activation should push itself | |
5247 | onto the stack in its @code{to_open} routine (by calling | |
5248 | @code{push_target}), and unpush itself from the stack in its | |
5249 | @code{to_mourn_inferior} routine (by calling @code{unpush_target}). | |
5250 | ||
5251 | A target which supports both partial and complete activation should | |
5252 | still call @code{push_target} in @code{to_open}, but not call | |
5253 | @code{unpush_target} in @code{to_mourn_inferior}. Instead, it should | |
5254 | call either @code{target_mark_running} or @code{target_mark_exited} | |
5255 | in its @code{to_open}, depending on whether the target is fully active | |
5256 | after connection. It should also call @code{target_mark_running} any | |
5257 | time the inferior becomes fully active (e.g.@: in | |
5258 | @code{to_create_inferior} and @code{to_attach}), and | |
5259 | @code{target_mark_exited} when the inferior becomes inactive (in | |
5260 | @code{to_mourn_inferior}). The target should also make sure to call | |
5261 | @code{target_mourn_inferior} from its @code{to_kill}, to return the | |
5262 | target to inactive state. | |
5263 | ||
5264 | @node Existing Targets | |
5265 | @section Existing Targets | |
5266 | @cindex targets | |
5267 | ||
5268 | @subsection File Targets | |
c906108c SS |
5269 | |
5270 | Both executables and core files have target vectors. | |
5271 | ||
52bb452f | 5272 | @subsection Standard Protocol and Remote Stubs |
c906108c | 5273 | |
587afa38 EZ |
5274 | @value{GDBN}'s file @file{remote.c} talks a serial protocol to code that |
5275 | runs in the target system. @value{GDBN} provides several sample | |
56caf160 | 5276 | @dfn{stubs} that can be integrated into target programs or operating |
587afa38 | 5277 | systems for this purpose; they are named @file{@var{cpu}-stub.c}. Many |
1f70da6a | 5278 | operating systems, embedded targets, emulators, and simulators already |
587afa38 | 5279 | have a @value{GDBN} stub built into them, and maintenance of the remote |
1f70da6a | 5280 | protocol must be careful to preserve compatibility. |
c906108c | 5281 | |
56caf160 EZ |
5282 | The @value{GDBN} user's manual describes how to put such a stub into |
5283 | your target code. What follows is a discussion of integrating the | |
5284 | SPARC stub into a complicated operating system (rather than a simple | |
5285 | program), by Stu Grossman, the author of this stub. | |
c906108c SS |
5286 | |
5287 | The trap handling code in the stub assumes the following upon entry to | |
56caf160 | 5288 | @code{trap_low}: |
c906108c SS |
5289 | |
5290 | @enumerate | |
56caf160 EZ |
5291 | @item |
5292 | %l1 and %l2 contain pc and npc respectively at the time of the trap; | |
c906108c | 5293 | |
56caf160 EZ |
5294 | @item |
5295 | traps are disabled; | |
c906108c | 5296 | |
56caf160 EZ |
5297 | @item |
5298 | you are in the correct trap window. | |
c906108c SS |
5299 | @end enumerate |
5300 | ||
5301 | As long as your trap handler can guarantee those conditions, then there | |
56caf160 | 5302 | is no reason why you shouldn't be able to ``share'' traps with the stub. |
c906108c SS |
5303 | The stub has no requirement that it be jumped to directly from the |
5304 | hardware trap vector. That is why it calls @code{exceptionHandler()}, | |
5305 | which is provided by the external environment. For instance, this could | |
56caf160 | 5306 | set up the hardware traps to actually execute code which calls the stub |
c906108c SS |
5307 | first, and then transfers to its own trap handler. |
5308 | ||
5309 | For the most point, there probably won't be much of an issue with | |
56caf160 | 5310 | ``sharing'' traps, as the traps we use are usually not used by the kernel, |
c906108c SS |
5311 | and often indicate unrecoverable error conditions. Anyway, this is all |
5312 | controlled by a table, and is trivial to modify. The most important | |
5313 | trap for us is for @code{ta 1}. Without that, we can't single step or | |
5314 | do breakpoints. Everything else is unnecessary for the proper operation | |
5315 | of the debugger/stub. | |
5316 | ||
5317 | From reading the stub, it's probably not obvious how breakpoints work. | |
25822942 | 5318 | They are simply done by deposit/examine operations from @value{GDBN}. |
c906108c | 5319 | |
52bb452f | 5320 | @subsection ROM Monitor Interface |
c906108c | 5321 | |
52bb452f | 5322 | @subsection Custom Protocols |
c906108c | 5323 | |
52bb452f | 5324 | @subsection Transport Layer |
c906108c | 5325 | |
52bb452f | 5326 | @subsection Builtin Simulator |
c906108c SS |
5327 | |
5328 | ||
5329 | @node Native Debugging | |
5330 | ||
5331 | @chapter Native Debugging | |
56caf160 | 5332 | @cindex native debugging |
c906108c | 5333 | |
25822942 | 5334 | Several files control @value{GDBN}'s configuration for native support: |
c906108c SS |
5335 | |
5336 | @table @file | |
56caf160 | 5337 | @vindex NATDEPFILES |
c906108c | 5338 | @item gdb/config/@var{arch}/@var{xyz}.mh |
7fd60527 | 5339 | Specifies Makefile fragments needed by a @emph{native} configuration on |
c906108c SS |
5340 | machine @var{xyz}. In particular, this lists the required |
5341 | native-dependent object files, by defining @samp{NATDEPFILES=@dots{}}. | |
5342 | Also specifies the header file which describes native support on | |
5343 | @var{xyz}, by defining @samp{NAT_FILE= nm-@var{xyz}.h}. You can also | |
5344 | define @samp{NAT_CFLAGS}, @samp{NAT_ADD_FILES}, @samp{NAT_CLIBS}, | |
3d0bb823 | 5345 | @samp{NAT_CDEPS}, @samp{NAT_GENERATED_FILES}, etc.; see @file{Makefile.in}. |
c906108c | 5346 | |
7fd60527 AC |
5347 | @emph{Maintainer's note: The @file{.mh} suffix is because this file |
5348 | originally contained @file{Makefile} fragments for hosting @value{GDBN} | |
5349 | on machine @var{xyz}. While the file is no longer used for this | |
937f164b | 5350 | purpose, the @file{.mh} suffix remains. Perhaps someone will |
7fd60527 AC |
5351 | eventually rename these fragments so that they have a @file{.mn} |
5352 | suffix.} | |
5353 | ||
c906108c | 5354 | @item gdb/config/@var{arch}/nm-@var{xyz}.h |
56caf160 | 5355 | (@file{nm.h} is a link to this file, created by @code{configure}). Contains C |
c906108c SS |
5356 | macro definitions describing the native system environment, such as |
5357 | child process control and core file support. | |
5358 | ||
5359 | @item gdb/@var{xyz}-nat.c | |
5360 | Contains any miscellaneous C code required for this native support of | |
5361 | this machine. On some machines it doesn't exist at all. | |
c906108c SS |
5362 | @end table |
5363 | ||
5364 | There are some ``generic'' versions of routines that can be used by | |
5365 | various systems. These can be customized in various ways by macros | |
5366 | defined in your @file{nm-@var{xyz}.h} file. If these routines work for | |
5367 | the @var{xyz} host, you can just include the generic file's name (with | |
5368 | @samp{.o}, not @samp{.c}) in @code{NATDEPFILES}. | |
5369 | ||
5370 | Otherwise, if your machine needs custom support routines, you will need | |
5371 | to write routines that perform the same functions as the generic file. | |
56caf160 | 5372 | Put them into @file{@var{xyz}-nat.c}, and put @file{@var{xyz}-nat.o} |
c906108c SS |
5373 | into @code{NATDEPFILES}. |
5374 | ||
5375 | @table @file | |
c906108c SS |
5376 | @item inftarg.c |
5377 | This contains the @emph{target_ops vector} that supports Unix child | |
5378 | processes on systems which use ptrace and wait to control the child. | |
5379 | ||
5380 | @item procfs.c | |
5381 | This contains the @emph{target_ops vector} that supports Unix child | |
5382 | processes on systems which use /proc to control the child. | |
5383 | ||
5384 | @item fork-child.c | |
56caf160 EZ |
5385 | This does the low-level grunge that uses Unix system calls to do a ``fork |
5386 | and exec'' to start up a child process. | |
c906108c SS |
5387 | |
5388 | @item infptrace.c | |
5389 | This is the low level interface to inferior processes for systems using | |
5390 | the Unix @code{ptrace} call in a vanilla way. | |
c906108c SS |
5391 | @end table |
5392 | ||
c906108c SS |
5393 | @section ptrace |
5394 | ||
5395 | @section /proc | |
5396 | ||
5397 | @section win32 | |
5398 | ||
5399 | @section shared libraries | |
5400 | ||
5401 | @section Native Conditionals | |
56caf160 | 5402 | @cindex native conditionals |
c906108c | 5403 | |
56caf160 EZ |
5404 | When @value{GDBN} is configured and compiled, various macros are |
5405 | defined or left undefined, to control compilation when the host and | |
5406 | target systems are the same. These macros should be defined (or left | |
5407 | undefined) in @file{nm-@var{system}.h}. | |
c906108c | 5408 | |
1f6d4158 AC |
5409 | @table @code |
5410 | ||
9742079a EZ |
5411 | @item I386_USE_GENERIC_WATCHPOINTS |
5412 | An x86-based machine can define this to use the generic x86 watchpoint | |
5413 | support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}. | |
5414 | ||
990f9fe3 | 5415 | @item SOLIB_ADD (@var{filename}, @var{from_tty}, @var{targ}, @var{readsyms}) |
56caf160 | 5416 | @findex SOLIB_ADD |
c906108c | 5417 | Define this to expand into an expression that will cause the symbols in |
587afa38 | 5418 | @var{filename} to be added to @value{GDBN}'s symbol table. If |
990f9fe3 FF |
5419 | @var{readsyms} is zero symbols are not read but any necessary low level |
5420 | processing for @var{filename} is still done. | |
c906108c SS |
5421 | |
5422 | @item SOLIB_CREATE_INFERIOR_HOOK | |
56caf160 | 5423 | @findex SOLIB_CREATE_INFERIOR_HOOK |
c906108c SS |
5424 | Define this to expand into any shared-library-relocation code that you |
5425 | want to be run just after the child process has been forked. | |
5426 | ||
5427 | @item START_INFERIOR_TRAPS_EXPECTED | |
56caf160 EZ |
5428 | @findex START_INFERIOR_TRAPS_EXPECTED |
5429 | When starting an inferior, @value{GDBN} normally expects to trap | |
5430 | twice; once when | |
c906108c SS |
5431 | the shell execs, and once when the program itself execs. If the actual |
5432 | number of traps is something other than 2, then define this macro to | |
5433 | expand into the number expected. | |
5434 | ||
c906108c SS |
5435 | @end table |
5436 | ||
c906108c SS |
5437 | @node Support Libraries |
5438 | ||
5439 | @chapter Support Libraries | |
5440 | ||
5441 | @section BFD | |
56caf160 | 5442 | @cindex BFD library |
c906108c | 5443 | |
25822942 | 5444 | BFD provides support for @value{GDBN} in several ways: |
c906108c SS |
5445 | |
5446 | @table @emph | |
c906108c SS |
5447 | @item identifying executable and core files |
5448 | BFD will identify a variety of file types, including a.out, coff, and | |
5449 | several variants thereof, as well as several kinds of core files. | |
5450 | ||
5451 | @item access to sections of files | |
5452 | BFD parses the file headers to determine the names, virtual addresses, | |
5453 | sizes, and file locations of all the various named sections in files | |
56caf160 EZ |
5454 | (such as the text section or the data section). @value{GDBN} simply |
5455 | calls BFD to read or write section @var{x} at byte offset @var{y} for | |
5456 | length @var{z}. | |
c906108c SS |
5457 | |
5458 | @item specialized core file support | |
5459 | BFD provides routines to determine the failing command name stored in a | |
5460 | core file, the signal with which the program failed, and whether a core | |
56caf160 | 5461 | file matches (i.e.@: could be a core dump of) a particular executable |
c906108c SS |
5462 | file. |
5463 | ||
5464 | @item locating the symbol information | |
25822942 DB |
5465 | @value{GDBN} uses an internal interface of BFD to determine where to find the |
5466 | symbol information in an executable file or symbol-file. @value{GDBN} itself | |
c906108c | 5467 | handles the reading of symbols, since BFD does not ``understand'' debug |
25822942 | 5468 | symbols, but @value{GDBN} uses BFD's cached information to find the symbols, |
c906108c | 5469 | string table, etc. |
c906108c SS |
5470 | @end table |
5471 | ||
5472 | @section opcodes | |
56caf160 | 5473 | @cindex opcodes library |
c906108c | 5474 | |
25822942 | 5475 | The opcodes library provides @value{GDBN}'s disassembler. (It's a separate |
c906108c SS |
5476 | library because it's also used in binutils, for @file{objdump}). |
5477 | ||
5478 | @section readline | |
86f04699 EZ |
5479 | @cindex readline library |
5480 | The @code{readline} library provides a set of functions for use by applications | |
5481 | that allow users to edit command lines as they are typed in. | |
c906108c SS |
5482 | |
5483 | @section libiberty | |
1eb288ea EZ |
5484 | @cindex @code{libiberty} library |
5485 | ||
5486 | The @code{libiberty} library provides a set of functions and features | |
5487 | that integrate and improve on functionality found in modern operating | |
5488 | systems. Broadly speaking, such features can be divided into three | |
5489 | groups: supplemental functions (functions that may be missing in some | |
5490 | environments and operating systems), replacement functions (providing | |
5491 | a uniform and easier to use interface for commonly used standard | |
5492 | functions), and extensions (which provide additional functionality | |
5493 | beyond standard functions). | |
5494 | ||
5495 | @value{GDBN} uses various features provided by the @code{libiberty} | |
5496 | library, for instance the C@t{++} demangler, the @acronym{IEEE} | |
5497 | floating format support functions, the input options parser | |
5498 | @samp{getopt}, the @samp{obstack} extension, and other functions. | |
5499 | ||
5500 | @subsection @code{obstacks} in @value{GDBN} | |
5501 | @cindex @code{obstacks} | |
5502 | ||
5503 | The obstack mechanism provides a convenient way to allocate and free | |
5504 | chunks of memory. Each obstack is a pool of memory that is managed | |
5505 | like a stack. Objects (of any nature, size and alignment) are | |
5506 | allocated and freed in a @acronym{LIFO} fashion on an obstack (see | |
d3e8051b | 5507 | @code{libiberty}'s documentation for a more detailed explanation of |
1eb288ea EZ |
5508 | @code{obstacks}). |
5509 | ||
5510 | The most noticeable use of the @code{obstacks} in @value{GDBN} is in | |
5511 | object files. There is an obstack associated with each internal | |
5512 | representation of an object file. Lots of things get allocated on | |
5513 | these @code{obstacks}: dictionary entries, blocks, blockvectors, | |
5514 | symbols, minimal symbols, types, vectors of fundamental types, class | |
5515 | fields of types, object files section lists, object files section | |
d3e8051b | 5516 | offset lists, line tables, symbol tables, partial symbol tables, |
1eb288ea EZ |
5517 | string tables, symbol table private data, macros tables, debug |
5518 | information sections and entries, import and export lists (som), | |
5519 | unwind information (hppa), dwarf2 location expressions data. Plus | |
5520 | various strings such as directory names strings, debug format strings, | |
5521 | names of types. | |
5522 | ||
5523 | An essential and convenient property of all data on @code{obstacks} is | |
5524 | that memory for it gets allocated (with @code{obstack_alloc}) at | |
d3e8051b | 5525 | various times during a debugging session, but it is released all at |
1eb288ea EZ |
5526 | once using the @code{obstack_free} function. The @code{obstack_free} |
5527 | function takes a pointer to where in the stack it must start the | |
5528 | deletion from (much like the cleanup chains have a pointer to where to | |
5529 | start the cleanups). Because of the stack like structure of the | |
5530 | @code{obstacks}, this allows to free only a top portion of the | |
5531 | obstack. There are a few instances in @value{GDBN} where such thing | |
5532 | happens. Calls to @code{obstack_free} are done after some local data | |
5533 | is allocated to the obstack. Only the local data is deleted from the | |
5534 | obstack. Of course this assumes that nothing between the | |
5535 | @code{obstack_alloc} and the @code{obstack_free} allocates anything | |
5536 | else on the same obstack. For this reason it is best and safest to | |
5537 | use temporary @code{obstacks}. | |
5538 | ||
5539 | Releasing the whole obstack is also not safe per se. It is safe only | |
5540 | under the condition that we know the @code{obstacks} memory is no | |
5541 | longer needed. In @value{GDBN} we get rid of the @code{obstacks} only | |
5542 | when we get rid of the whole objfile(s), for instance upon reading a | |
5543 | new symbol file. | |
c906108c SS |
5544 | |
5545 | @section gnu-regex | |
56caf160 | 5546 | @cindex regular expressions library |
c906108c SS |
5547 | |
5548 | Regex conditionals. | |
5549 | ||
5550 | @table @code | |
c906108c SS |
5551 | @item C_ALLOCA |
5552 | ||
5553 | @item NFAILURES | |
5554 | ||
5555 | @item RE_NREGS | |
5556 | ||
5557 | @item SIGN_EXTEND_CHAR | |
5558 | ||
5559 | @item SWITCH_ENUM_BUG | |
5560 | ||
5561 | @item SYNTAX_TABLE | |
5562 | ||
5563 | @item Sword | |
5564 | ||
5565 | @item sparc | |
c906108c SS |
5566 | @end table |
5567 | ||
350da6ee DJ |
5568 | @section Array Containers |
5569 | @cindex Array Containers | |
5570 | @cindex VEC | |
5571 | ||
5572 | Often it is necessary to manipulate a dynamic array of a set of | |
5573 | objects. C forces some bookkeeping on this, which can get cumbersome | |
d3e8051b | 5574 | and repetitive. The @file{vec.h} file contains macros for defining |
350da6ee DJ |
5575 | and using a typesafe vector type. The functions defined will be |
5576 | inlined when compiling, and so the abstraction cost should be zero. | |
5577 | Domain checks are added to detect programming errors. | |
5578 | ||
5579 | An example use would be an array of symbols or section information. | |
5580 | The array can be grown as symbols are read in (or preallocated), and | |
5581 | the accessor macros provided keep care of all the necessary | |
5582 | bookkeeping. Because the arrays are type safe, there is no danger of | |
5583 | accidentally mixing up the contents. Think of these as C++ templates, | |
5584 | but implemented in C. | |
5585 | ||
5586 | Because of the different behavior of structure objects, scalar objects | |
5587 | and of pointers, there are three flavors of vector, one for each of | |
5588 | these variants. Both the structure object and pointer variants pass | |
5589 | pointers to objects around --- in the former case the pointers are | |
5590 | stored into the vector and in the latter case the pointers are | |
5591 | dereferenced and the objects copied into the vector. The scalar | |
5592 | object variant is suitable for @code{int}-like objects, and the vector | |
5593 | elements are returned by value. | |
5594 | ||
5595 | There are both @code{index} and @code{iterate} accessors. The iterator | |
5596 | returns a boolean iteration condition and updates the iteration | |
5597 | variable passed by reference. Because the iterator will be inlined, | |
5598 | the address-of can be optimized away. | |
5599 | ||
5600 | The vectors are implemented using the trailing array idiom, thus they | |
5601 | are not resizeable without changing the address of the vector object | |
5602 | itself. This means you cannot have variables or fields of vector type | |
5603 | --- always use a pointer to a vector. The one exception is the final | |
5604 | field of a structure, which could be a vector type. You will have to | |
5605 | use the @code{embedded_size} & @code{embedded_init} calls to create | |
5606 | such objects, and they will probably not be resizeable (so don't use | |
5607 | the @dfn{safe} allocation variants). The trailing array idiom is used | |
5608 | (rather than a pointer to an array of data), because, if we allow | |
5609 | @code{NULL} to also represent an empty vector, empty vectors occupy | |
5610 | minimal space in the structure containing them. | |
5611 | ||
5612 | Each operation that increases the number of active elements is | |
5613 | available in @dfn{quick} and @dfn{safe} variants. The former presumes | |
5614 | that there is sufficient allocated space for the operation to succeed | |
5615 | (it dies if there is not). The latter will reallocate the vector, if | |
5616 | needed. Reallocation causes an exponential increase in vector size. | |
5617 | If you know you will be adding N elements, it would be more efficient | |
5618 | to use the reserve operation before adding the elements with the | |
5619 | @dfn{quick} operation. This will ensure there are at least as many | |
5620 | elements as you ask for, it will exponentially increase if there are | |
5621 | too few spare slots. If you want reserve a specific number of slots, | |
5622 | but do not want the exponential increase (for instance, you know this | |
5623 | is the last allocation), use a negative number for reservation. You | |
5624 | can also create a vector of a specific size from the get go. | |
5625 | ||
5626 | You should prefer the push and pop operations, as they append and | |
587afa38 | 5627 | remove from the end of the vector. If you need to remove several items |
350da6ee DJ |
5628 | in one go, use the truncate operation. The insert and remove |
5629 | operations allow you to change elements in the middle of the vector. | |
5630 | There are two remove operations, one which preserves the element | |
5631 | ordering @code{ordered_remove}, and one which does not | |
5632 | @code{unordered_remove}. The latter function copies the end element | |
5633 | into the removed slot, rather than invoke a memmove operation. The | |
5634 | @code{lower_bound} function will determine where to place an item in | |
5635 | the array using insert that will maintain sorted order. | |
5636 | ||
5637 | If you need to directly manipulate a vector, then the @code{address} | |
5638 | accessor will return the address of the start of the vector. Also the | |
5639 | @code{space} predicate will tell you whether there is spare capacity in the | |
5640 | vector. You will not normally need to use these two functions. | |
5641 | ||
5642 | Vector types are defined using a | |
5643 | @code{DEF_VEC_@{O,P,I@}(@var{typename})} macro. Variables of vector | |
5644 | type are declared using a @code{VEC(@var{typename})} macro. The | |
5645 | characters @code{O}, @code{P} and @code{I} indicate whether | |
5646 | @var{typename} is an object (@code{O}), pointer (@code{P}) or integral | |
5647 | (@code{I}) type. Be careful to pick the correct one, as you'll get an | |
5648 | awkward and inefficient API if you use the wrong one. There is a | |
5649 | check, which results in a compile-time warning, for the @code{P} and | |
5650 | @code{I} versions, but there is no check for the @code{O} versions, as | |
5651 | that is not possible in plain C. | |
5652 | ||
5653 | An example of their use would be, | |
5654 | ||
5655 | @smallexample | |
5656 | DEF_VEC_P(tree); // non-managed tree vector. | |
5657 | ||
5658 | struct my_struct @{ | |
5659 | VEC(tree) *v; // A (pointer to) a vector of tree pointers. | |
5660 | @}; | |
5661 | ||
5662 | struct my_struct *s; | |
5663 | ||
5664 | if (VEC_length(tree, s->v)) @{ we have some contents @} | |
5665 | VEC_safe_push(tree, s->v, decl); // append some decl onto the end | |
5666 | for (ix = 0; VEC_iterate(tree, s->v, ix, elt); ix++) | |
5667 | @{ do something with elt @} | |
5668 | ||
5669 | @end smallexample | |
5670 | ||
5671 | The @file{vec.h} file provides details on how to invoke the various | |
5672 | accessors provided. They are enumerated here: | |
5673 | ||
5674 | @table @code | |
5675 | @item VEC_length | |
5676 | Return the number of items in the array, | |
5677 | ||
5678 | @item VEC_empty | |
5679 | Return true if the array has no elements. | |
5680 | ||
5681 | @item VEC_last | |
5682 | @itemx VEC_index | |
5683 | Return the last or arbitrary item in the array. | |
5684 | ||
5685 | @item VEC_iterate | |
5686 | Access an array element and indicate whether the array has been | |
5687 | traversed. | |
5688 | ||
5689 | @item VEC_alloc | |
5690 | @itemx VEC_free | |
5691 | Create and destroy an array. | |
5692 | ||
5693 | @item VEC_embedded_size | |
5694 | @itemx VEC_embedded_init | |
5695 | Helpers for embedding an array as the final element of another struct. | |
5696 | ||
5697 | @item VEC_copy | |
5698 | Duplicate an array. | |
5699 | ||
5700 | @item VEC_space | |
5701 | Return the amount of free space in an array. | |
5702 | ||
5703 | @item VEC_reserve | |
5704 | Ensure a certain amount of free space. | |
5705 | ||
5706 | @item VEC_quick_push | |
5707 | @itemx VEC_safe_push | |
5708 | Append to an array, either assuming the space is available, or making | |
5709 | sure that it is. | |
5710 | ||
5711 | @item VEC_pop | |
5712 | Remove the last item from an array. | |
5713 | ||
5714 | @item VEC_truncate | |
5715 | Remove several items from the end of an array. | |
5716 | ||
5717 | @item VEC_safe_grow | |
5718 | Add several items to the end of an array. | |
5719 | ||
5720 | @item VEC_replace | |
5721 | Overwrite an item in the array. | |
5722 | ||
5723 | @item VEC_quick_insert | |
5724 | @itemx VEC_safe_insert | |
5725 | Insert an item into the middle of the array. Either the space must | |
5726 | already exist, or the space is created. | |
5727 | ||
5728 | @item VEC_ordered_remove | |
5729 | @itemx VEC_unordered_remove | |
5730 | Remove an item from the array, preserving order or not. | |
5731 | ||
5732 | @item VEC_block_remove | |
5733 | Remove a set of items from the array. | |
5734 | ||
5735 | @item VEC_address | |
5736 | Provide the address of the first element. | |
5737 | ||
5738 | @item VEC_lower_bound | |
5739 | Binary search the array. | |
5740 | ||
5741 | @end table | |
5742 | ||
c906108c SS |
5743 | @section include |
5744 | ||
a0e0ffdf | 5745 | @node Coding Standards |
c906108c | 5746 | |
a0e0ffdf DE |
5747 | @chapter Coding Standards |
5748 | @cindex coding standards | |
5749 | ||
5750 | @section @value{GDBN} C Coding Standards | |
5751 | ||
5752 | @value{GDBN} follows the GNU coding standards, as described in | |
5753 | @file{etc/standards.texi}. This file is also available for anonymous | |
5754 | FTP from GNU archive sites. @value{GDBN} takes a strict interpretation | |
5755 | of the standard; in general, when the GNU standard recommends a practice | |
5756 | but does not require it, @value{GDBN} requires it. | |
5757 | ||
5758 | @value{GDBN} follows an additional set of coding standards specific to | |
5759 | @value{GDBN}, as described in the following sections. | |
5760 | ||
5761 | @subsection ISO C | |
5762 | ||
5763 | @value{GDBN} assumes an ISO/IEC 9899:1990 (a.k.a.@: ISO C90) compliant | |
5764 | compiler. | |
5765 | ||
5766 | @value{GDBN} does not assume an ISO C or POSIX compliant C library. | |
5767 | ||
5768 | @subsection Formatting | |
5769 | ||
5770 | @cindex source code formatting | |
5771 | The standard GNU recommendations for formatting must be followed | |
cef35b0f PA |
5772 | strictly. Any @value{GDBN}-specific deviation from GNU |
5773 | recomendations is described below. | |
a0e0ffdf DE |
5774 | |
5775 | A function declaration should not have its name in column zero. A | |
5776 | function definition should have its name in column zero. | |
5777 | ||
5778 | @smallexample | |
5779 | /* Declaration */ | |
5780 | static void foo (void); | |
5781 | /* Definition */ | |
5782 | void | |
5783 | foo (void) | |
5784 | @{ | |
5785 | @} | |
5786 | @end smallexample | |
5787 | ||
5788 | @emph{Pragmatics: This simplifies scripting. Function definitions can | |
5789 | be found using @samp{^function-name}.} | |
5790 | ||
5791 | There must be a space between a function or macro name and the opening | |
5792 | parenthesis of its argument list (except for macro definitions, as | |
5793 | required by C). There must not be a space after an open paren/bracket | |
5794 | or before a close paren/bracket. | |
5795 | ||
5796 | While additional whitespace is generally helpful for reading, do not use | |
5797 | more than one blank line to separate blocks, and avoid adding whitespace | |
5798 | after the end of a program line (as of 1/99, some 600 lines had | |
5799 | whitespace after the semicolon). Excess whitespace causes difficulties | |
5800 | for @code{diff} and @code{patch} utilities. | |
5801 | ||
5802 | Pointers are declared using the traditional K&R C style: | |
5803 | ||
5804 | @smallexample | |
5805 | void *foo; | |
5806 | @end smallexample | |
5807 | ||
5808 | @noindent | |
5809 | and not: | |
5810 | ||
5811 | @smallexample | |
5812 | void * foo; | |
5813 | void* foo; | |
5814 | @end smallexample | |
5815 | ||
cef35b0f PA |
5816 | In addition, whitespace around casts and unary operators should follow |
5817 | the following guidelines: | |
5818 | ||
5819 | @multitable @columnfractions .2 .2 .8 | |
5820 | @item Use... @tab ...instead of @tab | |
5821 | ||
5822 | @item @code{!x} | |
5823 | @tab @code{! x} | |
5824 | @item @code{~x} | |
5825 | @tab @code{~ x} | |
5826 | @item @code{-x} | |
5827 | @tab @code{- x} | |
5828 | @tab (unary minus) | |
5829 | @item @code{(foo) x} | |
5830 | @tab @code{(foo)x} | |
5831 | @tab (cast) | |
5832 | @item @code{*x} | |
5833 | @tab @code{* x} | |
5834 | @tab (pointer dereference) | |
5835 | @end multitable | |
5836 | ||
0ee339bc JK |
5837 | Any two or more lines in code should be wrapped in braces, even if |
5838 | they are comments, as they look like separate statements: | |
5839 | ||
5840 | @smallexample | |
5841 | if (i) | |
5842 | @{ | |
5843 | /* Return success. */ | |
5844 | return 0; | |
5845 | @} | |
5846 | @end smallexample | |
5847 | ||
5848 | @noindent | |
5849 | and not: | |
5850 | ||
5851 | @smallexample | |
5852 | if (i) | |
5853 | /* Return success. */ | |
5854 | return 0; | |
5855 | @end smallexample | |
5856 | ||
a0e0ffdf DE |
5857 | @subsection Comments |
5858 | ||
5859 | @cindex comment formatting | |
5860 | The standard GNU requirements on comments must be followed strictly. | |
5861 | ||
5862 | Block comments must appear in the following form, with no @code{/*}- or | |
5863 | @code{*/}-only lines, and no leading @code{*}: | |
5864 | ||
5865 | @smallexample | |
5866 | /* Wait for control to return from inferior to debugger. If inferior | |
5867 | gets a signal, we may decide to start it up again instead of | |
5868 | returning. That is why there is a loop in this function. When | |
5869 | this function actually returns it means the inferior should be left | |
5870 | stopped and @value{GDBN} should read more commands. */ | |
5871 | @end smallexample | |
5872 | ||
5873 | (Note that this format is encouraged by Emacs; tabbing for a multi-line | |
5874 | comment works correctly, and @kbd{M-q} fills the block consistently.) | |
5875 | ||
5876 | Put a blank line between the block comments preceding function or | |
5877 | variable definitions, and the definition itself. | |
5878 | ||
5879 | In general, put function-body comments on lines by themselves, rather | |
5880 | than trying to fit them into the 20 characters left at the end of a | |
5881 | line, since either the comment or the code will inevitably get longer | |
5882 | than will fit, and then somebody will have to move it anyhow. | |
5883 | ||
5884 | @subsection C Usage | |
5885 | ||
5886 | @cindex C data types | |
5887 | Code must not depend on the sizes of C data types, the format of the | |
5888 | host's floating point numbers, the alignment of anything, or the order | |
5889 | of evaluation of expressions. | |
5890 | ||
5891 | @cindex function usage | |
5892 | Use functions freely. There are only a handful of compute-bound areas | |
5893 | in @value{GDBN} that might be affected by the overhead of a function | |
5894 | call, mainly in symbol reading. Most of @value{GDBN}'s performance is | |
5895 | limited by the target interface (whether serial line or system call). | |
5896 | ||
5897 | However, use functions with moderation. A thousand one-line functions | |
5898 | are just as hard to understand as a single thousand-line function. | |
5899 | ||
5900 | @emph{Macros are bad, M'kay.} | |
5901 | (But if you have to use a macro, make sure that the macro arguments are | |
5902 | protected with parentheses.) | |
5903 | ||
5904 | @cindex types | |
5905 | ||
5906 | Declarations like @samp{struct foo *} should be used in preference to | |
5907 | declarations like @samp{typedef struct foo @{ @dots{} @} *foo_ptr}. | |
5908 | ||
3d745be3 JK |
5909 | Zero constant (@code{0}) is not interchangeable with a null pointer |
5910 | constant (@code{NULL}) anywhere. @sc{gcc} does not give a warning for | |
5911 | such interchange. Specifically: | |
5912 | ||
5913 | @multitable @columnfractions .2 .5 | |
5914 | @item incorrect | |
5915 | @tab @code{if (pointervar) @{@}} | |
5916 | @item incorrect | |
5917 | @tab @code{if (!pointervar) @{@}} | |
5918 | @item incorrect | |
5919 | @tab @code{if (pointervar != 0) @{@}} | |
5920 | @item incorrect | |
5921 | @tab @code{if (pointervar == 0) @{@}} | |
5922 | @item correct | |
5923 | @tab @code{if (pointervar != NULL) @{@}} | |
5924 | @item correct | |
5925 | @tab @code{if (pointervar == NULL) @{@}} | |
5926 | @end multitable | |
5927 | ||
a0e0ffdf DE |
5928 | @subsection Function Prototypes |
5929 | @cindex function prototypes | |
5930 | ||
5931 | Prototypes must be used when both @emph{declaring} and @emph{defining} | |
5932 | a function. Prototypes for @value{GDBN} functions must include both the | |
5933 | argument type and name, with the name matching that used in the actual | |
5934 | function definition. | |
5935 | ||
5936 | All external functions should have a declaration in a header file that | |
0dfd2fad PM |
5937 | callers include, that declaration should use the @code{extern} modifier. |
5938 | The only exception concerns @code{_initialize_*} functions, which must | |
a0e0ffdf DE |
5939 | be external so that @file{init.c} construction works, but shouldn't be |
5940 | visible to random source files. | |
5941 | ||
5942 | Where a source file needs a forward declaration of a static function, | |
5943 | that declaration must appear in a block near the top of the source file. | |
5944 | ||
5945 | @subsection File Names | |
5946 | ||
5947 | Any file used when building the core of @value{GDBN} must be in lower | |
5948 | case. Any file used when building the core of @value{GDBN} must be 8.3 | |
5949 | unique. These requirements apply to both source and generated files. | |
5950 | ||
5951 | @emph{Pragmatics: The core of @value{GDBN} must be buildable on many | |
5952 | platforms including DJGPP and MacOS/HFS. Every time an unfriendly file | |
5953 | is introduced to the build process both @file{Makefile.in} and | |
5954 | @file{configure.in} need to be modified accordingly. Compare the | |
5955 | convoluted conversion process needed to transform @file{COPYING} into | |
5956 | @file{copying.c} with the conversion needed to transform | |
5957 | @file{version.in} into @file{version.c}.} | |
5958 | ||
5959 | Any file non 8.3 compliant file (that is not used when building the core | |
5960 | of @value{GDBN}) must be added to @file{gdb/config/djgpp/fnchange.lst}. | |
5961 | ||
5962 | @emph{Pragmatics: This is clearly a compromise.} | |
5963 | ||
5964 | When @value{GDBN} has a local version of a system header file (ex | |
5965 | @file{string.h}) the file name based on the POSIX header prefixed with | |
5966 | @file{gdb_} (@file{gdb_string.h}). These headers should be relatively | |
5967 | independent: they should use only macros defined by @file{configure}, | |
5968 | the compiler, or the host; they should include only system headers; they | |
5969 | should refer only to system types. They may be shared between multiple | |
5970 | programs, e.g.@: @value{GDBN} and @sc{gdbserver}. | |
5971 | ||
5972 | For other files @samp{-} is used as the separator. | |
5973 | ||
5974 | @subsection Include Files | |
5975 | ||
5976 | A @file{.c} file should include @file{defs.h} first. | |
5977 | ||
5978 | A @file{.c} file should directly include the @code{.h} file of every | |
5979 | declaration and/or definition it directly refers to. It cannot rely on | |
5980 | indirect inclusion. | |
5981 | ||
5982 | A @file{.h} file should directly include the @code{.h} file of every | |
5983 | declaration and/or definition it directly refers to. It cannot rely on | |
5984 | indirect inclusion. Exception: The file @file{defs.h} does not need to | |
5985 | be directly included. | |
5986 | ||
5987 | An external declaration should only appear in one include file. | |
5988 | ||
5989 | An external declaration should never appear in a @code{.c} file. | |
5990 | Exception: a declaration for the @code{_initialize} function that | |
5991 | pacifies @option{-Wmissing-declaration}. | |
5992 | ||
5993 | A @code{typedef} definition should only appear in one include file. | |
5994 | ||
5995 | An opaque @code{struct} declaration can appear in multiple @file{.h} | |
5996 | files. Where possible, a @file{.h} file should use an opaque | |
5997 | @code{struct} declaration instead of an include. | |
5998 | ||
5999 | All @file{.h} files should be wrapped in: | |
6000 | ||
6001 | @smallexample | |
6002 | #ifndef INCLUDE_FILE_NAME_H | |
6003 | #define INCLUDE_FILE_NAME_H | |
6004 | header body | |
6005 | #endif | |
6006 | @end smallexample | |
6007 | ||
6008 | @section @value{GDBN} Python Coding Standards | |
6009 | ||
6010 | @value{GDBN} follows the published @code{Python} coding standards in | |
6011 | @uref{http://www.python.org/dev/peps/pep-0008/, @code{PEP008}}. | |
6012 | ||
6013 | In addition, the guidelines in the | |
6014 | @uref{http://google-styleguide.googlecode.com/svn/trunk/pyguide.html, | |
6015 | Google Python Style Guide} are also followed where they do not | |
6016 | conflict with @code{PEP008}. | |
6017 | ||
6018 | @subsection @value{GDBN}-specific exceptions | |
6019 | ||
6020 | There are a few exceptions to the published standards. | |
6021 | They exist mainly for consistency with the @code{C} standards. | |
6022 | ||
6023 | @c It is expected that there are a few more exceptions, | |
6024 | @c so we use itemize here. | |
6025 | ||
6026 | @itemize @bullet | |
6027 | ||
6028 | @item | |
6029 | Use @code{FIXME} instead of @code{TODO}. | |
6030 | ||
6031 | @end itemize | |
6032 | ||
6033 | @node Misc Guidelines | |
6034 | ||
6035 | @chapter Misc Guidelines | |
c906108c SS |
6036 | |
6037 | This chapter covers topics that are lower-level than the major | |
25822942 | 6038 | algorithms of @value{GDBN}. |
c906108c SS |
6039 | |
6040 | @section Cleanups | |
56caf160 | 6041 | @cindex cleanups |
c906108c SS |
6042 | |
6043 | Cleanups are a structured way to deal with things that need to be done | |
cc1cb004 | 6044 | later. |
c906108c | 6045 | |
cc1cb004 AC |
6046 | When your code does something (e.g., @code{xmalloc} some memory, or |
6047 | @code{open} a file) that needs to be undone later (e.g., @code{xfree} | |
6048 | the memory or @code{close} the file), it can make a cleanup. The | |
6049 | cleanup will be done at some future point: when the command is finished | |
6050 | and control returns to the top level; when an error occurs and the stack | |
6051 | is unwound; or when your code decides it's time to explicitly perform | |
6052 | cleanups. Alternatively you can elect to discard the cleanups you | |
6053 | created. | |
c906108c SS |
6054 | |
6055 | Syntax: | |
6056 | ||
6057 | @table @code | |
c906108c SS |
6058 | @item struct cleanup *@var{old_chain}; |
6059 | Declare a variable which will hold a cleanup chain handle. | |
6060 | ||
56caf160 | 6061 | @findex make_cleanup |
c906108c SS |
6062 | @item @var{old_chain} = make_cleanup (@var{function}, @var{arg}); |
6063 | Make a cleanup which will cause @var{function} to be called with | |
6064 | @var{arg} (a @code{char *}) later. The result, @var{old_chain}, is a | |
cc1cb004 AC |
6065 | handle that can later be passed to @code{do_cleanups} or |
6066 | @code{discard_cleanups}. Unless you are going to call | |
6067 | @code{do_cleanups} or @code{discard_cleanups}, you can ignore the result | |
6068 | from @code{make_cleanup}. | |
c906108c | 6069 | |
56caf160 | 6070 | @findex do_cleanups |
c906108c | 6071 | @item do_cleanups (@var{old_chain}); |
cc1cb004 AC |
6072 | Do all cleanups added to the chain since the corresponding |
6073 | @code{make_cleanup} call was made. | |
6074 | ||
6075 | @findex discard_cleanups | |
6076 | @item discard_cleanups (@var{old_chain}); | |
6077 | Same as @code{do_cleanups} except that it just removes the cleanups from | |
6078 | the chain and does not call the specified functions. | |
6079 | @end table | |
6080 | ||
6081 | Cleanups are implemented as a chain. The handle returned by | |
6082 | @code{make_cleanups} includes the cleanup passed to the call and any | |
6083 | later cleanups appended to the chain (but not yet discarded or | |
6084 | performed). E.g.: | |
56caf160 | 6085 | |
474c8240 | 6086 | @smallexample |
c906108c | 6087 | make_cleanup (a, 0); |
cc1cb004 AC |
6088 | @{ |
6089 | struct cleanup *old = make_cleanup (b, 0); | |
6090 | make_cleanup (c, 0) | |
6091 | ... | |
6092 | do_cleanups (old); | |
6093 | @} | |
474c8240 | 6094 | @end smallexample |
56caf160 | 6095 | |
c906108c | 6096 | @noindent |
cc1cb004 AC |
6097 | will call @code{c()} and @code{b()} but will not call @code{a()}. The |
6098 | cleanup that calls @code{a()} will remain in the cleanup chain, and will | |
6099 | be done later unless otherwise discarded.@refill | |
6100 | ||
6101 | Your function should explicitly do or discard the cleanups it creates. | |
6102 | Failing to do this leads to non-deterministic behavior since the caller | |
6103 | will arbitrarily do or discard your functions cleanups. This need leads | |
6104 | to two common cleanup styles. | |
6105 | ||
6106 | The first style is try/finally. Before it exits, your code-block calls | |
6107 | @code{do_cleanups} with the old cleanup chain and thus ensures that your | |
6108 | code-block's cleanups are always performed. For instance, the following | |
6109 | code-segment avoids a memory leak problem (even when @code{error} is | |
6110 | called and a forced stack unwind occurs) by ensuring that the | |
6111 | @code{xfree} will always be called: | |
c906108c | 6112 | |
474c8240 | 6113 | @smallexample |
cc1cb004 AC |
6114 | struct cleanup *old = make_cleanup (null_cleanup, 0); |
6115 | data = xmalloc (sizeof blah); | |
6116 | make_cleanup (xfree, data); | |
6117 | ... blah blah ... | |
6118 | do_cleanups (old); | |
474c8240 | 6119 | @end smallexample |
cc1cb004 AC |
6120 | |
6121 | The second style is try/except. Before it exits, your code-block calls | |
6122 | @code{discard_cleanups} with the old cleanup chain and thus ensures that | |
6123 | any created cleanups are not performed. For instance, the following | |
6124 | code segment, ensures that the file will be closed but only if there is | |
6125 | an error: | |
6126 | ||
474c8240 | 6127 | @smallexample |
cc1cb004 AC |
6128 | FILE *file = fopen ("afile", "r"); |
6129 | struct cleanup *old = make_cleanup (close_file, file); | |
6130 | ... blah blah ... | |
6131 | discard_cleanups (old); | |
6132 | return file; | |
474c8240 | 6133 | @end smallexample |
c906108c | 6134 | |
c1468174 | 6135 | Some functions, e.g., @code{fputs_filtered()} or @code{error()}, specify |
c906108c SS |
6136 | that they ``should not be called when cleanups are not in place''. This |
6137 | means that any actions you need to reverse in the case of an error or | |
6138 | interruption must be on the cleanup chain before you call these | |
6139 | functions, since they might never return to your code (they | |
6140 | @samp{longjmp} instead). | |
6141 | ||
ba8c9337 AC |
6142 | @section Per-architecture module data |
6143 | @cindex per-architecture module data | |
6144 | @cindex multi-arch data | |
6145 | @cindex data-pointer, per-architecture/per-module | |
6146 | ||
fc989b7a AC |
6147 | The multi-arch framework includes a mechanism for adding module |
6148 | specific per-architecture data-pointers to the @code{struct gdbarch} | |
6149 | architecture object. | |
6150 | ||
6151 | A module registers one or more per-architecture data-pointers using: | |
6152 | ||
587afa38 | 6153 | @deftypefn {Architecture Function} {struct gdbarch_data *} gdbarch_data_register_pre_init (gdbarch_data_pre_init_ftype *@var{pre_init}) |
fc989b7a AC |
6154 | @var{pre_init} is used to, on-demand, allocate an initial value for a |
6155 | per-architecture data-pointer using the architecture's obstack (passed | |
6156 | in as a parameter). Since @var{pre_init} can be called during | |
6157 | architecture creation, it is not parameterized with the architecture. | |
6158 | and must not call modules that use per-architecture data. | |
587afa38 | 6159 | @end deftypefn |
ba8c9337 | 6160 | |
587afa38 | 6161 | @deftypefn {Architecture Function} {struct gdbarch_data *} gdbarch_data_register_post_init (gdbarch_data_post_init_ftype *@var{post_init}) |
fc989b7a AC |
6162 | @var{post_init} is used to obtain an initial value for a |
6163 | per-architecture data-pointer @emph{after}. Since @var{post_init} is | |
6164 | always called after architecture creation, it both receives the fully | |
6165 | initialized architecture and is free to call modules that use | |
6166 | per-architecture data (care needs to be taken to ensure that those | |
6167 | other modules do not try to call back to this module as that will | |
6168 | create in cycles in the initialization call graph). | |
587afa38 | 6169 | @end deftypefn |
ba8c9337 | 6170 | |
fc989b7a AC |
6171 | These functions return a @code{struct gdbarch_data} that is used to |
6172 | identify the per-architecture data-pointer added for that module. | |
ba8c9337 | 6173 | |
fc989b7a | 6174 | The per-architecture data-pointer is accessed using the function: |
ba8c9337 | 6175 | |
587afa38 | 6176 | @deftypefn {Architecture Function} {void *} gdbarch_data (struct gdbarch *@var{gdbarch}, struct gdbarch_data *@var{data_handle}) |
fc989b7a AC |
6177 | Given the architecture @var{arch} and module data handle |
6178 | @var{data_handle} (returned by @code{gdbarch_data_register_pre_init} | |
6179 | or @code{gdbarch_data_register_post_init}), this function returns the | |
6180 | current value of the per-architecture data-pointer. If the data | |
6181 | pointer is @code{NULL}, it is first initialized by calling the | |
6182 | corresponding @var{pre_init} or @var{post_init} method. | |
587afa38 | 6183 | @end deftypefn |
ba8c9337 | 6184 | |
fc989b7a | 6185 | The examples below assume the following definitions: |
ba8c9337 AC |
6186 | |
6187 | @smallexample | |
e7f16015 | 6188 | struct nozel @{ int total; @}; |
ba8c9337 | 6189 | static struct gdbarch_data *nozel_handle; |
ba8c9337 AC |
6190 | @end smallexample |
6191 | ||
fc989b7a AC |
6192 | A module can extend the architecture vector, adding additional |
6193 | per-architecture data, using the @var{pre_init} method. The module's | |
6194 | per-architecture data is then initialized during architecture | |
6195 | creation. | |
ba8c9337 | 6196 | |
fc989b7a AC |
6197 | In the below, the module's per-architecture @emph{nozel} is added. An |
6198 | architecture can specify its nozel by calling @code{set_gdbarch_nozel} | |
6199 | from @code{gdbarch_init}. | |
ba8c9337 AC |
6200 | |
6201 | @smallexample | |
fc989b7a AC |
6202 | static void * |
6203 | nozel_pre_init (struct obstack *obstack) | |
ba8c9337 | 6204 | @{ |
fc989b7a AC |
6205 | struct nozel *data = OBSTACK_ZALLOC (obstack, struct nozel); |
6206 | return data; | |
6207 | @} | |
ba8c9337 AC |
6208 | @end smallexample |
6209 | ||
ba8c9337 | 6210 | @smallexample |
fc989b7a AC |
6211 | extern void |
6212 | set_gdbarch_nozel (struct gdbarch *gdbarch, int total) | |
ba8c9337 | 6213 | @{ |
ba8c9337 | 6214 | struct nozel *data = gdbarch_data (gdbarch, nozel_handle); |
fc989b7a | 6215 | data->total = nozel; |
ba8c9337 AC |
6216 | @} |
6217 | @end smallexample | |
6218 | ||
587afa38 | 6219 | A module can on-demand create architecture dependent data structures |
fc989b7a | 6220 | using @code{post_init}. |
ba8c9337 | 6221 | |
fc989b7a AC |
6222 | In the below, the nozel's total is computed on-demand by |
6223 | @code{nozel_post_init} using information obtained from the | |
6224 | architecture. | |
ba8c9337 AC |
6225 | |
6226 | @smallexample | |
fc989b7a AC |
6227 | static void * |
6228 | nozel_post_init (struct gdbarch *gdbarch) | |
ba8c9337 | 6229 | @{ |
fc989b7a AC |
6230 | struct nozel *data = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct nozel); |
6231 | nozel->total = gdbarch@dots{} (gdbarch); | |
6232 | return data; | |
ba8c9337 AC |
6233 | @} |
6234 | @end smallexample | |
6235 | ||
6236 | @smallexample | |
fc989b7a AC |
6237 | extern int |
6238 | nozel_total (struct gdbarch *gdbarch) | |
ba8c9337 | 6239 | @{ |
fc989b7a AC |
6240 | struct nozel *data = gdbarch_data (gdbarch, nozel_handle); |
6241 | return data->total; | |
ba8c9337 AC |
6242 | @} |
6243 | @end smallexample | |
6244 | ||
c906108c | 6245 | @section Wrapping Output Lines |
56caf160 | 6246 | @cindex line wrap in output |
c906108c | 6247 | |
56caf160 | 6248 | @findex wrap_here |
c906108c SS |
6249 | Output that goes through @code{printf_filtered} or @code{fputs_filtered} |
6250 | or @code{fputs_demangled} needs only to have calls to @code{wrap_here} | |
6251 | added in places that would be good breaking points. The utility | |
6252 | routines will take care of actually wrapping if the line width is | |
6253 | exceeded. | |
6254 | ||
6255 | The argument to @code{wrap_here} is an indentation string which is | |
6256 | printed @emph{only} if the line breaks there. This argument is saved | |
6257 | away and used later. It must remain valid until the next call to | |
6258 | @code{wrap_here} or until a newline has been printed through the | |
6259 | @code{*_filtered} functions. Don't pass in a local variable and then | |
6260 | return! | |
6261 | ||
56caf160 | 6262 | It is usually best to call @code{wrap_here} after printing a comma or |
c906108c SS |
6263 | space. If you call it before printing a space, make sure that your |
6264 | indentation properly accounts for the leading space that will print if | |
6265 | the line wraps there. | |
6266 | ||
6267 | Any function or set of functions that produce filtered output must | |
6268 | finish by printing a newline, to flush the wrap buffer, before switching | |
56caf160 | 6269 | to unfiltered (@code{printf}) output. Symbol reading routines that |
c906108c SS |
6270 | print warnings are a good example. |
6271 | ||
a0e0ffdf | 6272 | @section Memory Management |
af6c57ea AC |
6273 | |
6274 | @value{GDBN} does not use the functions @code{malloc}, @code{realloc}, | |
6275 | @code{calloc}, @code{free} and @code{asprintf}. | |
6276 | ||
6277 | @value{GDBN} uses the functions @code{xmalloc}, @code{xrealloc} and | |
6278 | @code{xcalloc} when allocating memory. Unlike @code{malloc} et.al.@: | |
6279 | these functions do not return when the memory pool is empty. Instead, | |
6280 | they unwind the stack using cleanups. These functions return | |
6281 | @code{NULL} when requested to allocate a chunk of memory of size zero. | |
6282 | ||
6283 | @emph{Pragmatics: By using these functions, the need to check every | |
6284 | memory allocation is removed. These functions provide portable | |
6285 | behavior.} | |
6286 | ||
6287 | @value{GDBN} does not use the function @code{free}. | |
6288 | ||
6289 | @value{GDBN} uses the function @code{xfree} to return memory to the | |
6290 | memory pool. Consistent with ISO-C, this function ignores a request to | |
6291 | free a @code{NULL} pointer. | |
6292 | ||
6293 | @emph{Pragmatics: On some systems @code{free} fails when passed a | |
6294 | @code{NULL} pointer.} | |
6295 | ||
6296 | @value{GDBN} can use the non-portable function @code{alloca} for the | |
6297 | allocation of small temporary values (such as strings). | |
6298 | ||
6299 | @emph{Pragmatics: This function is very non-portable. Some systems | |
6300 | restrict the memory being allocated to no more than a few kilobytes.} | |
6301 | ||
6302 | @value{GDBN} uses the string function @code{xstrdup} and the print | |
b435e160 | 6303 | function @code{xstrprintf}. |
af6c57ea AC |
6304 | |
6305 | @emph{Pragmatics: @code{asprintf} and @code{strdup} can fail. Print | |
6306 | functions such as @code{sprintf} are very prone to buffer overflow | |
6307 | errors.} | |
6308 | ||
6309 | ||
a0e0ffdf | 6310 | @section Compiler Warnings |
56caf160 | 6311 | @cindex compiler warnings |
af6c57ea | 6312 | |
aa79a185 DJ |
6313 | With few exceptions, developers should avoid the configuration option |
6314 | @samp{--disable-werror} when building @value{GDBN}. The exceptions | |
6315 | are listed in the file @file{gdb/MAINTAINERS}. The default, when | |
6316 | building with @sc{gcc}, is @samp{--enable-werror}. | |
af6c57ea AC |
6317 | |
6318 | This option causes @value{GDBN} (when built using GCC) to be compiled | |
6319 | with a carefully selected list of compiler warning flags. Any warnings | |
aa79a185 | 6320 | from those flags are treated as errors. |
af6c57ea AC |
6321 | |
6322 | The current list of warning flags includes: | |
6323 | ||
6324 | @table @samp | |
aa79a185 DJ |
6325 | @item -Wall |
6326 | Recommended @sc{gcc} warnings. | |
af6c57ea | 6327 | |
aa79a185 | 6328 | @item -Wdeclaration-after-statement |
af6c57ea | 6329 | |
aa79a185 DJ |
6330 | @sc{gcc} 3.x (and later) and @sc{c99} allow declarations mixed with |
6331 | code, but @sc{gcc} 2.x and @sc{c89} do not. | |
af6c57ea | 6332 | |
aa79a185 | 6333 | @item -Wpointer-arith |
af6c57ea | 6334 | |
aa79a185 DJ |
6335 | @item -Wformat-nonliteral |
6336 | Non-literal format strings, with a few exceptions, are bugs - they | |
d3e8051b | 6337 | might contain unintended user-supplied format specifiers. |
af6c57ea | 6338 | Since @value{GDBN} uses the @code{format printf} attribute on all |
aa79a185 | 6339 | @code{printf} like functions this checks not just @code{printf} calls |
af6c57ea AC |
6340 | but also calls to functions such as @code{fprintf_unfiltered}. |
6341 | ||
bd3f3b55 PA |
6342 | @item -Wpointer-sign |
6343 | This helps make sure @value{GDBN} code uses @code{gdb_byte} which is | |
6344 | really @code{unsigned char} for raw bytes instead of @code{char}, | |
6345 | whose signness is host-dependent. @sc{gcc} enables this with | |
6346 | @code{-Wall} since version 4.0. We enable it explicitly too to be | |
6347 | decoupled from future @sc{gcc} (or other compiler)'s defaults. | |
7be93b9e | 6348 | |
aa79a185 DJ |
6349 | @item -Wno-unused-parameter |
6350 | Due to the way that @value{GDBN} is implemented many functions have | |
6351 | unused parameters. Consequently this warning is avoided. The macro | |
af6c57ea AC |
6352 | @code{ATTRIBUTE_UNUSED} is not used as it leads to false negatives --- |
6353 | it is not an error to have @code{ATTRIBUTE_UNUSED} on a parameter that | |
aa79a185 DJ |
6354 | is being used. |
6355 | ||
6356 | @item -Wno-unused | |
6357 | @itemx -Wno-switch | |
58b38ee2 | 6358 | @itemx -Wno-char-subscripts |
aa79a185 DJ |
6359 | These are warnings which might be useful for @value{GDBN}, but are |
6360 | currently too noisy to enable with @samp{-Werror}. | |
af6c57ea | 6361 | |
aa79a185 | 6362 | @end table |
c906108c | 6363 | |
a0e0ffdf | 6364 | @section Internal Error Recovery |
af6c57ea AC |
6365 | |
6366 | During its execution, @value{GDBN} can encounter two types of errors. | |
6367 | User errors and internal errors. User errors include not only a user | |
6368 | entering an incorrect command but also problems arising from corrupt | |
6369 | object files and system errors when interacting with the target. | |
937f164b FF |
6370 | Internal errors include situations where @value{GDBN} has detected, at |
6371 | run time, a corrupt or erroneous situation. | |
af6c57ea AC |
6372 | |
6373 | When reporting an internal error, @value{GDBN} uses | |
6374 | @code{internal_error} and @code{gdb_assert}. | |
6375 | ||
6376 | @value{GDBN} must not call @code{abort} or @code{assert}. | |
6377 | ||
6378 | @emph{Pragmatics: There is no @code{internal_warning} function. Either | |
6379 | the code detected a user error, recovered from it and issued a | |
6380 | @code{warning} or the code failed to correctly recover from the user | |
6381 | error and issued an @code{internal_error}.} | |
6382 | ||
a0e0ffdf | 6383 | @section Command Names |
aaf4119b DE |
6384 | |
6385 | GDB U/I commands are written @samp{foo-bar}, not @samp{foo_bar}. | |
6386 | ||
a0e0ffdf | 6387 | @section Clean Design and Portable Implementation |
c906108c | 6388 | |
56caf160 | 6389 | @cindex design |
c906108c | 6390 | In addition to getting the syntax right, there's the little question of |
25822942 | 6391 | semantics. Some things are done in certain ways in @value{GDBN} because long |
c906108c SS |
6392 | experience has shown that the more obvious ways caused various kinds of |
6393 | trouble. | |
6394 | ||
56caf160 | 6395 | @cindex assumptions about targets |
c906108c SS |
6396 | You can't assume the byte order of anything that comes from a target |
6397 | (including @var{value}s, object files, and instructions). Such things | |
56caf160 EZ |
6398 | must be byte-swapped using @code{SWAP_TARGET_AND_HOST} in |
6399 | @value{GDBN}, or one of the swap routines defined in @file{bfd.h}, | |
6400 | such as @code{bfd_get_32}. | |
c906108c SS |
6401 | |
6402 | You can't assume that you know what interface is being used to talk to | |
6403 | the target system. All references to the target must go through the | |
6404 | current @code{target_ops} vector. | |
6405 | ||
6406 | You can't assume that the host and target machines are the same machine | |
6407 | (except in the ``native'' support modules). In particular, you can't | |
6408 | assume that the target machine's header files will be available on the | |
6409 | host machine. Target code must bring along its own header files -- | |
6410 | written from scratch or explicitly donated by their owner, to avoid | |
6411 | copyright problems. | |
6412 | ||
56caf160 | 6413 | @cindex portability |
c906108c SS |
6414 | Insertion of new @code{#ifdef}'s will be frowned upon. It's much better |
6415 | to write the code portably than to conditionalize it for various | |
6416 | systems. | |
6417 | ||
56caf160 | 6418 | @cindex system dependencies |
c906108c SS |
6419 | New @code{#ifdef}'s which test for specific compilers or manufacturers |
6420 | or operating systems are unacceptable. All @code{#ifdef}'s should test | |
6421 | for features. The information about which configurations contain which | |
6422 | features should be segregated into the configuration files. Experience | |
6423 | has proven far too often that a feature unique to one particular system | |
6424 | often creeps into other systems; and that a conditional based on some | |
6425 | predefined macro for your current system will become worthless over | |
6426 | time, as new versions of your system come out that behave differently | |
6427 | with regard to this feature. | |
6428 | ||
6429 | Adding code that handles specific architectures, operating systems, | |
af6c57ea | 6430 | target interfaces, or hosts, is not acceptable in generic code. |
c906108c | 6431 | |
dab11f21 EZ |
6432 | @cindex portable file name handling |
6433 | @cindex file names, portability | |
6434 | One particularly notorious area where system dependencies tend to | |
6435 | creep in is handling of file names. The mainline @value{GDBN} code | |
6436 | assumes Posix semantics of file names: absolute file names begin with | |
6437 | a forward slash @file{/}, slashes are used to separate leading | |
6438 | directories, case-sensitive file names. These assumptions are not | |
6439 | necessarily true on non-Posix systems such as MS-Windows. To avoid | |
6440 | system-dependent code where you need to take apart or construct a file | |
6441 | name, use the following portable macros: | |
6442 | ||
6443 | @table @code | |
6444 | @findex HAVE_DOS_BASED_FILE_SYSTEM | |
6445 | @item HAVE_DOS_BASED_FILE_SYSTEM | |
6446 | This preprocessing symbol is defined to a non-zero value on hosts | |
6447 | whose filesystems belong to the MS-DOS/MS-Windows family. Use this | |
6448 | symbol to write conditional code which should only be compiled for | |
6449 | such hosts. | |
6450 | ||
6451 | @findex IS_DIR_SEPARATOR | |
4be31470 | 6452 | @item IS_DIR_SEPARATOR (@var{c}) |
dab11f21 EZ |
6453 | Evaluates to a non-zero value if @var{c} is a directory separator |
6454 | character. On Unix and GNU/Linux systems, only a slash @file{/} is | |
6455 | such a character, but on Windows, both @file{/} and @file{\} will | |
6456 | pass. | |
6457 | ||
6458 | @findex IS_ABSOLUTE_PATH | |
6459 | @item IS_ABSOLUTE_PATH (@var{file}) | |
6460 | Evaluates to a non-zero value if @var{file} is an absolute file name. | |
6461 | For Unix and GNU/Linux hosts, a name which begins with a slash | |
6462 | @file{/} is absolute. On DOS and Windows, @file{d:/foo} and | |
6463 | @file{x:\bar} are also absolute file names. | |
6464 | ||
6465 | @findex FILENAME_CMP | |
6466 | @item FILENAME_CMP (@var{f1}, @var{f2}) | |
6467 | Calls a function which compares file names @var{f1} and @var{f2} as | |
6468 | appropriate for the underlying host filesystem. For Posix systems, | |
6469 | this simply calls @code{strcmp}; on case-insensitive filesystems it | |
6470 | will call @code{strcasecmp} instead. | |
6471 | ||
6472 | @findex DIRNAME_SEPARATOR | |
6473 | @item DIRNAME_SEPARATOR | |
6474 | Evaluates to a character which separates directories in | |
6475 | @code{PATH}-style lists, typically held in environment variables. | |
6476 | This character is @samp{:} on Unix, @samp{;} on DOS and Windows. | |
6477 | ||
6478 | @findex SLASH_STRING | |
6479 | @item SLASH_STRING | |
6480 | This evaluates to a constant string you should use to produce an | |
6481 | absolute filename from leading directories and the file's basename. | |
6482 | @code{SLASH_STRING} is @code{"/"} on most systems, but might be | |
6483 | @code{"\\"} for some Windows-based ports. | |
6484 | @end table | |
6485 | ||
6486 | In addition to using these macros, be sure to use portable library | |
6487 | functions whenever possible. For example, to extract a directory or a | |
6488 | basename part from a file name, use the @code{dirname} and | |
6489 | @code{basename} library functions (available in @code{libiberty} for | |
6490 | platforms which don't provide them), instead of searching for a slash | |
6491 | with @code{strrchr}. | |
6492 | ||
25822942 DB |
6493 | Another way to generalize @value{GDBN} along a particular interface is with an |
6494 | attribute struct. For example, @value{GDBN} has been generalized to handle | |
56caf160 EZ |
6495 | multiple kinds of remote interfaces---not by @code{#ifdef}s everywhere, but |
6496 | by defining the @code{target_ops} structure and having a current target (as | |
c906108c SS |
6497 | well as a stack of targets below it, for memory references). Whenever |
6498 | something needs to be done that depends on which remote interface we are | |
56caf160 EZ |
6499 | using, a flag in the current target_ops structure is tested (e.g., |
6500 | @code{target_has_stack}), or a function is called through a pointer in the | |
c906108c | 6501 | current target_ops structure. In this way, when a new remote interface |
56caf160 | 6502 | is added, only one module needs to be touched---the one that actually |
c906108c SS |
6503 | implements the new remote interface. Other examples of |
6504 | attribute-structs are BFD access to multiple kinds of object file | |
25822942 | 6505 | formats, or @value{GDBN}'s access to multiple source languages. |
c906108c | 6506 | |
56caf160 EZ |
6507 | Please avoid duplicating code. For example, in @value{GDBN} 3.x all |
6508 | the code interfacing between @code{ptrace} and the rest of | |
6509 | @value{GDBN} was duplicated in @file{*-dep.c}, and so changing | |
6510 | something was very painful. In @value{GDBN} 4.x, these have all been | |
6511 | consolidated into @file{infptrace.c}. @file{infptrace.c} can deal | |
6512 | with variations between systems the same way any system-independent | |
6513 | file would (hooks, @code{#if defined}, etc.), and machines which are | |
6514 | radically different don't need to use @file{infptrace.c} at all. | |
c906108c | 6515 | |
af6c57ea AC |
6516 | All debugging code must be controllable using the @samp{set debug |
6517 | @var{module}} command. Do not use @code{printf} to print trace | |
6518 | messages. Use @code{fprintf_unfiltered(gdb_stdlog, ...}. Do not use | |
6519 | @code{#ifdef DEBUG}. | |
6520 | ||
8487521e | 6521 | @node Porting GDB |
c906108c | 6522 | |
25822942 | 6523 | @chapter Porting @value{GDBN} |
56caf160 | 6524 | @cindex porting to new machines |
c906108c | 6525 | |
56caf160 | 6526 | Most of the work in making @value{GDBN} compile on a new machine is in |
587afa38 EZ |
6527 | specifying the configuration of the machine. Porting a new |
6528 | architecture to @value{GDBN} can be broken into a number of steps. | |
c906108c | 6529 | |
56caf160 | 6530 | @itemize @bullet |
c906108c | 6531 | |
587afa38 EZ |
6532 | @item |
6533 | Ensure a @sc{bfd} exists for executables of the target architecture in | |
6534 | the @file{bfd} directory. If one does not exist, create one by | |
6535 | modifying an existing similar one. | |
56caf160 | 6536 | |
587afa38 EZ |
6537 | @item |
6538 | Implement a disassembler for the target architecture in the @file{opcodes} | |
6539 | directory. | |
56caf160 | 6540 | |
587afa38 EZ |
6541 | @item |
6542 | Define the target architecture in the @file{gdb} directory | |
6543 | (@pxref{Adding a New Target, , Adding a New Target}). Add the pattern | |
6544 | for the new target to @file{configure.tgt} with the names of the files | |
6545 | that contain the code. By convention the target architecture | |
6546 | definition for an architecture @var{arch} is placed in | |
6547 | @file{@var{arch}-tdep.c}. | |
6548 | ||
6549 | Within @file{@var{arch}-tdep.c} define the function | |
6550 | @code{_initialize_@var{arch}_tdep} which calls | |
6551 | @code{gdbarch_register} to create the new @code{@w{struct | |
6552 | gdbarch}} for the architecture. | |
56caf160 | 6553 | |
587afa38 EZ |
6554 | @item |
6555 | If a new remote target is needed, consider adding a new remote target | |
6556 | by defining a function | |
6557 | @code{_initialize_remote_@var{arch}}. However if at all possible | |
6558 | use the @value{GDBN} @emph{Remote Serial Protocol} for this and implement | |
6559 | the server side protocol independently with the target. | |
c906108c | 6560 | |
587afa38 EZ |
6561 | @item |
6562 | If desired implement a simulator in the @file{sim} directory. This | |
6563 | should create the library @file{libsim.a} implementing the interface | |
6564 | in @file{remote-sim.h} (found in the @file{include} directory). | |
c906108c | 6565 | |
56caf160 | 6566 | @item |
587afa38 EZ |
6567 | Build and test. If desired, lobby the @sc{gdb} steering group to |
6568 | have the new port included in the main distribution! | |
7fd60527 | 6569 | |
56caf160 | 6570 | @item |
587afa38 EZ |
6571 | Add a description of the new architecture to the main @value{GDBN} user |
6572 | guide (@pxref{Configuration Specific Information, , Configuration | |
6573 | Specific Information, gdb, Debugging with @value{GDBN}}). | |
6574 | ||
56caf160 | 6575 | @end itemize |
c906108c | 6576 | |
d52fe014 AC |
6577 | @node Versions and Branches |
6578 | @chapter Versions and Branches | |
8973da3a | 6579 | |
d52fe014 | 6580 | @section Versions |
8973da3a | 6581 | |
d52fe014 AC |
6582 | @value{GDBN}'s version is determined by the file |
6583 | @file{gdb/version.in} and takes one of the following forms: | |
fb0ff88f | 6584 | |
d52fe014 AC |
6585 | @table @asis |
6586 | @item @var{major}.@var{minor} | |
6587 | @itemx @var{major}.@var{minor}.@var{patchlevel} | |
53531fc1 AC |
6588 | an official release (e.g., 6.2 or 6.2.1) |
6589 | @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD} | |
6590 | a snapshot taken at @var{YYYY}-@var{MM}-@var{DD}-gmt (e.g., | |
6591 | 6.1.50.20020302, 6.1.90.20020304, or 6.1.0.20020308) | |
6592 | @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}-cvs | |
6593 | a @sc{cvs} check out drawn on @var{YYYY}-@var{MM}-@var{DD} (e.g., | |
6594 | 6.1.50.20020302-cvs, 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs) | |
6595 | @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD} (@var{vendor}) | |
d52fe014 | 6596 | a vendor specific release of @value{GDBN}, that while based on@* |
53531fc1 AC |
6597 | @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}, |
6598 | may include additional changes | |
d52fe014 | 6599 | @end table |
fb0ff88f | 6600 | |
d52fe014 AC |
6601 | @value{GDBN}'s mainline uses the @var{major} and @var{minor} version |
6602 | numbers from the most recent release branch, with a @var{patchlevel} | |
53531fc1 AC |
6603 | of 50. At the time each new release branch is created, the mainline's |
6604 | @var{major} and @var{minor} version numbers are updated. | |
fb0ff88f | 6605 | |
53531fc1 AC |
6606 | @value{GDBN}'s release branch is similar. When the branch is cut, the |
6607 | @var{patchlevel} is changed from 50 to 90. As draft releases are | |
6608 | drawn from the branch, the @var{patchlevel} is incremented. Once the | |
6609 | first release (@var{major}.@var{minor}) has been made, the | |
6610 | @var{patchlevel} is set to 0 and updates have an incremented | |
6611 | @var{patchlevel}. | |
6612 | ||
6613 | For snapshots, and @sc{cvs} check outs, it is also possible to | |
6614 | identify the @sc{cvs} origin: | |
6615 | ||
6616 | @table @asis | |
6617 | @item @var{major}.@var{minor}.50.@var{YYYY}@var{MM}@var{DD} | |
6618 | drawn from the @sc{head} of mainline @sc{cvs} (e.g., 6.1.50.20020302) | |
6619 | @item @var{major}.@var{minor}.90.@var{YYYY}@var{MM}@var{DD} | |
6620 | @itemx @var{major}.@var{minor}.91.@var{YYYY}@var{MM}@var{DD} @dots{} | |
6621 | drawn from a release branch prior to the release (e.g., | |
6622 | 6.1.90.20020304) | |
6623 | @item @var{major}.@var{minor}.0.@var{YYYY}@var{MM}@var{DD} | |
6624 | @itemx @var{major}.@var{minor}.1.@var{YYYY}@var{MM}@var{DD} @dots{} | |
6625 | drawn from a release branch after the release (e.g., 6.2.0.20020308) | |
6626 | @end table | |
fb0ff88f | 6627 | |
d52fe014 AC |
6628 | If the previous @value{GDBN} version is 6.1 and the current version is |
6629 | 6.2, then, substituting 6 for @var{major} and 1 or 2 for @var{minor}, | |
6630 | here's an illustration of a typical sequence: | |
fb0ff88f | 6631 | |
d52fe014 AC |
6632 | @smallexample |
6633 | <HEAD> | |
6634 | | | |
53531fc1 | 6635 | 6.1.50.20020302-cvs |
d52fe014 | 6636 | | |
53531fc1 | 6637 | +--------------------------. |
d52fe014 | 6638 | | <gdb_6_2-branch> |
d52fe014 | 6639 | | | |
53531fc1 AC |
6640 | 6.2.50.20020303-cvs 6.1.90 (draft #1) |
6641 | | | | |
6642 | 6.2.50.20020304-cvs 6.1.90.20020304-cvs | |
6643 | | | | |
6644 | 6.2.50.20020305-cvs 6.1.91 (draft #2) | |
d52fe014 | 6645 | | | |
53531fc1 AC |
6646 | 6.2.50.20020306-cvs 6.1.91.20020306-cvs |
6647 | | | | |
6648 | 6.2.50.20020307-cvs 6.2 (release) | |
6649 | | | | |
6650 | 6.2.50.20020308-cvs 6.2.0.20020308-cvs | |
6651 | | | | |
6652 | 6.2.50.20020309-cvs 6.2.1 (update) | |
6653 | | | | |
6654 | 6.2.50.20020310-cvs <branch closed> | |
d52fe014 | 6655 | | |
53531fc1 | 6656 | 6.2.50.20020311-cvs |
d52fe014 | 6657 | | |
53531fc1 | 6658 | +--------------------------. |
d52fe014 | 6659 | | <gdb_6_3-branch> |
53531fc1 AC |
6660 | | | |
6661 | 6.3.50.20020312-cvs 6.2.90 (draft #1) | |
6662 | | | | |
d52fe014 | 6663 | @end smallexample |
fb0ff88f | 6664 | |
d52fe014 AC |
6665 | @section Release Branches |
6666 | @cindex Release Branches | |
fb0ff88f | 6667 | |
d52fe014 AC |
6668 | @value{GDBN} draws a release series (6.2, 6.2.1, @dots{}) from a |
6669 | single release branch, and identifies that branch using the @sc{cvs} | |
6670 | branch tags: | |
fb0ff88f | 6671 | |
d52fe014 AC |
6672 | @smallexample |
6673 | gdb_@var{major}_@var{minor}-@var{YYYY}@var{MM}@var{DD}-branchpoint | |
6674 | gdb_@var{major}_@var{minor}-branch | |
6675 | gdb_@var{major}_@var{minor}-@var{YYYY}@var{MM}@var{DD}-release | |
6676 | @end smallexample | |
6677 | ||
6678 | @emph{Pragmatics: To help identify the date at which a branch or | |
6679 | release is made, both the branchpoint and release tags include the | |
6680 | date that they are cut (@var{YYYY}@var{MM}@var{DD}) in the tag. The | |
6681 | branch tag, denoting the head of the branch, does not need this.} | |
6682 | ||
6683 | @section Vendor Branches | |
6684 | @cindex vendor branches | |
fb0ff88f AC |
6685 | |
6686 | To avoid version conflicts, vendors are expected to modify the file | |
6687 | @file{gdb/version.in} to include a vendor unique alphabetic identifier | |
6688 | (an official @value{GDBN} release never uses alphabetic characters in | |
d3e8051b | 6689 | its version identifier). E.g., @samp{6.2widgit2}, or @samp{6.2 (Widgit |
d52fe014 AC |
6690 | Inc Patch 2)}. |
6691 | ||
6692 | @section Experimental Branches | |
6693 | @cindex experimental branches | |
6694 | ||
6695 | @subsection Guidelines | |
6696 | ||
6697 | @value{GDBN} permits the creation of branches, cut from the @sc{cvs} | |
6698 | repository, for experimental development. Branches make it possible | |
6699 | for developers to share preliminary work, and maintainers to examine | |
6700 | significant new developments. | |
fb0ff88f | 6701 | |
d52fe014 | 6702 | The following are a set of guidelines for creating such branches: |
fb0ff88f | 6703 | |
d52fe014 AC |
6704 | @table @emph |
6705 | ||
6706 | @item a branch has an owner | |
6707 | The owner can set further policy for a branch, but may not change the | |
6708 | ground rules. In particular, they can set a policy for commits (be it | |
6709 | adding more reviewers or deciding who can commit). | |
6710 | ||
6711 | @item all commits are posted | |
6712 | All changes committed to a branch shall also be posted to | |
87f9adc1 | 6713 | @email{gdb-patches@@sourceware.org, the @value{GDBN} patches |
d52fe014 AC |
6714 | mailing list}. While commentary on such changes are encouraged, people |
6715 | should remember that the changes only apply to a branch. | |
6716 | ||
6717 | @item all commits are covered by an assignment | |
6718 | This ensures that all changes belong to the Free Software Foundation, | |
6719 | and avoids the possibility that the branch may become contaminated. | |
6720 | ||
6721 | @item a branch is focused | |
6722 | A focused branch has a single objective or goal, and does not contain | |
6723 | unnecessary or irrelevant changes. Cleanups, where identified, being | |
6724 | be pushed into the mainline as soon as possible. | |
6725 | ||
6726 | @item a branch tracks mainline | |
6727 | This keeps the level of divergence under control. It also keeps the | |
6728 | pressure on developers to push cleanups and other stuff into the | |
6729 | mainline. | |
6730 | ||
6731 | @item a branch shall contain the entire @value{GDBN} module | |
6732 | The @value{GDBN} module @code{gdb} should be specified when creating a | |
6733 | branch (branches of individual files should be avoided). @xref{Tags}. | |
6734 | ||
6735 | @item a branch shall be branded using @file{version.in} | |
6736 | The file @file{gdb/version.in} shall be modified so that it identifies | |
6737 | the branch @var{owner} and branch @var{name}, e.g., | |
53531fc1 | 6738 | @samp{6.2.50.20030303_owner_name} or @samp{6.2 (Owner Name)}. |
d52fe014 AC |
6739 | |
6740 | @end table | |
fb0ff88f | 6741 | |
d52fe014 AC |
6742 | @subsection Tags |
6743 | @anchor{Tags} | |
fb0ff88f | 6744 | |
d52fe014 AC |
6745 | To simplify the identification of @value{GDBN} branches, the following |
6746 | branch tagging convention is strongly recommended: | |
fb0ff88f | 6747 | |
d52fe014 | 6748 | @table @code |
fb0ff88f | 6749 | |
d52fe014 AC |
6750 | @item @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint |
6751 | @itemx @var{owner}_@var{name}-@var{YYYYMMDD}-branch | |
6752 | The branch point and corresponding branch tag. @var{YYYYMMDD} is the | |
6753 | date that the branch was created. A branch is created using the | |
6754 | sequence: @anchor{experimental branch tags} | |
474c8240 | 6755 | @smallexample |
d52fe014 AC |
6756 | cvs rtag @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint gdb |
6757 | cvs rtag -b -r @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint \ | |
6758 | @var{owner}_@var{name}-@var{YYYYMMDD}-branch gdb | |
474c8240 | 6759 | @end smallexample |
fb0ff88f | 6760 | |
d52fe014 AC |
6761 | @item @var{owner}_@var{name}-@var{yyyymmdd}-mergepoint |
6762 | The tagged point, on the mainline, that was used when merging the branch | |
6763 | on @var{yyyymmdd}. To merge in all changes since the branch was cut, | |
6764 | use a command sequence like: | |
474c8240 | 6765 | @smallexample |
d52fe014 AC |
6766 | cvs rtag @var{owner}_@var{name}-@var{yyyymmdd}-mergepoint gdb |
6767 | cvs update \ | |
6768 | -j@var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint | |
6769 | -j@var{owner}_@var{name}-@var{yyyymmdd}-mergepoint | |
474c8240 | 6770 | @end smallexample |
d52fe014 AC |
6771 | @noindent |
6772 | Similar sequences can be used to just merge in changes since the last | |
6773 | merge. | |
6774 | ||
6775 | @end table | |
fb0ff88f | 6776 | |
d52fe014 AC |
6777 | @noindent |
6778 | For further information on @sc{cvs}, see | |
6779 | @uref{http://www.gnu.org/software/cvs/, Concurrent Versions System}. | |
6780 | ||
55f6ca0f JB |
6781 | @node Start of New Year Procedure |
6782 | @chapter Start of New Year Procedure | |
6783 | @cindex new year procedure | |
6784 | ||
6785 | At the start of each new year, the following actions should be performed: | |
6786 | ||
6787 | @itemize @bullet | |
6788 | @item | |
6789 | Rotate the ChangeLog file | |
6790 | ||
6791 | The current @file{ChangeLog} file should be renamed into | |
6792 | @file{ChangeLog-YYYY} where YYYY is the year that has just passed. | |
6793 | A new @file{ChangeLog} file should be created, and its contents should | |
6794 | contain a reference to the previous ChangeLog. The following should | |
6795 | also be preserved at the end of the new ChangeLog, in order to provide | |
6796 | the appropriate settings when editing this file with Emacs: | |
6797 | @smallexample | |
6798 | Local Variables: | |
6799 | mode: change-log | |
6800 | left-margin: 8 | |
6801 | fill-column: 74 | |
6802 | version-control: never | |
9cb011d3 | 6803 | coding: utf-8 |
55f6ca0f JB |
6804 | End: |
6805 | @end smallexample | |
6806 | ||
7f893741 JB |
6807 | @item |
6808 | Add an entry for the newly created ChangeLog file (@file{ChangeLog-YYYY}) | |
6809 | in @file{gdb/config/djgpp/fnchange.lst}. | |
6810 | ||
55f6ca0f JB |
6811 | @item |
6812 | Update the copyright year in the startup message | |
6813 | ||
9cb011d3 JB |
6814 | Update the copyright year in: |
6815 | @itemize @bullet | |
e6f3ec50 JB |
6816 | @item |
6817 | file @file{top.c}, function @code{print_gdb_version} | |
6818 | @item | |
6819 | file @file{gdbserver/server.c}, function @code{gdbserver_version} | |
6820 | @item | |
6821 | file @file{gdbserver/gdbreplay.c}, function @code{gdbreplay_version} | |
9cb011d3 | 6822 | @end itemize |
6ec2edbe JB |
6823 | |
6824 | @item | |
ce1b17c4 JB |
6825 | Run the @file{copyright.py} Python script to add the new year in the copyright |
6826 | notices of most source files. This script has been tested with Python | |
6827 | 2.6 and 2.7. | |
6ec2edbe | 6828 | |
55f6ca0f JB |
6829 | @end itemize |
6830 | ||
d52fe014 | 6831 | @node Releasing GDB |
fb0ff88f | 6832 | |
d52fe014 AC |
6833 | @chapter Releasing @value{GDBN} |
6834 | @cindex making a new release of gdb | |
fb0ff88f | 6835 | |
9bb0a4d8 AC |
6836 | @section Branch Commit Policy |
6837 | ||
6838 | The branch commit policy is pretty slack. @value{GDBN} releases 5.0, | |
6839 | 5.1 and 5.2 all used the below: | |
6840 | ||
6841 | @itemize @bullet | |
6842 | @item | |
6843 | The @file{gdb/MAINTAINERS} file still holds. | |
6844 | @item | |
6845 | Don't fix something on the branch unless/until it is also fixed in the | |
6846 | trunk. If this isn't possible, mentioning it in the @file{gdb/PROBLEMS} | |
4be31470 | 6847 | file is better than committing a hack. |
9bb0a4d8 AC |
6848 | @item |
6849 | When considering a patch for the branch, suggested criteria include: | |
6850 | Does it fix a build? Does it fix the sequence @kbd{break main; run} | |
6851 | when debugging a static binary? | |
6852 | @item | |
6853 | The further a change is from the core of @value{GDBN}, the less likely | |
6854 | the change will worry anyone (e.g., target specific code). | |
6855 | @item | |
6856 | Only post a proposal to change the core of @value{GDBN} after you've | |
6857 | sent individual bribes to all the people listed in the | |
6858 | @file{MAINTAINERS} file @t{;-)} | |
6859 | @end itemize | |
6860 | ||
6861 | @emph{Pragmatics: Provided updates are restricted to non-core | |
6862 | functionality there is little chance that a broken change will be fatal. | |
6863 | This means that changes such as adding a new architectures or (within | |
6864 | reason) support for a new host are considered acceptable.} | |
6865 | ||
6866 | ||
cbb09e6a | 6867 | @section Obsoleting code |
8973da3a | 6868 | |
8642bc8f | 6869 | Before anything else, poke the other developers (and around the source |
4be31470 EZ |
6870 | code) to see if there is anything that can be removed from @value{GDBN} |
6871 | (an old target, an unused file). | |
8973da3a | 6872 | |
8642bc8f | 6873 | Obsolete code is identified by adding an @code{OBSOLETE} prefix to every |
cbb09e6a AC |
6874 | line. Doing this means that it is easy to identify something that has |
6875 | been obsoleted when greping through the sources. | |
8973da3a | 6876 | |
cbb09e6a AC |
6877 | The process is done in stages --- this is mainly to ensure that the |
6878 | wider @value{GDBN} community has a reasonable opportunity to respond. | |
6879 | Remember, everything on the Internet takes a week. | |
8973da3a | 6880 | |
cbb09e6a | 6881 | @enumerate |
8973da3a | 6882 | @item |
87f9adc1 | 6883 | Post the proposal on @email{gdb@@sourceware.org, the GDB mailing |
cbb09e6a AC |
6884 | list} Creating a bug report to track the task's state, is also highly |
6885 | recommended. | |
8973da3a | 6886 | @item |
cbb09e6a | 6887 | Wait a week or so. |
8973da3a | 6888 | @item |
87f9adc1 | 6889 | Post the proposal on @email{gdb-announce@@sourceware.org, the GDB |
cbb09e6a | 6890 | Announcement mailing list}. |
8973da3a | 6891 | @item |
cbb09e6a | 6892 | Wait a week or so. |
8973da3a | 6893 | @item |
cbb09e6a AC |
6894 | Go through and edit all relevant files and lines so that they are |
6895 | prefixed with the word @code{OBSOLETE}. | |
6896 | @item | |
6897 | Wait until the next GDB version, containing this obsolete code, has been | |
6898 | released. | |
6899 | @item | |
6900 | Remove the obsolete code. | |
6901 | @end enumerate | |
6902 | ||
6903 | @noindent | |
6904 | @emph{Maintainer note: While removing old code is regrettable it is | |
6905 | hopefully better for @value{GDBN}'s long term development. Firstly it | |
6906 | helps the developers by removing code that is either no longer relevant | |
6907 | or simply wrong. Secondly since it removes any history associated with | |
6908 | the file (effectively clearing the slate) the developer has a much freer | |
6909 | hand when it comes to fixing broken files.} | |
8973da3a | 6910 | |
8973da3a | 6911 | |
9ae8b82c AC |
6912 | |
6913 | @section Before the Branch | |
8973da3a | 6914 | |
8642bc8f AC |
6915 | The most important objective at this stage is to find and fix simple |
6916 | changes that become a pain to track once the branch is created. For | |
6917 | instance, configuration problems that stop @value{GDBN} from even | |
6918 | building. If you can't get the problem fixed, document it in the | |
6919 | @file{gdb/PROBLEMS} file. | |
8973da3a | 6920 | |
9ae8b82c | 6921 | @subheading Prompt for @file{gdb/NEWS} |
8973da3a | 6922 | |
9ae8b82c AC |
6923 | People always forget. Send a post reminding them but also if you know |
6924 | something interesting happened add it yourself. The @code{schedule} | |
6925 | script will mention this in its e-mail. | |
8973da3a | 6926 | |
9ae8b82c | 6927 | @subheading Review @file{gdb/README} |
8973da3a | 6928 | |
9ae8b82c AC |
6929 | Grab one of the nightly snapshots and then walk through the |
6930 | @file{gdb/README} looking for anything that can be improved. The | |
6931 | @code{schedule} script will mention this in its e-mail. | |
8642bc8f AC |
6932 | |
6933 | @subheading Refresh any imported files. | |
8973da3a | 6934 | |
8642bc8f | 6935 | A number of files are taken from external repositories. They include: |
8973da3a | 6936 | |
8642bc8f AC |
6937 | @itemize @bullet |
6938 | @item | |
6939 | @file{texinfo/texinfo.tex} | |
6940 | @item | |
9ae8b82c AC |
6941 | @file{config.guess} et.@: al.@: (see the top-level @file{MAINTAINERS} |
6942 | file) | |
6943 | @item | |
6944 | @file{etc/standards.texi}, @file{etc/make-stds.texi} | |
8642bc8f AC |
6945 | @end itemize |
6946 | ||
9ae8b82c | 6947 | @subheading Check the ARI |
8642bc8f | 6948 | |
87f9adc1 | 6949 | @uref{http://sourceware.org/gdb/ari,,A.R.I.} is an @code{awk} script |
9ae8b82c AC |
6950 | (Awk Regression Index ;-) that checks for a number of errors and coding |
6951 | conventions. The checks include things like using @code{malloc} instead | |
6952 | of @code{xmalloc} and file naming problems. There shouldn't be any | |
6953 | regressions. | |
8642bc8f | 6954 | |
9ae8b82c | 6955 | @subsection Review the bug data base |
8642bc8f | 6956 | |
9ae8b82c | 6957 | Close anything obviously fixed. |
8642bc8f | 6958 | |
9ae8b82c | 6959 | @subsection Check all cross targets build |
8642bc8f | 6960 | |
9ae8b82c | 6961 | The targets are listed in @file{gdb/MAINTAINERS}. |
8642bc8f | 6962 | |
8642bc8f | 6963 | |
30107679 | 6964 | @section Cut the Branch |
8642bc8f | 6965 | |
30107679 | 6966 | @subheading Create the branch |
8642bc8f | 6967 | |
474c8240 | 6968 | @smallexample |
30107679 AC |
6969 | $ u=5.1 |
6970 | $ v=5.2 | |
6971 | $ V=`echo $v | sed 's/\./_/g'` | |
6972 | $ D=`date -u +%Y-%m-%d` | |
6973 | $ echo $u $V $D | |
6974 | 5.1 5_2 2002-03-03 | |
87f9adc1 | 6975 | $ echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \ |
b247355e | 6976 | -D $D-gmt gdb_$V-$D-branchpoint insight |
87f9adc1 | 6977 | cvs -f -d :ext:sourceware.org:/cvs/src rtag |
b247355e | 6978 | -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight |
30107679 AC |
6979 | $ ^echo ^^ |
6980 | ... | |
87f9adc1 | 6981 | $ echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \ |
b247355e | 6982 | -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight |
87f9adc1 | 6983 | cvs -f -d :ext:sourceware.org:/cvs/src rtag \ |
b247355e | 6984 | -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight |
30107679 AC |
6985 | $ ^echo ^^ |
6986 | ... | |
8642bc8f | 6987 | $ |
474c8240 | 6988 | @end smallexample |
8642bc8f AC |
6989 | |
6990 | @itemize @bullet | |
6991 | @item | |
b247355e | 6992 | By using @kbd{-D YYYY-MM-DD-gmt}, the branch is forced to an exact |
30107679 AC |
6993 | date/time. |
6994 | @item | |
b247355e | 6995 | The trunk is first tagged so that the branch point can easily be found. |
30107679 | 6996 | @item |
b247355e | 6997 | Insight, which includes @value{GDBN}, is tagged at the same time. |
8642bc8f | 6998 | @item |
b247355e | 6999 | @file{version.in} gets bumped to avoid version number conflicts. |
8642bc8f | 7000 | @item |
b247355e | 7001 | The reading of @file{.cvsrc} is disabled using @file{-f}. |
30107679 AC |
7002 | @end itemize |
7003 | ||
7004 | @subheading Update @file{version.in} | |
7005 | ||
7006 | @smallexample | |
7007 | $ u=5.1 | |
7008 | $ v=5.2 | |
7009 | $ V=`echo $v | sed 's/\./_/g'` | |
7010 | $ echo $u $v$V | |
7011 | 5.1 5_2 | |
7012 | $ cd /tmp | |
87f9adc1 | 7013 | $ echo cvs -f -d :ext:sourceware.org:/cvs/src co \ |
30107679 | 7014 | -r gdb_$V-branch src/gdb/version.in |
87f9adc1 | 7015 | cvs -f -d :ext:sourceware.org:/cvs/src co |
30107679 AC |
7016 | -r gdb_5_2-branch src/gdb/version.in |
7017 | $ ^echo ^^ | |
7018 | U src/gdb/version.in | |
7019 | $ cd src/gdb | |
7020 | $ echo $u.90-0000-00-00-cvs > version.in | |
7021 | $ cat version.in | |
7022 | 5.1.90-0000-00-00-cvs | |
7023 | $ cvs -f commit version.in | |
7024 | @end smallexample | |
7025 | ||
7026 | @itemize @bullet | |
7027 | @item | |
7028 | @file{0000-00-00} is used as a date to pump prime the version.in update | |
b247355e | 7029 | mechanism. |
30107679 AC |
7030 | @item |
7031 | @file{.90} and the previous branch version are used as fairly arbitrary | |
b247355e | 7032 | initial branch version number. |
8642bc8f AC |
7033 | @end itemize |
7034 | ||
8642bc8f AC |
7035 | |
7036 | @subheading Update the web and news pages | |
7037 | ||
30107679 AC |
7038 | Something? |
7039 | ||
8642bc8f AC |
7040 | @subheading Tweak cron to track the new branch |
7041 | ||
30107679 AC |
7042 | The file @file{gdbadmin/cron/crontab} contains gdbadmin's cron table. |
7043 | This file needs to be updated so that: | |
7044 | ||
7045 | @itemize @bullet | |
7046 | @item | |
b247355e | 7047 | A daily timestamp is added to the file @file{version.in}. |
30107679 | 7048 | @item |
b247355e | 7049 | The new branch is included in the snapshot process. |
30107679 AC |
7050 | @end itemize |
7051 | ||
7052 | @noindent | |
7053 | See the file @file{gdbadmin/cron/README} for how to install the updated | |
7054 | cron table. | |
7055 | ||
7056 | The file @file{gdbadmin/ss/README} should also be reviewed to reflect | |
7057 | any changes. That file is copied to both the branch/ and current/ | |
7058 | snapshot directories. | |
7059 | ||
7060 | ||
7061 | @subheading Update the NEWS and README files | |
7062 | ||
7063 | The @file{NEWS} file needs to be updated so that on the branch it refers | |
7064 | to @emph{changes in the current release} while on the trunk it also | |
7065 | refers to @emph{changes since the current release}. | |
7066 | ||
7067 | The @file{README} file needs to be updated so that it refers to the | |
7068 | current release. | |
7069 | ||
7070 | @subheading Post the branch info | |
7071 | ||
7072 | Send an announcement to the mailing lists: | |
7073 | ||
7074 | @itemize @bullet | |
7075 | @item | |
87f9adc1 | 7076 | @email{gdb-announce@@sourceware.org, GDB Announcement mailing list} |
30107679 | 7077 | @item |
87f9adc1 PM |
7078 | @email{gdb@@sourceware.org, GDB Discussion mailing list} and |
7079 | @email{gdb-testers@@sourceware.org, GDB Testers mailing list} | |
16737d73 | 7080 | @end itemize |
30107679 AC |
7081 | |
7082 | @emph{Pragmatics: The branch creation is sent to the announce list to | |
7083 | ensure that people people not subscribed to the higher volume discussion | |
7084 | list are alerted.} | |
7085 | ||
7086 | The announcement should include: | |
7087 | ||
7088 | @itemize @bullet | |
7089 | @item | |
b247355e | 7090 | The branch tag. |
30107679 | 7091 | @item |
b247355e | 7092 | How to check out the branch using CVS. |
30107679 | 7093 | @item |
b247355e | 7094 | The date/number of weeks until the release. |
30107679 | 7095 | @item |
b247355e | 7096 | The branch commit policy still holds. |
16737d73 | 7097 | @end itemize |
30107679 | 7098 | |
8642bc8f AC |
7099 | @section Stabilize the branch |
7100 | ||
7101 | Something goes here. | |
7102 | ||
7103 | @section Create a Release | |
7104 | ||
0816590b AC |
7105 | The process of creating and then making available a release is broken |
7106 | down into a number of stages. The first part addresses the technical | |
7107 | process of creating a releasable tar ball. The later stages address the | |
7108 | process of releasing that tar ball. | |
8973da3a | 7109 | |
0816590b AC |
7110 | When making a release candidate just the first section is needed. |
7111 | ||
7112 | @subsection Create a release candidate | |
7113 | ||
7114 | The objective at this stage is to create a set of tar balls that can be | |
7115 | made available as a formal release (or as a less formal release | |
7116 | candidate). | |
7117 | ||
7118 | @subsubheading Freeze the branch | |
7119 | ||
7120 | Send out an e-mail notifying everyone that the branch is frozen to | |
87f9adc1 | 7121 | @email{gdb-patches@@sourceware.org}. |
0816590b AC |
7122 | |
7123 | @subsubheading Establish a few defaults. | |
8973da3a | 7124 | |
474c8240 | 7125 | @smallexample |
0816590b AC |
7126 | $ b=gdb_5_2-branch |
7127 | $ v=5.2 | |
8642bc8f AC |
7128 | $ t=/sourceware/snapshot-tmp/gdbadmin-tmp |
7129 | $ echo $t/$b/$v | |
0816590b | 7130 | /sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2 |
8642bc8f AC |
7131 | $ mkdir -p $t/$b/$v |
7132 | $ cd $t/$b/$v | |
7133 | $ pwd | |
0816590b | 7134 | /sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2 |
8973da3a AC |
7135 | $ which autoconf |
7136 | /home/gdbadmin/bin/autoconf | |
8642bc8f | 7137 | $ |
474c8240 | 7138 | @end smallexample |
8973da3a | 7139 | |
0816590b AC |
7140 | @noindent |
7141 | Notes: | |
8973da3a | 7142 | |
0816590b AC |
7143 | @itemize @bullet |
7144 | @item | |
7145 | Check the @code{autoconf} version carefully. You want to be using the | |
af542c2e | 7146 | version documented in the toplevel @file{README-maintainer-mode} file. |
bc3a0b4d RW |
7147 | It is very unlikely that the version of @code{autoconf} installed in |
7148 | system directories (e.g., @file{/usr/bin/autoconf}) is correct. | |
0816590b AC |
7149 | @end itemize |
7150 | ||
7151 | @subsubheading Check out the relevant modules: | |
8973da3a | 7152 | |
474c8240 | 7153 | @smallexample |
b247355e | 7154 | $ for m in gdb insight |
8642bc8f | 7155 | do |
8973da3a AC |
7156 | ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m ) |
7157 | done | |
8642bc8f | 7158 | $ |
474c8240 | 7159 | @end smallexample |
8973da3a | 7160 | |
0816590b AC |
7161 | @noindent |
7162 | Note: | |
8642bc8f | 7163 | |
0816590b AC |
7164 | @itemize @bullet |
7165 | @item | |
7166 | The reading of @file{.cvsrc} is disabled (@file{-f}) so that there isn't | |
7167 | any confusion between what is written here and what your local | |
7168 | @code{cvs} really does. | |
7169 | @end itemize | |
7170 | ||
7171 | @subsubheading Update relevant files. | |
8973da3a | 7172 | |
0816590b AC |
7173 | @table @file |
7174 | ||
7175 | @item gdb/NEWS | |
8642bc8f AC |
7176 | |
7177 | Major releases get their comments added as part of the mainline. Minor | |
7178 | releases should probably mention any significant bugs that were fixed. | |
7179 | ||
0816590b | 7180 | Don't forget to include the @file{ChangeLog} entry. |
8973da3a | 7181 | |
474c8240 | 7182 | @smallexample |
8642bc8f AC |
7183 | $ emacs gdb/src/gdb/NEWS |
7184 | ... | |
7185 | c-x 4 a | |
7186 | ... | |
7187 | c-x c-s c-x c-c | |
7188 | $ cp gdb/src/gdb/NEWS insight/src/gdb/NEWS | |
7189 | $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog | |
474c8240 | 7190 | @end smallexample |
8973da3a | 7191 | |
0816590b AC |
7192 | @item gdb/README |
7193 | ||
7194 | You'll need to update: | |
8973da3a | 7195 | |
0816590b AC |
7196 | @itemize @bullet |
7197 | @item | |
b247355e | 7198 | The version. |
0816590b | 7199 | @item |
b247355e | 7200 | The update date. |
0816590b | 7201 | @item |
b247355e | 7202 | Who did it. |
0816590b | 7203 | @end itemize |
8973da3a | 7204 | |
474c8240 | 7205 | @smallexample |
8642bc8f AC |
7206 | $ emacs gdb/src/gdb/README |
7207 | ... | |
8973da3a | 7208 | c-x 4 a |
8642bc8f | 7209 | ... |
8973da3a | 7210 | c-x c-s c-x c-c |
8642bc8f AC |
7211 | $ cp gdb/src/gdb/README insight/src/gdb/README |
7212 | $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog | |
474c8240 | 7213 | @end smallexample |
8973da3a | 7214 | |
0816590b AC |
7215 | @emph{Maintainer note: Hopefully the @file{README} file was reviewed |
7216 | before the initial branch was cut so just a simple substitute is needed | |
7217 | to get it updated.} | |
8973da3a | 7218 | |
8642bc8f AC |
7219 | @emph{Maintainer note: Other projects generate @file{README} and |
7220 | @file{INSTALL} from the core documentation. This might be worth | |
7221 | pursuing.} | |
8973da3a | 7222 | |
0816590b | 7223 | @item gdb/version.in |
8973da3a | 7224 | |
474c8240 | 7225 | @smallexample |
8642bc8f | 7226 | $ echo $v > gdb/src/gdb/version.in |
0816590b AC |
7227 | $ cat gdb/src/gdb/version.in |
7228 | 5.2 | |
8642bc8f | 7229 | $ emacs gdb/src/gdb/version.in |
8973da3a AC |
7230 | ... |
7231 | c-x 4 a | |
0816590b | 7232 | ... Bump to version ... |
8973da3a | 7233 | c-x c-s c-x c-c |
8642bc8f AC |
7234 | $ cp gdb/src/gdb/version.in insight/src/gdb/version.in |
7235 | $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog | |
474c8240 | 7236 | @end smallexample |
8973da3a | 7237 | |
0816590b AC |
7238 | @end table |
7239 | ||
7240 | @subsubheading Do the dirty work | |
7241 | ||
7242 | This is identical to the process used to create the daily snapshot. | |
8973da3a | 7243 | |
4ce8657e MC |
7244 | @smallexample |
7245 | $ for m in gdb insight | |
7246 | do | |
7247 | ( cd $m/src && gmake -f src-release $m.tar ) | |
7248 | done | |
4ce8657e MC |
7249 | @end smallexample |
7250 | ||
7251 | If the top level source directory does not have @file{src-release} | |
7252 | (@value{GDBN} version 5.3.1 or earlier), try these commands instead: | |
7253 | ||
474c8240 | 7254 | @smallexample |
0816590b | 7255 | $ for m in gdb insight |
8642bc8f | 7256 | do |
0816590b | 7257 | ( cd $m/src && gmake -f Makefile.in $m.tar ) |
8973da3a | 7258 | done |
474c8240 | 7259 | @end smallexample |
8973da3a | 7260 | |
0816590b | 7261 | @subsubheading Check the source files |
8642bc8f | 7262 | |
0816590b | 7263 | You're looking for files that have mysteriously disappeared. |
8642bc8f AC |
7264 | @kbd{distclean} has the habit of deleting files it shouldn't. Watch out |
7265 | for the @file{version.in} update @kbd{cronjob}. | |
8973da3a | 7266 | |
474c8240 | 7267 | @smallexample |
8642bc8f AC |
7268 | $ ( cd gdb/src && cvs -f -q -n update ) |
7269 | M djunpack.bat | |
0816590b | 7270 | ? gdb-5.1.91.tar |
8642bc8f | 7271 | ? proto-toplev |
0816590b | 7272 | @dots{} lots of generated files @dots{} |
8642bc8f AC |
7273 | M gdb/ChangeLog |
7274 | M gdb/NEWS | |
7275 | M gdb/README | |
7276 | M gdb/version.in | |
0816590b | 7277 | @dots{} lots of generated files @dots{} |
8642bc8f | 7278 | $ |
474c8240 | 7279 | @end smallexample |
8973da3a | 7280 | |
0816590b | 7281 | @noindent |
8642bc8f AC |
7282 | @emph{Don't worry about the @file{gdb.info-??} or |
7283 | @file{gdb/p-exp.tab.c}. They were generated (and yes @file{gdb.info-1} | |
7284 | was also generated only something strange with CVS means that they | |
d3e8051b | 7285 | didn't get suppressed). Fixing it would be nice though.} |
8973da3a | 7286 | |
0816590b | 7287 | @subsubheading Create compressed versions of the release |
8973da3a | 7288 | |
474c8240 | 7289 | @smallexample |
0816590b AC |
7290 | $ cp */src/*.tar . |
7291 | $ cp */src/*.bz2 . | |
7292 | $ ls -F | |
b247355e | 7293 | gdb/ gdb-5.2.tar insight/ insight-5.2.tar |
0816590b AC |
7294 | $ for m in gdb insight |
7295 | do | |
7296 | bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2 | |
7297 | gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz | |
7298 | done | |
7299 | $ | |
474c8240 | 7300 | @end smallexample |
8973da3a | 7301 | |
0816590b AC |
7302 | @noindent |
7303 | Note: | |
7304 | ||
7305 | @itemize @bullet | |
7306 | @item | |
7307 | A pipe such as @kbd{bunzip2 < xxx.bz2 | gzip -9 > xxx.gz} is not since, | |
7308 | in that mode, @code{gzip} does not know the name of the file and, hence, | |
7309 | can not include it in the compressed file. This is also why the release | |
7310 | process runs @code{tar} and @code{bzip2} as separate passes. | |
7311 | @end itemize | |
7312 | ||
7313 | @subsection Sanity check the tar ball | |
8973da3a | 7314 | |
0816590b | 7315 | Pick a popular machine (Solaris/PPC?) and try the build on that. |
8973da3a | 7316 | |
0816590b AC |
7317 | @smallexample |
7318 | $ bunzip2 < gdb-5.2.tar.bz2 | tar xpf - | |
7319 | $ cd gdb-5.2 | |
7320 | $ ./configure | |
7321 | $ make | |
7322 | @dots{} | |
7323 | $ ./gdb/gdb ./gdb/gdb | |
7324 | GNU gdb 5.2 | |
7325 | @dots{} | |
7326 | (gdb) b main | |
7327 | Breakpoint 1 at 0x80732bc: file main.c, line 734. | |
7328 | (gdb) run | |
7329 | Starting program: /tmp/gdb-5.2/gdb/gdb | |
7330 | ||
7331 | Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734 | |
7332 | 734 catch_errors (captured_main, &args, "", RETURN_MASK_ALL); | |
7333 | (gdb) print args | |
7334 | $1 = @{argc = 136426532, argv = 0x821b7f0@} | |
7335 | (gdb) | |
7336 | @end smallexample | |
8973da3a | 7337 | |
0816590b | 7338 | @subsection Make a release candidate available |
8973da3a | 7339 | |
0816590b | 7340 | If this is a release candidate then the only remaining steps are: |
8642bc8f | 7341 | |
0816590b AC |
7342 | @enumerate |
7343 | @item | |
7344 | Commit @file{version.in} and @file{ChangeLog} | |
7345 | @item | |
7346 | Tweak @file{version.in} (and @file{ChangeLog} to read | |
7347 | @var{L}.@var{M}.@var{N}-0000-00-00-cvs so that the version update | |
7348 | process can restart. | |
7349 | @item | |
7350 | Make the release candidate available in | |
87f9adc1 | 7351 | @uref{ftp://sourceware.org/pub/gdb/snapshots/branch} |
0816590b | 7352 | @item |
87f9adc1 PM |
7353 | Notify the relevant mailing lists ( @email{gdb@@sourceware.org} and |
7354 | @email{gdb-testers@@sourceware.org} that the candidate is available. | |
0816590b | 7355 | @end enumerate |
8642bc8f | 7356 | |
0816590b | 7357 | @subsection Make a formal release available |
8642bc8f | 7358 | |
0816590b | 7359 | (And you thought all that was required was to post an e-mail.) |
8642bc8f | 7360 | |
0816590b | 7361 | @subsubheading Install on sware |
8642bc8f | 7362 | |
0816590b | 7363 | Copy the new files to both the release and the old release directory: |
8642bc8f | 7364 | |
474c8240 | 7365 | @smallexample |
0816590b | 7366 | $ cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/ |
8642bc8f | 7367 | $ cp *.bz2 *.gz ~ftp/pub/gdb/releases |
474c8240 | 7368 | @end smallexample |
8642bc8f | 7369 | |
0816590b AC |
7370 | @noindent |
7371 | Clean up the releases directory so that only the most recent releases | |
587afa38 | 7372 | are available (e.g.@: keep 5.2 and 5.2.1 but remove 5.1): |
0816590b AC |
7373 | |
7374 | @smallexample | |
7375 | $ cd ~ftp/pub/gdb/releases | |
7376 | $ rm @dots{} | |
7377 | @end smallexample | |
7378 | ||
7379 | @noindent | |
7380 | Update the file @file{README} and @file{.message} in the releases | |
7381 | directory: | |
7382 | ||
7383 | @smallexample | |
7384 | $ vi README | |
7385 | @dots{} | |
7386 | $ rm -f .message | |
7387 | $ ln README .message | |
7388 | @end smallexample | |
8642bc8f | 7389 | |
0816590b | 7390 | @subsubheading Update the web pages. |
8973da3a | 7391 | |
0816590b AC |
7392 | @table @file |
7393 | ||
7394 | @item htdocs/download/ANNOUNCEMENT | |
7395 | This file, which is posted as the official announcement, includes: | |
8973da3a AC |
7396 | @itemize @bullet |
7397 | @item | |
b247355e | 7398 | General announcement. |
8642bc8f | 7399 | @item |
0816590b AC |
7400 | News. If making an @var{M}.@var{N}.1 release, retain the news from |
7401 | earlier @var{M}.@var{N} release. | |
8973da3a | 7402 | @item |
b247355e | 7403 | Errata. |
0816590b AC |
7404 | @end itemize |
7405 | ||
7406 | @item htdocs/index.html | |
7407 | @itemx htdocs/news/index.html | |
7408 | @itemx htdocs/download/index.html | |
7409 | These files include: | |
7410 | @itemize @bullet | |
8642bc8f | 7411 | @item |
b247355e | 7412 | Announcement of the most recent release. |
8642bc8f | 7413 | @item |
b247355e | 7414 | News entry (remember to update both the top level and the news directory). |
8973da3a | 7415 | @end itemize |
0816590b | 7416 | These pages also need to be regenerate using @code{index.sh}. |
8973da3a | 7417 | |
0816590b | 7418 | @item download/onlinedocs/ |
8642bc8f AC |
7419 | You need to find the magic command that is used to generate the online |
7420 | docs from the @file{.tar.bz2}. The best way is to look in the output | |
0816590b | 7421 | from one of the nightly @code{cron} jobs and then just edit accordingly. |
8642bc8f AC |
7422 | Something like: |
7423 | ||
474c8240 | 7424 | @smallexample |
8642bc8f | 7425 | $ ~/ss/update-web-docs \ |
0816590b | 7426 | ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \ |
8642bc8f | 7427 | $PWD/www \ |
0816590b | 7428 | /www/sourceware/htdocs/gdb/download/onlinedocs \ |
8642bc8f | 7429 | gdb |
474c8240 | 7430 | @end smallexample |
8642bc8f | 7431 | |
0816590b AC |
7432 | @item download/ari/ |
7433 | Just like the online documentation. Something like: | |
8642bc8f | 7434 | |
0816590b AC |
7435 | @smallexample |
7436 | $ /bin/sh ~/ss/update-web-ari \ | |
7437 | ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \ | |
7438 | $PWD/www \ | |
7439 | /www/sourceware/htdocs/gdb/download/ari \ | |
7440 | gdb | |
7441 | @end smallexample | |
7442 | ||
7443 | @end table | |
7444 | ||
7445 | @subsubheading Shadow the pages onto gnu | |
7446 | ||
7447 | Something goes here. | |
7448 | ||
7449 | ||
7450 | @subsubheading Install the @value{GDBN} tar ball on GNU | |
7451 | ||
7452 | At the time of writing, the GNU machine was @kbd{gnudist.gnu.org} in | |
7453 | @file{~ftp/gnu/gdb}. | |
7454 | ||
7455 | @subsubheading Make the @file{ANNOUNCEMENT} | |
7456 | ||
7457 | Post the @file{ANNOUNCEMENT} file you created above to: | |
8642bc8f AC |
7458 | |
7459 | @itemize @bullet | |
7460 | @item | |
87f9adc1 | 7461 | @email{gdb-announce@@sourceware.org, GDB Announcement mailing list} |
8642bc8f | 7462 | @item |
0816590b AC |
7463 | @email{info-gnu@@gnu.org, General GNU Announcement list} (but delay it a |
7464 | day or so to let things get out) | |
7465 | @item | |
7466 | @email{bug-gdb@@gnu.org, GDB Bug Report mailing list} | |
8642bc8f AC |
7467 | @end itemize |
7468 | ||
0816590b | 7469 | @subsection Cleanup |
8642bc8f | 7470 | |
0816590b | 7471 | The release is out but you're still not finished. |
8642bc8f | 7472 | |
0816590b | 7473 | @subsubheading Commit outstanding changes |
8642bc8f | 7474 | |
0816590b | 7475 | In particular you'll need to commit any changes to: |
8642bc8f AC |
7476 | |
7477 | @itemize @bullet | |
7478 | @item | |
7479 | @file{gdb/ChangeLog} | |
7480 | @item | |
7481 | @file{gdb/version.in} | |
7482 | @item | |
7483 | @file{gdb/NEWS} | |
7484 | @item | |
7485 | @file{gdb/README} | |
7486 | @end itemize | |
7487 | ||
0816590b | 7488 | @subsubheading Tag the release |
8642bc8f AC |
7489 | |
7490 | Something like: | |
7491 | ||
474c8240 | 7492 | @smallexample |
8642bc8f AC |
7493 | $ d=`date -u +%Y-%m-%d` |
7494 | $ echo $d | |
7495 | 2002-01-24 | |
7496 | $ ( cd insight/src/gdb && cvs -f -q update ) | |
0816590b | 7497 | $ ( cd insight/src && cvs -f -q tag gdb_5_2-$d-release ) |
474c8240 | 7498 | @end smallexample |
8642bc8f | 7499 | |
0816590b | 7500 | Insight is used since that contains more of the release than |
b247355e | 7501 | @value{GDBN}. |
0816590b AC |
7502 | |
7503 | @subsubheading Mention the release on the trunk | |
8642bc8f | 7504 | |
0816590b AC |
7505 | Just put something in the @file{ChangeLog} so that the trunk also |
7506 | indicates when the release was made. | |
7507 | ||
7508 | @subsubheading Restart @file{gdb/version.in} | |
8642bc8f AC |
7509 | |
7510 | If @file{gdb/version.in} does not contain an ISO date such as | |
7511 | @kbd{2002-01-24} then the daily @code{cronjob} won't update it. Having | |
7512 | committed all the release changes it can be set to | |
0816590b | 7513 | @file{5.2.0_0000-00-00-cvs} which will restart things (yes the @kbd{_} |
8642bc8f AC |
7514 | is important - it affects the snapshot process). |
7515 | ||
7516 | Don't forget the @file{ChangeLog}. | |
7517 | ||
0816590b | 7518 | @subsubheading Merge into trunk |
8973da3a | 7519 | |
8642bc8f AC |
7520 | The files committed to the branch may also need changes merged into the |
7521 | trunk. | |
8973da3a | 7522 | |
0816590b AC |
7523 | @subsubheading Revise the release schedule |
7524 | ||
87f9adc1 | 7525 | Post a revised release schedule to @email{gdb@@sourceware.org, GDB |
0816590b AC |
7526 | Discussion List} with an updated announcement. The schedule can be |
7527 | generated by running: | |
7528 | ||
7529 | @smallexample | |
7530 | $ ~/ss/schedule `date +%s` schedule | |
7531 | @end smallexample | |
7532 | ||
7533 | @noindent | |
7534 | The first parameter is approximate date/time in seconds (from the epoch) | |
7535 | of the most recent release. | |
7536 | ||
7537 | Also update the schedule @code{cronjob}. | |
7538 | ||
8642bc8f | 7539 | @section Post release |
8973da3a | 7540 | |
8642bc8f | 7541 | Remove any @code{OBSOLETE} code. |
8973da3a | 7542 | |
085dd6e6 JM |
7543 | @node Testsuite |
7544 | ||
7545 | @chapter Testsuite | |
56caf160 | 7546 | @cindex test suite |
085dd6e6 | 7547 | |
56caf160 EZ |
7548 | The testsuite is an important component of the @value{GDBN} package. |
7549 | While it is always worthwhile to encourage user testing, in practice | |
7550 | this is rarely sufficient; users typically use only a small subset of | |
7551 | the available commands, and it has proven all too common for a change | |
7552 | to cause a significant regression that went unnoticed for some time. | |
085dd6e6 | 7553 | |
b247355e NR |
7554 | The @value{GDBN} testsuite uses the DejaGNU testing framework. The |
7555 | tests themselves are calls to various @code{Tcl} procs; the framework | |
7556 | runs all the procs and summarizes the passes and fails. | |
085dd6e6 JM |
7557 | |
7558 | @section Using the Testsuite | |
7559 | ||
56caf160 | 7560 | @cindex running the test suite |
25822942 | 7561 | To run the testsuite, simply go to the @value{GDBN} object directory (or to the |
085dd6e6 JM |
7562 | testsuite's objdir) and type @code{make check}. This just sets up some |
7563 | environment variables and invokes DejaGNU's @code{runtest} script. While | |
7564 | the testsuite is running, you'll get mentions of which test file is in use, | |
7565 | and a mention of any unexpected passes or fails. When the testsuite is | |
7566 | finished, you'll get a summary that looks like this: | |
56caf160 | 7567 | |
474c8240 | 7568 | @smallexample |
085dd6e6 JM |
7569 | === gdb Summary === |
7570 | ||
7571 | # of expected passes 6016 | |
7572 | # of unexpected failures 58 | |
7573 | # of unexpected successes 5 | |
7574 | # of expected failures 183 | |
7575 | # of unresolved testcases 3 | |
7576 | # of untested testcases 5 | |
474c8240 | 7577 | @end smallexample |
56caf160 | 7578 | |
a9f158ec JB |
7579 | To run a specific test script, type: |
7580 | @example | |
7581 | make check RUNTESTFLAGS='@var{tests}' | |
7582 | @end example | |
7583 | where @var{tests} is a list of test script file names, separated by | |
7584 | spaces. | |
7585 | ||
f5a33284 TT |
7586 | If you use GNU make, you can use its @option{-j} option to run the |
7587 | testsuite in parallel. This can greatly reduce the amount of time it | |
7588 | takes for the testsuite to run. In this case, if you set | |
7589 | @code{RUNTESTFLAGS} then, by default, the tests will be run serially | |
7590 | even under @option{-j}. You can override this and force a parallel run | |
7591 | by setting the @code{make} variable @code{FORCE_PARALLEL} to any | |
7592 | non-empty value. Note that the parallel @kbd{make check} assumes | |
7593 | that you want to run the entire testsuite, so it is not compatible | |
7594 | with some dejagnu options, like @option{--directory}. | |
7595 | ||
085dd6e6 JM |
7596 | The ideal test run consists of expected passes only; however, reality |
7597 | conspires to keep us from this ideal. Unexpected failures indicate | |
56caf160 EZ |
7598 | real problems, whether in @value{GDBN} or in the testsuite. Expected |
7599 | failures are still failures, but ones which have been decided are too | |
7600 | hard to deal with at the time; for instance, a test case might work | |
7601 | everywhere except on AIX, and there is no prospect of the AIX case | |
7602 | being fixed in the near future. Expected failures should not be added | |
7603 | lightly, since you may be masking serious bugs in @value{GDBN}. | |
7604 | Unexpected successes are expected fails that are passing for some | |
7605 | reason, while unresolved and untested cases often indicate some minor | |
7606 | catastrophe, such as the compiler being unable to deal with a test | |
7607 | program. | |
7608 | ||
7609 | When making any significant change to @value{GDBN}, you should run the | |
7610 | testsuite before and after the change, to confirm that there are no | |
7611 | regressions. Note that truly complete testing would require that you | |
7612 | run the testsuite with all supported configurations and a variety of | |
7613 | compilers; however this is more than really necessary. In many cases | |
7614 | testing with a single configuration is sufficient. Other useful | |
7615 | options are to test one big-endian (Sparc) and one little-endian (x86) | |
7616 | host, a cross config with a builtin simulator (powerpc-eabi, | |
7617 | mips-elf), or a 64-bit host (Alpha). | |
7618 | ||
7619 | If you add new functionality to @value{GDBN}, please consider adding | |
7620 | tests for it as well; this way future @value{GDBN} hackers can detect | |
7621 | and fix their changes that break the functionality you added. | |
7622 | Similarly, if you fix a bug that was not previously reported as a test | |
7623 | failure, please add a test case for it. Some cases are extremely | |
7624 | difficult to test, such as code that handles host OS failures or bugs | |
7625 | in particular versions of compilers, and it's OK not to try to write | |
7626 | tests for all of those. | |
085dd6e6 | 7627 | |
e7dc800a MC |
7628 | DejaGNU supports separate build, host, and target machines. However, |
7629 | some @value{GDBN} test scripts do not work if the build machine and | |
7630 | the host machine are not the same. In such an environment, these scripts | |
7631 | will give a result of ``UNRESOLVED'', like this: | |
7632 | ||
7633 | @smallexample | |
7634 | UNRESOLVED: gdb.base/example.exp: This test script does not work on a remote host. | |
7635 | @end smallexample | |
7636 | ||
c5f80513 DE |
7637 | @section Testsuite Parameters |
7638 | ||
7639 | Several variables exist to modify the behavior of the testsuite. | |
7640 | ||
7641 | @itemize @bullet | |
7642 | ||
7643 | @item @code{TRANSCRIPT} | |
7644 | ||
812f7342 TT |
7645 | Sometimes it is convenient to get a transcript of the commands which |
7646 | the testsuite sends to @value{GDBN}. For example, if @value{GDBN} | |
7647 | crashes during testing, a transcript can be used to more easily | |
7648 | reconstruct the failure when running @value{GDBN} under @value{GDBN}. | |
7649 | ||
7650 | You can instruct the @value{GDBN} testsuite to write transcripts by | |
7651 | setting the DejaGNU variable @code{TRANSCRIPT} (to any value) | |
7652 | before invoking @code{runtest} or @kbd{make check}. The transcripts | |
7653 | will be written into DejaGNU's output directory. One transcript will | |
7654 | be made for each invocation of @value{GDBN}; they will be named | |
7655 | @file{transcript.@var{n}}, where @var{n} is an integer. The first | |
7656 | line of the transcript file will show how @value{GDBN} was invoked; | |
7657 | each subsequent line is a command sent as input to @value{GDBN}. | |
7658 | ||
7659 | @smallexample | |
7660 | make check RUNTESTFLAGS=TRANSCRIPT=y | |
7661 | @end smallexample | |
7662 | ||
7663 | Note that the transcript is not always complete. In particular, tests | |
7664 | of completion can yield partial command lines. | |
7665 | ||
c5f80513 DE |
7666 | @item @code{GDB} |
7667 | ||
7668 | Sometimes one wishes to test a different @value{GDBN} than the one in the build | |
7669 | directory. For example, one may wish to run the testsuite on | |
7670 | @file{/usr/bin/gdb}. | |
7671 | ||
7672 | @smallexample | |
7673 | make check RUNTESTFLAGS=GDB=/usr/bin/gdb | |
7674 | @end smallexample | |
7675 | ||
7676 | @item @code{GDBSERVER} | |
7677 | ||
7678 | When testing a different @value{GDBN}, it is often useful to also test a | |
7679 | different gdbserver. | |
7680 | ||
7681 | @smallexample | |
7682 | make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver" | |
7683 | @end smallexample | |
7684 | ||
1be00882 DE |
7685 | @item @code{INTERNAL_GDBFLAGS} |
7686 | ||
7687 | When running the testsuite normally one doesn't want whatever is in | |
7688 | @file{~/.gdbinit} to interfere with the tests, therefore the test harness | |
7689 | passes @option{-nx} to @value{GDBN}. One also doesn't want any windowed | |
217bff3e | 7690 | version of @value{GDBN}, e.g., @samp{gdb -tui}, to run. |
1be00882 DE |
7691 | This is achieved via @code{INTERNAL_GDBFLAGS}. |
7692 | ||
7693 | @smallexample | |
7694 | set INTERNAL_GDBFLAGS "-nw -nx" | |
7695 | @end smallexample | |
7696 | ||
7697 | This is all well and good, except when testing an installed @value{GDBN} | |
7698 | that has been configured with @option{--with-system-gdbinit}. Here one | |
7699 | does not want @file{~/.gdbinit} loaded but one may want the system | |
7700 | @file{.gdbinit} file loaded. This can be achieved by pointing @code{$HOME} | |
7701 | at a directory without a @file{.gdbinit} and by overriding | |
7702 | @code{INTERNAL_GDBFLAGS} and removing @option{-nx}. | |
7703 | ||
7704 | @smallexample | |
7705 | cd testsuite | |
7706 | HOME=`pwd` runtest \ | |
7707 | GDB=/usr/bin/gdb \ | |
7708 | GDBSERVER=/usr/bin/gdbserver \ | |
7709 | INTERNAL_GDBFLAGS=-nw | |
7710 | @end smallexample | |
7711 | ||
c5f80513 DE |
7712 | @end itemize |
7713 | ||
7714 | There are two ways to run the testsuite and pass additional parameters | |
7715 | to DejaGnu. The first is with @kbd{make check} and specifying the | |
7716 | makefile variable @samp{RUNTESTFLAGS}. | |
7717 | ||
7718 | @smallexample | |
7719 | make check RUNTESTFLAGS=TRANSCRIPT=y | |
7720 | @end smallexample | |
7721 | ||
7722 | The second is to cd to the @file{testsuite} directory and invoke the DejaGnu | |
7723 | @command{runtest} command directly. | |
7724 | ||
7725 | @smallexample | |
7726 | cd testsuite | |
7727 | make site.exp | |
7728 | runtest TRANSCRIPT=y | |
7729 | @end smallexample | |
7730 | ||
c09529e5 JB |
7731 | @section Testsuite Configuration |
7732 | @cindex Testsuite Configuration | |
7733 | ||
7734 | It is possible to adjust the behavior of the testsuite by defining | |
7735 | the global variables listed below, either in a @file{site.exp} file, | |
7736 | or in a board file. | |
7737 | ||
7738 | @itemize @bullet | |
7739 | ||
7740 | @item @code{gdb_test_timeout} | |
7741 | ||
7742 | Defining this variable changes the default timeout duration used during | |
7743 | communication with @value{GDBN}. More specifically, the global variable | |
7744 | used during testing is @code{timeout}, but this variable gets reset to | |
7745 | @code{gdb_test_timeout} at the beginning of each testcase, making sure | |
7746 | that any local change to @code{timeout} in a testcase does not affect | |
7747 | subsequent testcases. | |
7748 | ||
7749 | This global variable comes in handy when the debugger is slower than | |
7750 | normal due to the testing environment, triggering unexpected @code{TIMEOUT} | |
7751 | test failures. Examples include when testing on a remote machine, or | |
7752 | against a system where communications are slow. | |
7753 | ||
7754 | If not specifically defined, this variable gets automatically defined | |
7755 | to the same value as @code{timeout} during the testsuite initialization. | |
7756 | The default value of the timeout is defined in the file | |
7757 | @file{gdb/testsuite/config/unix.exp} that is part of the @value{GDBN} | |
7758 | test suite@footnote{If you are using a board file, it could override | |
7759 | the test-suite default; search the board file for "timeout".}. | |
7760 | ||
7761 | @end itemize | |
7762 | ||
085dd6e6 JM |
7763 | @section Testsuite Organization |
7764 | ||
56caf160 | 7765 | @cindex test suite organization |
085dd6e6 JM |
7766 | The testsuite is entirely contained in @file{gdb/testsuite}. While the |
7767 | testsuite includes some makefiles and configury, these are very minimal, | |
7768 | and used for little besides cleaning up, since the tests themselves | |
25822942 | 7769 | handle the compilation of the programs that @value{GDBN} will run. The file |
085dd6e6 | 7770 | @file{testsuite/lib/gdb.exp} contains common utility procs useful for |
25822942 | 7771 | all @value{GDBN} tests, while the directory @file{testsuite/config} contains |
085dd6e6 JM |
7772 | configuration-specific files, typically used for special-purpose |
7773 | definitions of procs like @code{gdb_load} and @code{gdb_start}. | |
7774 | ||
7775 | The tests themselves are to be found in @file{testsuite/gdb.*} and | |
7776 | subdirectories of those. The names of the test files must always end | |
7777 | with @file{.exp}. DejaGNU collects the test files by wildcarding | |
7778 | in the test directories, so both subdirectories and individual files | |
7779 | get chosen and run in alphabetical order. | |
7780 | ||
7781 | The following table lists the main types of subdirectories and what they | |
7782 | are for. Since DejaGNU finds test files no matter where they are | |
7783 | located, and since each test file sets up its own compilation and | |
7784 | execution environment, this organization is simply for convenience and | |
7785 | intelligibility. | |
7786 | ||
56caf160 | 7787 | @table @file |
085dd6e6 | 7788 | @item gdb.base |
085dd6e6 | 7789 | This is the base testsuite. The tests in it should apply to all |
25822942 | 7790 | configurations of @value{GDBN} (but generic native-only tests may live here). |
085dd6e6 | 7791 | The test programs should be in the subset of C that is valid K&R, |
49efadf5 | 7792 | ANSI/ISO, and C@t{++} (@code{#ifdef}s are allowed if necessary, for instance |
085dd6e6 JM |
7793 | for prototypes). |
7794 | ||
7795 | @item gdb.@var{lang} | |
56caf160 | 7796 | Language-specific tests for any language @var{lang} besides C. Examples are |
af6cf26d | 7797 | @file{gdb.cp} and @file{gdb.java}. |
085dd6e6 JM |
7798 | |
7799 | @item gdb.@var{platform} | |
085dd6e6 JM |
7800 | Non-portable tests. The tests are specific to a specific configuration |
7801 | (host or target), such as HP-UX or eCos. Example is @file{gdb.hp}, for | |
7802 | HP-UX. | |
7803 | ||
7804 | @item gdb.@var{compiler} | |
085dd6e6 JM |
7805 | Tests specific to a particular compiler. As of this writing (June |
7806 | 1999), there aren't currently any groups of tests in this category that | |
7807 | couldn't just as sensibly be made platform-specific, but one could | |
56caf160 EZ |
7808 | imagine a @file{gdb.gcc}, for tests of @value{GDBN}'s handling of GCC |
7809 | extensions. | |
085dd6e6 JM |
7810 | |
7811 | @item gdb.@var{subsystem} | |
25822942 | 7812 | Tests that exercise a specific @value{GDBN} subsystem in more depth. For |
085dd6e6 JM |
7813 | instance, @file{gdb.disasm} exercises various disassemblers, while |
7814 | @file{gdb.stabs} tests pathways through the stabs symbol reader. | |
085dd6e6 JM |
7815 | @end table |
7816 | ||
7817 | @section Writing Tests | |
56caf160 | 7818 | @cindex writing tests |
085dd6e6 | 7819 | |
25822942 | 7820 | In many areas, the @value{GDBN} tests are already quite comprehensive; you |
085dd6e6 JM |
7821 | should be able to copy existing tests to handle new cases. |
7822 | ||
7823 | You should try to use @code{gdb_test} whenever possible, since it | |
7824 | includes cases to handle all the unexpected errors that might happen. | |
7825 | However, it doesn't cost anything to add new test procedures; for | |
7826 | instance, @file{gdb.base/exprs.exp} defines a @code{test_expr} that | |
7827 | calls @code{gdb_test} multiple times. | |
7828 | ||
7829 | Only use @code{send_gdb} and @code{gdb_expect} when absolutely | |
8a3dae3e DJ |
7830 | necessary. Even if @value{GDBN} has several valid responses to |
7831 | a command, you can use @code{gdb_test_multiple}. Like @code{gdb_test}, | |
7832 | @code{gdb_test_multiple} recognizes internal errors and unexpected | |
7833 | prompts. | |
7834 | ||
7835 | Do not write tests which expect a literal tab character from @value{GDBN}. | |
7836 | On some operating systems (e.g.@: OpenBSD) the TTY layer expands tabs to | |
7837 | spaces, so by the time @value{GDBN}'s output reaches expect the tab is gone. | |
085dd6e6 JM |
7838 | |
7839 | The source language programs do @emph{not} need to be in a consistent | |
25822942 | 7840 | style. Since @value{GDBN} is used to debug programs written in many different |
085dd6e6 | 7841 | styles, it's worth having a mix of styles in the testsuite; for |
25822942 | 7842 | instance, some @value{GDBN} bugs involving the display of source lines would |
085dd6e6 JM |
7843 | never manifest themselves if the programs used GNU coding style |
7844 | uniformly. | |
7845 | ||
13ac8d2c JK |
7846 | Some testcase results need more detailed explanation: |
7847 | ||
7848 | @table @code | |
7849 | @item KFAIL | |
7850 | Known problem of @value{GDBN} itself. You must specify the @value{GDBN} bug | |
7851 | report number like in these sample tests: | |
7852 | @smallexample | |
7853 | kfail "gdb/13392" "continue to marker 2" | |
7854 | @end smallexample | |
7855 | or | |
7856 | @smallexample | |
7857 | setup_kfail gdb/13392 "*-*-*" | |
7858 | kfail "continue to marker 2" | |
7859 | @end smallexample | |
7860 | ||
7861 | @item XFAIL | |
7862 | Known problem of environment. This typically includes @value{NGCC} but it | |
7863 | includes also many other system components which cannot be fixed in the | |
7864 | @value{GDBN} project. Sample test with sanity check not knowing the specific | |
7865 | cause of the problem: | |
7866 | @smallexample | |
7867 | # On x86_64 it is commonly about 4MB. | |
7868 | if @{$stub_size > 25000000@} @{ | |
7869 | xfail "stub size $stub_size is too large" | |
7870 | return | |
7871 | @} | |
7872 | @end smallexample | |
7873 | ||
7874 | You should provide bug report number for the failing component of the | |
7875 | environment, if such bug report is available: | |
7876 | @smallexample | |
7877 | if @{[test_compiler_info @{gcc-[0-3]-*@}] | |
7878 | || [test_compiler_info @{gcc-4-[0-5]-*@}]@} @{ | |
7879 | setup_xfail "gcc/46955" *-*-* | |
7880 | @} | |
7881 | gdb_test "python print ttype.template_argument(2)" "&C::c" | |
7882 | @end smallexample | |
7883 | @end table | |
7884 | ||
f02e2b19 YQ |
7885 | @section Board settings |
7886 | In @value{GDBN} testsuite, the tests can be configured or customized in the board | |
7887 | file by means of @dfn{Board Settings}. Each setting should be consulted by | |
7888 | test cases that depend on the corresponding feature. | |
7889 | ||
7890 | Here are the supported board settings: | |
7891 | ||
7892 | @table @code | |
7893 | ||
7894 | @item gdb,cannot_call_functions | |
7895 | The board does not support inferior call, that is, invoking inferior functions | |
7896 | in @value{GDBN}. | |
7897 | @item gdb,can_reverse | |
7898 | The board supports reverse execution. | |
7899 | @item gdb,no_hardware_watchpoints | |
7900 | The board does not support hardware watchpoints. | |
7901 | @item gdb,nofileio | |
7902 | @value{GDBN} is unable to intercept target file operations in remote and perform | |
7903 | them on the host. | |
7904 | @item gdb,noinferiorio | |
7905 | The board is unable to provide I/O capability to the inferior. | |
7906 | @c @item gdb,noresults | |
7907 | @c NEED DOCUMENT. | |
7908 | @item gdb,nosignals | |
7909 | The board does not support signals. | |
7910 | @item gdb,skip_huge_test | |
7911 | Skip time-consuming tests on the board with slow connection. | |
7912 | @item gdb,skip_float_tests | |
7913 | Skip tests related to float points on target board. | |
7914 | @item gdb,use_precord | |
7915 | The board supports process record. | |
7916 | @item gdb_server_prog | |
7917 | The location of GDBserver. If GDBserver somewhere other than its default | |
7918 | location is used in test, specify the location of GDBserver in this variable. | |
7919 | The location is a file name of GDBserver that can be either absolute or | |
7920 | relative to testsuite subdirectory in build directory. | |
7921 | @item in_proc_agent | |
7922 | The location of in-process agent. If in-process agent other than its default | |
7923 | location is used in test, specify the location of in-process agent in | |
7924 | this variable. The location is a file name of in-process agent that can be | |
7925 | either absolute or relative to testsuite subdirectory in build directory. | |
7926 | @item noargs | |
7927 | @value{GDBN} does not support argument passing for inferior. | |
7928 | @item no_long_long | |
7929 | The board does not support type @code{long long}. | |
7930 | @c @item use_cygmon | |
7931 | @c NEED DOCUMENT. | |
7932 | @item use_gdb_stub | |
7933 | The tests are running with gdb stub. | |
7934 | @end table | |
7935 | ||
c906108c SS |
7936 | @node Hints |
7937 | ||
7938 | @chapter Hints | |
7939 | ||
7940 | Check the @file{README} file, it often has useful information that does not | |
7941 | appear anywhere else in the directory. | |
7942 | ||
7943 | @menu | |
25822942 | 7944 | * Getting Started:: Getting started working on @value{GDBN} |
33e16fad | 7945 | * Debugging GDB:: Debugging @value{GDBN} with itself |
c906108c SS |
7946 | @end menu |
7947 | ||
629d6a47 | 7948 | @node Getting Started |
c906108c SS |
7949 | |
7950 | @section Getting Started | |
7951 | ||
25822942 | 7952 | @value{GDBN} is a large and complicated program, and if you first starting to |
c906108c SS |
7953 | work on it, it can be hard to know where to start. Fortunately, if you |
7954 | know how to go about it, there are ways to figure out what is going on. | |
7955 | ||
25822942 DB |
7956 | This manual, the @value{GDBN} Internals manual, has information which applies |
7957 | generally to many parts of @value{GDBN}. | |
c906108c SS |
7958 | |
7959 | Information about particular functions or data structures are located in | |
7960 | comments with those functions or data structures. If you run across a | |
7961 | function or a global variable which does not have a comment correctly | |
25822942 | 7962 | explaining what is does, this can be thought of as a bug in @value{GDBN}; feel |
c906108c SS |
7963 | free to submit a bug report, with a suggested comment if you can figure |
7964 | out what the comment should say. If you find a comment which is | |
7965 | actually wrong, be especially sure to report that. | |
7966 | ||
7967 | Comments explaining the function of macros defined in host, target, or | |
7968 | native dependent files can be in several places. Sometimes they are | |
7969 | repeated every place the macro is defined. Sometimes they are where the | |
7970 | macro is used. Sometimes there is a header file which supplies a | |
7971 | default definition of the macro, and the comment is there. This manual | |
7972 | also documents all the available macros. | |
7973 | @c (@pxref{Host Conditionals}, @pxref{Target | |
7974 | @c Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete | |
7975 | @c Conditionals}) | |
7976 | ||
56caf160 EZ |
7977 | Start with the header files. Once you have some idea of how |
7978 | @value{GDBN}'s internal symbol tables are stored (see @file{symtab.h}, | |
7979 | @file{gdbtypes.h}), you will find it much easier to understand the | |
7980 | code which uses and creates those symbol tables. | |
c906108c SS |
7981 | |
7982 | You may wish to process the information you are getting somehow, to | |
7983 | enhance your understanding of it. Summarize it, translate it to another | |
25822942 | 7984 | language, add some (perhaps trivial or non-useful) feature to @value{GDBN}, use |
c906108c SS |
7985 | the code to predict what a test case would do and write the test case |
7986 | and verify your prediction, etc. If you are reading code and your eyes | |
7987 | are starting to glaze over, this is a sign you need to use a more active | |
7988 | approach. | |
7989 | ||
25822942 | 7990 | Once you have a part of @value{GDBN} to start with, you can find more |
c906108c SS |
7991 | specifically the part you are looking for by stepping through each |
7992 | function with the @code{next} command. Do not use @code{step} or you | |
7993 | will quickly get distracted; when the function you are stepping through | |
7994 | calls another function try only to get a big-picture understanding | |
7995 | (perhaps using the comment at the beginning of the function being | |
7996 | called) of what it does. This way you can identify which of the | |
7997 | functions being called by the function you are stepping through is the | |
7998 | one which you are interested in. You may need to examine the data | |
7999 | structures generated at each stage, with reference to the comments in | |
8000 | the header files explaining what the data structures are supposed to | |
8001 | look like. | |
8002 | ||
8003 | Of course, this same technique can be used if you are just reading the | |
8004 | code, rather than actually stepping through it. The same general | |
8005 | principle applies---when the code you are looking at calls something | |
8006 | else, just try to understand generally what the code being called does, | |
8007 | rather than worrying about all its details. | |
8008 | ||
56caf160 EZ |
8009 | @cindex command implementation |
8010 | A good place to start when tracking down some particular area is with | |
8011 | a command which invokes that feature. Suppose you want to know how | |
8012 | single-stepping works. As a @value{GDBN} user, you know that the | |
8013 | @code{step} command invokes single-stepping. The command is invoked | |
8014 | via command tables (see @file{command.h}); by convention the function | |
8015 | which actually performs the command is formed by taking the name of | |
8016 | the command and adding @samp{_command}, or in the case of an | |
8017 | @code{info} subcommand, @samp{_info}. For example, the @code{step} | |
8018 | command invokes the @code{step_command} function and the @code{info | |
8019 | display} command invokes @code{display_info}. When this convention is | |
8020 | not followed, you might have to use @code{grep} or @kbd{M-x | |
8021 | tags-search} in emacs, or run @value{GDBN} on itself and set a | |
8022 | breakpoint in @code{execute_command}. | |
8023 | ||
8024 | @cindex @code{bug-gdb} mailing list | |
c906108c SS |
8025 | If all of the above fail, it may be appropriate to ask for information |
8026 | on @code{bug-gdb}. But @emph{never} post a generic question like ``I was | |
8027 | wondering if anyone could give me some tips about understanding | |
25822942 | 8028 | @value{GDBN}''---if we had some magic secret we would put it in this manual. |
c906108c SS |
8029 | Suggestions for improving the manual are always welcome, of course. |
8030 | ||
629d6a47 | 8031 | @node Debugging GDB |
c906108c | 8032 | |
25822942 | 8033 | @section Debugging @value{GDBN} with itself |
56caf160 | 8034 | @cindex debugging @value{GDBN} |
c906108c | 8035 | |
25822942 | 8036 | If @value{GDBN} is limping on your machine, this is the preferred way to get it |
c906108c SS |
8037 | fully functional. Be warned that in some ancient Unix systems, like |
8038 | Ultrix 4.2, a program can't be running in one process while it is being | |
56caf160 | 8039 | debugged in another. Rather than typing the command @kbd{@w{./gdb |
c906108c | 8040 | ./gdb}}, which works on Suns and such, you can copy @file{gdb} to |
56caf160 | 8041 | @file{gdb2} and then type @kbd{@w{./gdb ./gdb2}}. |
c906108c | 8042 | |
dc1039df JK |
8043 | When you run @value{GDBN} in the @value{GDBN} source directory, it will read |
8044 | @file{gdb-gdb.gdb} file (plus possibly @file{gdb-gdb.py} file) that sets up | |
8045 | some simple things to make debugging gdb easier. The @code{info} command, when | |
8046 | executed without a subcommand in a @value{GDBN} being debugged by gdb, will pop | |
8047 | you back up to the top level gdb. See @file{gdb-gdb.gdb} for details. | |
c906108c SS |
8048 | |
8049 | If you use emacs, you will probably want to do a @code{make TAGS} after | |
8050 | you configure your distribution; this will put the machine dependent | |
8051 | routines for your local machine where they will be accessed first by | |
8052 | @kbd{M-.} | |
8053 | ||
25822942 | 8054 | Also, make sure that you've either compiled @value{GDBN} with your local cc, or |
c906108c SS |
8055 | have run @code{fixincludes} if you are compiling with gcc. |
8056 | ||
8057 | @section Submitting Patches | |
8058 | ||
56caf160 | 8059 | @cindex submitting patches |
c906108c | 8060 | Thanks for thinking of offering your changes back to the community of |
25822942 | 8061 | @value{GDBN} users. In general we like to get well designed enhancements. |
c906108c SS |
8062 | Thanks also for checking in advance about the best way to transfer the |
8063 | changes. | |
8064 | ||
25822942 DB |
8065 | The @value{GDBN} maintainers will only install ``cleanly designed'' patches. |
8066 | This manual summarizes what we believe to be clean design for @value{GDBN}. | |
c906108c SS |
8067 | |
8068 | If the maintainers don't have time to put the patch in when it arrives, | |
8069 | or if there is any question about a patch, it goes into a large queue | |
8070 | with everyone else's patches and bug reports. | |
8071 | ||
56caf160 | 8072 | @cindex legal papers for code contributions |
c906108c SS |
8073 | The legal issue is that to incorporate substantial changes requires a |
8074 | copyright assignment from you and/or your employer, granting ownership | |
8075 | of the changes to the Free Software Foundation. You can get the | |
9e0b60a8 JM |
8076 | standard documents for doing this by sending mail to @code{gnu@@gnu.org} |
8077 | and asking for it. We recommend that people write in "All programs | |
8078 | owned by the Free Software Foundation" as "NAME OF PROGRAM", so that | |
56caf160 EZ |
8079 | changes in many programs (not just @value{GDBN}, but GAS, Emacs, GCC, |
8080 | etc) can be | |
9e0b60a8 | 8081 | contributed with only one piece of legalese pushed through the |
be9c6c35 | 8082 | bureaucracy and filed with the FSF. We can't start merging changes until |
9e0b60a8 JM |
8083 | this paperwork is received by the FSF (their rules, which we follow |
8084 | since we maintain it for them). | |
c906108c SS |
8085 | |
8086 | Technically, the easiest way to receive changes is to receive each | |
56caf160 EZ |
8087 | feature as a small context diff or unidiff, suitable for @code{patch}. |
8088 | Each message sent to me should include the changes to C code and | |
8089 | header files for a single feature, plus @file{ChangeLog} entries for | |
8090 | each directory where files were modified, and diffs for any changes | |
8091 | needed to the manuals (@file{gdb/doc/gdb.texinfo} or | |
8092 | @file{gdb/doc/gdbint.texinfo}). If there are a lot of changes for a | |
8093 | single feature, they can be split down into multiple messages. | |
9e0b60a8 JM |
8094 | |
8095 | In this way, if we read and like the feature, we can add it to the | |
c906108c | 8096 | sources with a single patch command, do some testing, and check it in. |
56caf160 EZ |
8097 | If you leave out the @file{ChangeLog}, we have to write one. If you leave |
8098 | out the doc, we have to puzzle out what needs documenting. Etc., etc. | |
c906108c | 8099 | |
9e0b60a8 JM |
8100 | The reason to send each change in a separate message is that we will not |
8101 | install some of the changes. They'll be returned to you with questions | |
8102 | or comments. If we're doing our job correctly, the message back to you | |
c906108c | 8103 | will say what you have to fix in order to make the change acceptable. |
9e0b60a8 JM |
8104 | The reason to have separate messages for separate features is so that |
8105 | the acceptable changes can be installed while one or more changes are | |
8106 | being reworked. If multiple features are sent in a single message, we | |
8107 | tend to not put in the effort to sort out the acceptable changes from | |
8108 | the unacceptable, so none of the features get installed until all are | |
8109 | acceptable. | |
8110 | ||
8111 | If this sounds painful or authoritarian, well, it is. But we get a lot | |
8112 | of bug reports and a lot of patches, and many of them don't get | |
8113 | installed because we don't have the time to finish the job that the bug | |
c906108c SS |
8114 | reporter or the contributor could have done. Patches that arrive |
8115 | complete, working, and well designed, tend to get installed on the day | |
9e0b60a8 JM |
8116 | they arrive. The others go into a queue and get installed as time |
8117 | permits, which, since the maintainers have many demands to meet, may not | |
8118 | be for quite some time. | |
c906108c | 8119 | |
56caf160 | 8120 | Please send patches directly to |
87f9adc1 | 8121 | @email{gdb-patches@@sourceware.org, the @value{GDBN} maintainers}. |
c906108c | 8122 | |
36af4ef6 MD |
8123 | @section Build Script |
8124 | ||
8125 | @cindex build script | |
8126 | ||
8127 | The script @file{gdb_buildall.sh} builds @value{GDBN} with flag | |
8128 | @option{--enable-targets=all} set. This builds @value{GDBN} with all supported | |
8129 | targets activated. This helps testing @value{GDBN} when doing changes that | |
8130 | affect more than one architecture and is much faster than using | |
8131 | @file{gdb_mbuild.sh}. | |
8132 | ||
8133 | After building @value{GDBN} the script checks which architectures are | |
8134 | supported and then switches the current architecture to each of those to get | |
8135 | information about the architecture. The test results are stored in log files | |
8136 | in the directory the script was called from. | |
8137 | ||
bcd7e15f | 8138 | @include observer.texi |
e4c0cfae SS |
8139 | |
8140 | @node GNU Free Documentation License | |
8141 | @appendix GNU Free Documentation License | |
aab4e0ec AC |
8142 | @include fdl.texi |
8143 | ||
055855a4 EZ |
8144 | @node Concept Index |
8145 | @unnumbered Concept Index | |
56caf160 EZ |
8146 | |
8147 | @printindex cp | |
8148 | ||
055855a4 EZ |
8149 | @node Function and Variable Index |
8150 | @unnumbered Function and Variable Index | |
8151 | ||
8152 | @printindex fn | |
8153 | ||
c906108c | 8154 | @bye |