Commit | Line | Data |
---|---|---|
9742079a | 1 | \input texinfo @c -*- texinfo -*- |
c906108c | 2 | @setfilename gdbint.info |
25822942 | 3 | @include gdb-cfg.texi |
03727ca6 | 4 | @dircategory Software development |
e9c75b65 | 5 | @direntry |
c906108c | 6 | * Gdb-Internals: (gdbint). The GNU debugger's internals. |
e9c75b65 | 7 | @end direntry |
c906108c SS |
8 | |
9 | @ifinfo | |
25822942 | 10 | This file documents the internals of the GNU debugger @value{GDBN}. |
c02a867d | 11 | Copyright (C) 1990, 1991, 1992, 1993, 1994, 1996, 1998, 1999, 2000, 2001, |
c91d38aa | 12 | 2002, 2003, 2004, 2005, 2006 |
e9c75b65 | 13 | Free Software Foundation, Inc. |
c906108c SS |
14 | Contributed by Cygnus Solutions. Written by John Gilmore. |
15 | Second Edition by Stan Shebs. | |
16 | ||
e9c75b65 EZ |
17 | Permission is granted to copy, distribute and/or modify this document |
18 | under the terms of the GNU Free Documentation License, Version 1.1 or | |
2a6585f0 | 19 | any later version published by the Free Software Foundation; with no |
e5249f67 AC |
20 | Invariant Sections, with no Front-Cover Texts, and with no Back-Cover |
21 | Texts. A copy of the license is included in the section entitled ``GNU | |
22 | Free Documentation License''. | |
c906108c SS |
23 | @end ifinfo |
24 | ||
25 | @setchapternewpage off | |
25822942 | 26 | @settitle @value{GDBN} Internals |
c906108c | 27 | |
56caf160 EZ |
28 | @syncodeindex fn cp |
29 | @syncodeindex vr cp | |
30 | ||
c906108c | 31 | @titlepage |
25822942 | 32 | @title @value{GDBN} Internals |
c906108c SS |
33 | @subtitle{A guide to the internals of the GNU debugger} |
34 | @author John Gilmore | |
35 | @author Cygnus Solutions | |
36 | @author Second Edition: | |
37 | @author Stan Shebs | |
38 | @author Cygnus Solutions | |
39 | @page | |
40 | @tex | |
41 | \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$ | |
42 | \xdef\manvers{\$Revision$} % For use in headers, footers too | |
43 | {\parskip=0pt | |
44 | \hfill Cygnus Solutions\par | |
45 | \hfill \manvers\par | |
46 | \hfill \TeX{}info \texinfoversion\par | |
47 | } | |
48 | @end tex | |
49 | ||
50 | @vskip 0pt plus 1filll | |
1e698235 | 51 | Copyright @copyright{} 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001, |
c91d38aa | 52 | 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. |
c906108c | 53 | |
e9c75b65 EZ |
54 | Permission is granted to copy, distribute and/or modify this document |
55 | under the terms of the GNU Free Documentation License, Version 1.1 or | |
2a6585f0 | 56 | any later version published by the Free Software Foundation; with no |
e5249f67 AC |
57 | Invariant Sections, with no Front-Cover Texts, and with no Back-Cover |
58 | Texts. A copy of the license is included in the section entitled ``GNU | |
59 | Free Documentation License''. | |
c906108c SS |
60 | @end titlepage |
61 | ||
449f3b6c | 62 | @contents |
449f3b6c | 63 | |
c906108c SS |
64 | @node Top |
65 | @c Perhaps this should be the title of the document (but only for info, | |
66 | @c not for TeX). Existing GNU manuals seem inconsistent on this point. | |
67 | @top Scope of this Document | |
68 | ||
25822942 DB |
69 | This document documents the internals of the GNU debugger, @value{GDBN}. It |
70 | includes description of @value{GDBN}'s key algorithms and operations, as well | |
71 | as the mechanisms that adapt @value{GDBN} to specific hosts and targets. | |
c906108c SS |
72 | |
73 | @menu | |
74 | * Requirements:: | |
75 | * Overall Structure:: | |
76 | * Algorithms:: | |
77 | * User Interface:: | |
89437448 | 78 | * libgdb:: |
c906108c SS |
79 | * Symbol Handling:: |
80 | * Language Support:: | |
81 | * Host Definition:: | |
82 | * Target Architecture Definition:: | |
83 | * Target Vector Definition:: | |
84 | * Native Debugging:: | |
85 | * Support Libraries:: | |
86 | * Coding:: | |
87 | * Porting GDB:: | |
d52fe014 | 88 | * Versions and Branches:: |
55f6ca0f | 89 | * Start of New Year Procedure:: |
8973da3a | 90 | * Releasing GDB:: |
085dd6e6 | 91 | * Testsuite:: |
c906108c | 92 | * Hints:: |
aab4e0ec | 93 | |
bcd7e15f | 94 | * GDB Observers:: @value{GDBN} Currently available observers |
aab4e0ec | 95 | * GNU Free Documentation License:: The license for this documentation |
56caf160 | 96 | * Index:: |
c906108c SS |
97 | @end menu |
98 | ||
99 | @node Requirements | |
100 | ||
101 | @chapter Requirements | |
56caf160 | 102 | @cindex requirements for @value{GDBN} |
c906108c SS |
103 | |
104 | Before diving into the internals, you should understand the formal | |
56caf160 EZ |
105 | requirements and other expectations for @value{GDBN}. Although some |
106 | of these may seem obvious, there have been proposals for @value{GDBN} | |
107 | that have run counter to these requirements. | |
c906108c | 108 | |
56caf160 EZ |
109 | First of all, @value{GDBN} is a debugger. It's not designed to be a |
110 | front panel for embedded systems. It's not a text editor. It's not a | |
111 | shell. It's not a programming environment. | |
c906108c | 112 | |
56caf160 EZ |
113 | @value{GDBN} is an interactive tool. Although a batch mode is |
114 | available, @value{GDBN}'s primary role is to interact with a human | |
115 | programmer. | |
c906108c | 116 | |
56caf160 EZ |
117 | @value{GDBN} should be responsive to the user. A programmer hot on |
118 | the trail of a nasty bug, and operating under a looming deadline, is | |
119 | going to be very impatient of everything, including the response time | |
120 | to debugger commands. | |
c906108c | 121 | |
56caf160 EZ |
122 | @value{GDBN} should be relatively permissive, such as for expressions. |
123 | While the compiler should be picky (or have the option to be made | |
be9c6c35 | 124 | picky), since source code lives for a long time usually, the |
56caf160 EZ |
125 | programmer doing debugging shouldn't be spending time figuring out to |
126 | mollify the debugger. | |
c906108c | 127 | |
56caf160 EZ |
128 | @value{GDBN} will be called upon to deal with really large programs. |
129 | Executable sizes of 50 to 100 megabytes occur regularly, and we've | |
130 | heard reports of programs approaching 1 gigabyte in size. | |
c906108c | 131 | |
56caf160 EZ |
132 | @value{GDBN} should be able to run everywhere. No other debugger is |
133 | available for even half as many configurations as @value{GDBN} | |
134 | supports. | |
c906108c SS |
135 | |
136 | ||
137 | @node Overall Structure | |
138 | ||
139 | @chapter Overall Structure | |
140 | ||
56caf160 EZ |
141 | @value{GDBN} consists of three major subsystems: user interface, |
142 | symbol handling (the @dfn{symbol side}), and target system handling (the | |
143 | @dfn{target side}). | |
c906108c | 144 | |
2e685b93 | 145 | The user interface consists of several actual interfaces, plus |
c906108c SS |
146 | supporting code. |
147 | ||
148 | The symbol side consists of object file readers, debugging info | |
149 | interpreters, symbol table management, source language expression | |
150 | parsing, type and value printing. | |
151 | ||
152 | The target side consists of execution control, stack frame analysis, and | |
153 | physical target manipulation. | |
154 | ||
155 | The target side/symbol side division is not formal, and there are a | |
156 | number of exceptions. For instance, core file support involves symbolic | |
157 | elements (the basic core file reader is in BFD) and target elements (it | |
158 | supplies the contents of memory and the values of registers). Instead, | |
159 | this division is useful for understanding how the minor subsystems | |
160 | should fit together. | |
161 | ||
162 | @section The Symbol Side | |
163 | ||
56caf160 EZ |
164 | The symbolic side of @value{GDBN} can be thought of as ``everything |
165 | you can do in @value{GDBN} without having a live program running''. | |
166 | For instance, you can look at the types of variables, and evaluate | |
167 | many kinds of expressions. | |
c906108c SS |
168 | |
169 | @section The Target Side | |
170 | ||
56caf160 EZ |
171 | The target side of @value{GDBN} is the ``bits and bytes manipulator''. |
172 | Although it may make reference to symbolic info here and there, most | |
173 | of the target side will run with only a stripped executable | |
174 | available---or even no executable at all, in remote debugging cases. | |
c906108c SS |
175 | |
176 | Operations such as disassembly, stack frame crawls, and register | |
177 | display, are able to work with no symbolic info at all. In some cases, | |
25822942 | 178 | such as disassembly, @value{GDBN} will use symbolic info to present addresses |
c906108c SS |
179 | relative to symbols rather than as raw numbers, but it will work either |
180 | way. | |
181 | ||
182 | @section Configurations | |
183 | ||
56caf160 EZ |
184 | @cindex host |
185 | @cindex target | |
25822942 | 186 | @dfn{Host} refers to attributes of the system where @value{GDBN} runs. |
c906108c SS |
187 | @dfn{Target} refers to the system where the program being debugged |
188 | executes. In most cases they are the same machine, in which case a | |
189 | third type of @dfn{Native} attributes come into play. | |
190 | ||
191 | Defines and include files needed to build on the host are host support. | |
192 | Examples are tty support, system defined types, host byte order, host | |
193 | float format. | |
194 | ||
195 | Defines and information needed to handle the target format are target | |
196 | dependent. Examples are the stack frame format, instruction set, | |
197 | breakpoint instruction, registers, and how to set up and tear down the stack | |
198 | to call a function. | |
199 | ||
200 | Information that is only needed when the host and target are the same, | |
201 | is native dependent. One example is Unix child process support; if the | |
202 | host and target are not the same, doing a fork to start the target | |
203 | process is a bad idea. The various macros needed for finding the | |
204 | registers in the @code{upage}, running @code{ptrace}, and such are all | |
205 | in the native-dependent files. | |
206 | ||
207 | Another example of native-dependent code is support for features that | |
208 | are really part of the target environment, but which require | |
209 | @code{#include} files that are only available on the host system. Core | |
210 | file handling and @code{setjmp} handling are two common cases. | |
211 | ||
25822942 | 212 | When you want to make @value{GDBN} work ``native'' on a particular machine, you |
c906108c SS |
213 | have to include all three kinds of information. |
214 | ||
215 | ||
216 | @node Algorithms | |
217 | ||
218 | @chapter Algorithms | |
56caf160 | 219 | @cindex algorithms |
c906108c | 220 | |
56caf160 EZ |
221 | @value{GDBN} uses a number of debugging-specific algorithms. They are |
222 | often not very complicated, but get lost in the thicket of special | |
223 | cases and real-world issues. This chapter describes the basic | |
224 | algorithms and mentions some of the specific target definitions that | |
225 | they use. | |
c906108c SS |
226 | |
227 | @section Frames | |
228 | ||
56caf160 EZ |
229 | @cindex frame |
230 | @cindex call stack frame | |
231 | A frame is a construct that @value{GDBN} uses to keep track of calling | |
232 | and called functions. | |
c906108c | 233 | |
410dd08e JB |
234 | @cindex frame, unwind |
235 | @value{GDBN}'s current frame model is the result of an incremental | |
236 | cleanup of working code, not a fresh design, so it's a little weird. | |
237 | ||
238 | The natural model would have a frame object, with methods that read | |
239 | and write that frame's registers. Reading or writing the youngest | |
240 | frame's registers would simply read or write the processor's current | |
241 | registers, since the youngest frame is running directly on the | |
242 | processor. Older frames might have some registers saved on the stack | |
243 | by younger frames, so accessing the older frames' registers would do a | |
244 | mix of memory accesses and register accesses, as appropriate. | |
245 | ||
246 | @findex frame_register_unwind | |
247 | Instead, @value{GDBN}'s model is that you find a frame's registers by | |
248 | ``unwinding'' them from the next younger frame. That is, to access | |
249 | the registers of frame #1 (the next-to-youngest frame), you actually | |
250 | apply @code{frame_register_unwind} to frame #0 (the youngest frame). | |
251 | But then the obvious question is: how do you access the registers of | |
252 | the youngest frame itself? How do you ``unwind'' them when they're | |
253 | not wound up? | |
254 | ||
255 | @cindex sentinel frame | |
256 | @findex get_frame_type | |
257 | @vindex SENTINEL_FRAME | |
258 | To answer this question, GDB has the @dfn{sentinel} frame, the | |
259 | ``-1st'' frame. Unwinding registers from the sentinel frame gives you | |
260 | the current values of the youngest real frame's registers. If @var{f} | |
261 | is a sentinel frame, then @code{get_frame_type (@var{f}) == | |
262 | SENTINEL_FRAME}. | |
263 | ||
56caf160 EZ |
264 | @findex create_new_frame |
265 | @vindex FRAME_FP | |
c906108c | 266 | @code{FRAME_FP} in the machine description has no meaning to the |
56caf160 EZ |
267 | machine-independent part of @value{GDBN}, except that it is used when |
268 | setting up a new frame from scratch, as follows: | |
c906108c | 269 | |
474c8240 | 270 | @smallexample |
0ba6dca9 | 271 | create_new_frame (read_register (DEPRECATED_FP_REGNUM), read_pc ())); |
474c8240 | 272 | @end smallexample |
c906108c | 273 | |
56caf160 | 274 | @cindex frame pointer register |
0ba6dca9 AC |
275 | Other than that, all the meaning imparted to @code{DEPRECATED_FP_REGNUM} |
276 | is imparted by the machine-dependent code. So, | |
277 | @code{DEPRECATED_FP_REGNUM} can have any value that is convenient for | |
278 | the code that creates new frames. (@code{create_new_frame} calls | |
279 | @code{DEPRECATED_INIT_EXTRA_FRAME_INFO} if it is defined; that is where | |
280 | you should use the @code{DEPRECATED_FP_REGNUM} value, if your frames are | |
281 | nonstandard.) | |
c906108c | 282 | |
56caf160 | 283 | @cindex frame chain |
618ce49f AC |
284 | Given a @value{GDBN} frame, define @code{DEPRECATED_FRAME_CHAIN} to |
285 | determine the address of the calling function's frame. This will be | |
286 | used to create a new @value{GDBN} frame struct, and then | |
e9582e71 | 287 | @code{DEPRECATED_INIT_EXTRA_FRAME_INFO} and |
a5afb99f | 288 | @code{DEPRECATED_INIT_FRAME_PC} will be called for the new frame. |
c906108c SS |
289 | |
290 | @section Breakpoint Handling | |
291 | ||
56caf160 | 292 | @cindex breakpoints |
c906108c SS |
293 | In general, a breakpoint is a user-designated location in the program |
294 | where the user wants to regain control if program execution ever reaches | |
295 | that location. | |
296 | ||
297 | There are two main ways to implement breakpoints; either as ``hardware'' | |
298 | breakpoints or as ``software'' breakpoints. | |
299 | ||
56caf160 EZ |
300 | @cindex hardware breakpoints |
301 | @cindex program counter | |
c906108c SS |
302 | Hardware breakpoints are sometimes available as a builtin debugging |
303 | features with some chips. Typically these work by having dedicated | |
304 | register into which the breakpoint address may be stored. If the PC | |
56caf160 | 305 | (shorthand for @dfn{program counter}) |
c906108c | 306 | ever matches a value in a breakpoint registers, the CPU raises an |
56caf160 EZ |
307 | exception and reports it to @value{GDBN}. |
308 | ||
309 | Another possibility is when an emulator is in use; many emulators | |
310 | include circuitry that watches the address lines coming out from the | |
311 | processor, and force it to stop if the address matches a breakpoint's | |
312 | address. | |
313 | ||
314 | A third possibility is that the target already has the ability to do | |
315 | breakpoints somehow; for instance, a ROM monitor may do its own | |
316 | software breakpoints. So although these are not literally ``hardware | |
317 | breakpoints'', from @value{GDBN}'s point of view they work the same; | |
50e3ee83 | 318 | @value{GDBN} need not do anything more than set the breakpoint and wait |
56caf160 | 319 | for something to happen. |
c906108c SS |
320 | |
321 | Since they depend on hardware resources, hardware breakpoints may be | |
56caf160 | 322 | limited in number; when the user asks for more, @value{GDBN} will |
9742079a | 323 | start trying to set software breakpoints. (On some architectures, |
937f164b | 324 | notably the 32-bit x86 platforms, @value{GDBN} cannot always know |
9742079a EZ |
325 | whether there's enough hardware resources to insert all the hardware |
326 | breakpoints and watchpoints. On those platforms, @value{GDBN} prints | |
327 | an error message only when the program being debugged is continued.) | |
56caf160 EZ |
328 | |
329 | @cindex software breakpoints | |
330 | Software breakpoints require @value{GDBN} to do somewhat more work. | |
331 | The basic theory is that @value{GDBN} will replace a program | |
332 | instruction with a trap, illegal divide, or some other instruction | |
333 | that will cause an exception, and then when it's encountered, | |
334 | @value{GDBN} will take the exception and stop the program. When the | |
335 | user says to continue, @value{GDBN} will restore the original | |
c906108c SS |
336 | instruction, single-step, re-insert the trap, and continue on. |
337 | ||
338 | Since it literally overwrites the program being tested, the program area | |
be9c6c35 | 339 | must be writable, so this technique won't work on programs in ROM. It |
c906108c | 340 | can also distort the behavior of programs that examine themselves, |
56caf160 | 341 | although such a situation would be highly unusual. |
c906108c SS |
342 | |
343 | Also, the software breakpoint instruction should be the smallest size of | |
344 | instruction, so it doesn't overwrite an instruction that might be a jump | |
345 | target, and cause disaster when the program jumps into the middle of the | |
346 | breakpoint instruction. (Strictly speaking, the breakpoint must be no | |
347 | larger than the smallest interval between instructions that may be jump | |
348 | targets; perhaps there is an architecture where only even-numbered | |
349 | instructions may jumped to.) Note that it's possible for an instruction | |
350 | set not to have any instructions usable for a software breakpoint, | |
351 | although in practice only the ARC has failed to define such an | |
352 | instruction. | |
353 | ||
56caf160 | 354 | @findex BREAKPOINT |
c906108c SS |
355 | The basic definition of the software breakpoint is the macro |
356 | @code{BREAKPOINT}. | |
357 | ||
358 | Basic breakpoint object handling is in @file{breakpoint.c}. However, | |
359 | much of the interesting breakpoint action is in @file{infrun.c}. | |
360 | ||
361 | @section Single Stepping | |
362 | ||
363 | @section Signal Handling | |
364 | ||
365 | @section Thread Handling | |
366 | ||
367 | @section Inferior Function Calls | |
368 | ||
369 | @section Longjmp Support | |
370 | ||
56caf160 | 371 | @cindex @code{longjmp} debugging |
25822942 | 372 | @value{GDBN} has support for figuring out that the target is doing a |
c906108c SS |
373 | @code{longjmp} and for stopping at the target of the jump, if we are |
374 | stepping. This is done with a few specialized internal breakpoints, | |
56caf160 EZ |
375 | which are visible in the output of the @samp{maint info breakpoint} |
376 | command. | |
c906108c | 377 | |
56caf160 | 378 | @findex GET_LONGJMP_TARGET |
c906108c SS |
379 | To make this work, you need to define a macro called |
380 | @code{GET_LONGJMP_TARGET}, which will examine the @code{jmp_buf} | |
381 | structure and extract the longjmp target address. Since @code{jmp_buf} | |
382 | is target specific, you will need to define it in the appropriate | |
56caf160 | 383 | @file{tm-@var{target}.h} file. Look in @file{tm-sun4os4.h} and |
c906108c SS |
384 | @file{sparc-tdep.c} for examples of how to do this. |
385 | ||
9742079a EZ |
386 | @section Watchpoints |
387 | @cindex watchpoints | |
388 | ||
389 | Watchpoints are a special kind of breakpoints (@pxref{Algorithms, | |
390 | breakpoints}) which break when data is accessed rather than when some | |
391 | instruction is executed. When you have data which changes without | |
392 | your knowing what code does that, watchpoints are the silver bullet to | |
393 | hunt down and kill such bugs. | |
394 | ||
395 | @cindex hardware watchpoints | |
396 | @cindex software watchpoints | |
397 | Watchpoints can be either hardware-assisted or not; the latter type is | |
398 | known as ``software watchpoints.'' @value{GDBN} always uses | |
399 | hardware-assisted watchpoints if they are available, and falls back on | |
400 | software watchpoints otherwise. Typical situations where @value{GDBN} | |
401 | will use software watchpoints are: | |
402 | ||
403 | @itemize @bullet | |
404 | @item | |
405 | The watched memory region is too large for the underlying hardware | |
406 | watchpoint support. For example, each x86 debug register can watch up | |
407 | to 4 bytes of memory, so trying to watch data structures whose size is | |
408 | more than 16 bytes will cause @value{GDBN} to use software | |
409 | watchpoints. | |
410 | ||
411 | @item | |
412 | The value of the expression to be watched depends on data held in | |
413 | registers (as opposed to memory). | |
414 | ||
415 | @item | |
416 | Too many different watchpoints requested. (On some architectures, | |
417 | this situation is impossible to detect until the debugged program is | |
418 | resumed.) Note that x86 debug registers are used both for hardware | |
419 | breakpoints and for watchpoints, so setting too many hardware | |
420 | breakpoints might cause watchpoint insertion to fail. | |
421 | ||
422 | @item | |
423 | No hardware-assisted watchpoints provided by the target | |
424 | implementation. | |
425 | @end itemize | |
426 | ||
427 | Software watchpoints are very slow, since @value{GDBN} needs to | |
428 | single-step the program being debugged and test the value of the | |
429 | watched expression(s) after each instruction. The rest of this | |
430 | section is mostly irrelevant for software watchpoints. | |
431 | ||
b6b8ece6 EZ |
432 | When the inferior stops, @value{GDBN} tries to establish, among other |
433 | possible reasons, whether it stopped due to a watchpoint being hit. | |
434 | For a data-write watchpoint, it does so by evaluating, for each | |
435 | watchpoint, the expression whose value is being watched, and testing | |
436 | whether the watched value has changed. For data-read and data-access | |
437 | watchpoints, @value{GDBN} needs the target to supply a primitive that | |
438 | returns the address of the data that was accessed or read (see the | |
439 | description of @code{target_stopped_data_address} below): if this | |
440 | primitive returns a valid address, @value{GDBN} infers that a | |
441 | watchpoint triggered if it watches an expression whose evaluation uses | |
442 | that address. | |
443 | ||
9742079a EZ |
444 | @value{GDBN} uses several macros and primitives to support hardware |
445 | watchpoints: | |
446 | ||
447 | @table @code | |
448 | @findex TARGET_HAS_HARDWARE_WATCHPOINTS | |
449 | @item TARGET_HAS_HARDWARE_WATCHPOINTS | |
450 | If defined, the target supports hardware watchpoints. | |
451 | ||
452 | @findex TARGET_CAN_USE_HARDWARE_WATCHPOINT | |
453 | @item TARGET_CAN_USE_HARDWARE_WATCHPOINT (@var{type}, @var{count}, @var{other}) | |
454 | Return the number of hardware watchpoints of type @var{type} that are | |
455 | possible to be set. The value is positive if @var{count} watchpoints | |
456 | of this type can be set, zero if setting watchpoints of this type is | |
457 | not supported, and negative if @var{count} is more than the maximum | |
458 | number of watchpoints of type @var{type} that can be set. @var{other} | |
459 | is non-zero if other types of watchpoints are currently enabled (there | |
460 | are architectures which cannot set watchpoints of different types at | |
461 | the same time). | |
462 | ||
463 | @findex TARGET_REGION_OK_FOR_HW_WATCHPOINT | |
464 | @item TARGET_REGION_OK_FOR_HW_WATCHPOINT (@var{addr}, @var{len}) | |
465 | Return non-zero if hardware watchpoints can be used to watch a region | |
466 | whose address is @var{addr} and whose length in bytes is @var{len}. | |
467 | ||
468 | @findex TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT | |
469 | @item TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (@var{size}) | |
470 | Return non-zero if hardware watchpoints can be used to watch a region | |
471 | whose size is @var{size}. @value{GDBN} only uses this macro as a | |
472 | fall-back, in case @code{TARGET_REGION_OK_FOR_HW_WATCHPOINT} is not | |
473 | defined. | |
474 | ||
b6b8ece6 | 475 | @cindex insert or remove hardware watchpoint |
9742079a EZ |
476 | @findex target_insert_watchpoint |
477 | @findex target_remove_watchpoint | |
478 | @item target_insert_watchpoint (@var{addr}, @var{len}, @var{type}) | |
479 | @itemx target_remove_watchpoint (@var{addr}, @var{len}, @var{type}) | |
480 | Insert or remove a hardware watchpoint starting at @var{addr}, for | |
481 | @var{len} bytes. @var{type} is the watchpoint type, one of the | |
482 | possible values of the enumerated data type @code{target_hw_bp_type}, | |
483 | defined by @file{breakpoint.h} as follows: | |
484 | ||
474c8240 | 485 | @smallexample |
9742079a EZ |
486 | enum target_hw_bp_type |
487 | @{ | |
488 | hw_write = 0, /* Common (write) HW watchpoint */ | |
489 | hw_read = 1, /* Read HW watchpoint */ | |
490 | hw_access = 2, /* Access (read or write) HW watchpoint */ | |
491 | hw_execute = 3 /* Execute HW breakpoint */ | |
492 | @}; | |
474c8240 | 493 | @end smallexample |
9742079a EZ |
494 | |
495 | @noindent | |
496 | These two macros should return 0 for success, non-zero for failure. | |
497 | ||
498 | @cindex insert or remove hardware breakpoint | |
499 | @findex target_remove_hw_breakpoint | |
500 | @findex target_insert_hw_breakpoint | |
501 | @item target_remove_hw_breakpoint (@var{addr}, @var{shadow}) | |
502 | @itemx target_insert_hw_breakpoint (@var{addr}, @var{shadow}) | |
503 | Insert or remove a hardware-assisted breakpoint at address @var{addr}. | |
504 | Returns zero for success, non-zero for failure. @var{shadow} is the | |
505 | real contents of the byte where the breakpoint has been inserted; it | |
506 | is generally not valid when hardware breakpoints are used, but since | |
507 | no other code touches these values, the implementations of the above | |
508 | two macros can use them for their internal purposes. | |
509 | ||
510 | @findex target_stopped_data_address | |
ac77d04f JJ |
511 | @item target_stopped_data_address (@var{addr_p}) |
512 | If the inferior has some watchpoint that triggered, place the address | |
513 | associated with the watchpoint at the location pointed to by | |
b6b8ece6 EZ |
514 | @var{addr_p} and return non-zero. Otherwise, return zero. Note that |
515 | this primitive is used by @value{GDBN} only on targets that support | |
516 | data-read or data-access type watchpoints, so targets that have | |
517 | support only for data-write watchpoints need not implement these | |
518 | primitives. | |
9742079a | 519 | |
9742079a EZ |
520 | @findex HAVE_STEPPABLE_WATCHPOINT |
521 | @item HAVE_STEPPABLE_WATCHPOINT | |
522 | If defined to a non-zero value, it is not necessary to disable a | |
523 | watchpoint to step over it. | |
524 | ||
525 | @findex HAVE_NONSTEPPABLE_WATCHPOINT | |
526 | @item HAVE_NONSTEPPABLE_WATCHPOINT | |
527 | If defined to a non-zero value, @value{GDBN} should disable a | |
528 | watchpoint to step the inferior over it. | |
529 | ||
530 | @findex HAVE_CONTINUABLE_WATCHPOINT | |
531 | @item HAVE_CONTINUABLE_WATCHPOINT | |
532 | If defined to a non-zero value, it is possible to continue the | |
533 | inferior after a watchpoint has been hit. | |
534 | ||
535 | @findex CANNOT_STEP_HW_WATCHPOINTS | |
536 | @item CANNOT_STEP_HW_WATCHPOINTS | |
537 | If this is defined to a non-zero value, @value{GDBN} will remove all | |
538 | watchpoints before stepping the inferior. | |
539 | ||
540 | @findex STOPPED_BY_WATCHPOINT | |
541 | @item STOPPED_BY_WATCHPOINT (@var{wait_status}) | |
542 | Return non-zero if stopped by a watchpoint. @var{wait_status} is of | |
543 | the type @code{struct target_waitstatus}, defined by @file{target.h}. | |
b6b8ece6 EZ |
544 | Normally, this macro is defined to invoke the function pointed to by |
545 | the @code{to_stopped_by_watchpoint} member of the structure (of the | |
546 | type @code{target_ops}, defined on @file{target.h}) that describes the | |
547 | target-specific operations; @code{to_stopped_by_watchpoint} ignores | |
548 | the @var{wait_status} argument. | |
549 | ||
550 | @value{GDBN} does not require the non-zero value returned by | |
551 | @code{STOPPED_BY_WATCHPOINT} to be 100% correct, so if a target cannot | |
552 | determine for sure whether the inferior stopped due to a watchpoint, | |
553 | it could return non-zero ``just in case''. | |
9742079a EZ |
554 | @end table |
555 | ||
556 | @subsection x86 Watchpoints | |
557 | @cindex x86 debug registers | |
558 | @cindex watchpoints, on x86 | |
559 | ||
560 | The 32-bit Intel x86 (a.k.a.@: ia32) processors feature special debug | |
561 | registers designed to facilitate debugging. @value{GDBN} provides a | |
562 | generic library of functions that x86-based ports can use to implement | |
563 | support for watchpoints and hardware-assisted breakpoints. This | |
564 | subsection documents the x86 watchpoint facilities in @value{GDBN}. | |
565 | ||
566 | To use the generic x86 watchpoint support, a port should do the | |
567 | following: | |
568 | ||
569 | @itemize @bullet | |
570 | @findex I386_USE_GENERIC_WATCHPOINTS | |
571 | @item | |
572 | Define the macro @code{I386_USE_GENERIC_WATCHPOINTS} somewhere in the | |
573 | target-dependent headers. | |
574 | ||
575 | @item | |
576 | Include the @file{config/i386/nm-i386.h} header file @emph{after} | |
577 | defining @code{I386_USE_GENERIC_WATCHPOINTS}. | |
578 | ||
579 | @item | |
580 | Add @file{i386-nat.o} to the value of the Make variable | |
581 | @code{NATDEPFILES} (@pxref{Native Debugging, NATDEPFILES}) or | |
582 | @code{TDEPFILES} (@pxref{Target Architecture Definition, TDEPFILES}). | |
583 | ||
584 | @item | |
585 | Provide implementations for the @code{I386_DR_LOW_*} macros described | |
586 | below. Typically, each macro should call a target-specific function | |
587 | which does the real work. | |
588 | @end itemize | |
589 | ||
590 | The x86 watchpoint support works by maintaining mirror images of the | |
591 | debug registers. Values are copied between the mirror images and the | |
592 | real debug registers via a set of macros which each target needs to | |
593 | provide: | |
594 | ||
595 | @table @code | |
596 | @findex I386_DR_LOW_SET_CONTROL | |
597 | @item I386_DR_LOW_SET_CONTROL (@var{val}) | |
598 | Set the Debug Control (DR7) register to the value @var{val}. | |
599 | ||
600 | @findex I386_DR_LOW_SET_ADDR | |
601 | @item I386_DR_LOW_SET_ADDR (@var{idx}, @var{addr}) | |
602 | Put the address @var{addr} into the debug register number @var{idx}. | |
603 | ||
604 | @findex I386_DR_LOW_RESET_ADDR | |
605 | @item I386_DR_LOW_RESET_ADDR (@var{idx}) | |
606 | Reset (i.e.@: zero out) the address stored in the debug register | |
607 | number @var{idx}. | |
608 | ||
609 | @findex I386_DR_LOW_GET_STATUS | |
610 | @item I386_DR_LOW_GET_STATUS | |
611 | Return the value of the Debug Status (DR6) register. This value is | |
612 | used immediately after it is returned by | |
613 | @code{I386_DR_LOW_GET_STATUS}, so as to support per-thread status | |
614 | register values. | |
615 | @end table | |
616 | ||
617 | For each one of the 4 debug registers (whose indices are from 0 to 3) | |
618 | that store addresses, a reference count is maintained by @value{GDBN}, | |
619 | to allow sharing of debug registers by several watchpoints. This | |
620 | allows users to define several watchpoints that watch the same | |
621 | expression, but with different conditions and/or commands, without | |
622 | wasting debug registers which are in short supply. @value{GDBN} | |
623 | maintains the reference counts internally, targets don't have to do | |
624 | anything to use this feature. | |
625 | ||
626 | The x86 debug registers can each watch a region that is 1, 2, or 4 | |
627 | bytes long. The ia32 architecture requires that each watched region | |
628 | be appropriately aligned: 2-byte region on 2-byte boundary, 4-byte | |
629 | region on 4-byte boundary. However, the x86 watchpoint support in | |
630 | @value{GDBN} can watch unaligned regions and regions larger than 4 | |
631 | bytes (up to 16 bytes) by allocating several debug registers to watch | |
632 | a single region. This allocation of several registers per a watched | |
633 | region is also done automatically without target code intervention. | |
634 | ||
635 | The generic x86 watchpoint support provides the following API for the | |
636 | @value{GDBN}'s application code: | |
637 | ||
638 | @table @code | |
639 | @findex i386_region_ok_for_watchpoint | |
640 | @item i386_region_ok_for_watchpoint (@var{addr}, @var{len}) | |
641 | The macro @code{TARGET_REGION_OK_FOR_HW_WATCHPOINT} is set to call | |
642 | this function. It counts the number of debug registers required to | |
643 | watch a given region, and returns a non-zero value if that number is | |
644 | less than 4, the number of debug registers available to x86 | |
645 | processors. | |
646 | ||
647 | @findex i386_stopped_data_address | |
ac77d04f JJ |
648 | @item i386_stopped_data_address (@var{addr_p}) |
649 | The target function | |
650 | @code{target_stopped_data_address} is set to call this function. | |
651 | This | |
9742079a EZ |
652 | function examines the breakpoint condition bits in the DR6 Debug |
653 | Status register, as returned by the @code{I386_DR_LOW_GET_STATUS} | |
654 | macro, and returns the address associated with the first bit that is | |
655 | set in DR6. | |
656 | ||
ac77d04f JJ |
657 | @findex i386_stopped_by_watchpoint |
658 | @item i386_stopped_by_watchpoint (void) | |
659 | The macro @code{STOPPED_BY_WATCHPOINT} | |
660 | is set to call this function. The | |
661 | argument passed to @code{STOPPED_BY_WATCHPOINT} is ignored. This | |
662 | function examines the breakpoint condition bits in the DR6 Debug | |
663 | Status register, as returned by the @code{I386_DR_LOW_GET_STATUS} | |
664 | macro, and returns true if any bit is set. Otherwise, false is | |
665 | returned. | |
666 | ||
9742079a EZ |
667 | @findex i386_insert_watchpoint |
668 | @findex i386_remove_watchpoint | |
669 | @item i386_insert_watchpoint (@var{addr}, @var{len}, @var{type}) | |
670 | @itemx i386_remove_watchpoint (@var{addr}, @var{len}, @var{type}) | |
671 | Insert or remove a watchpoint. The macros | |
672 | @code{target_insert_watchpoint} and @code{target_remove_watchpoint} | |
673 | are set to call these functions. @code{i386_insert_watchpoint} first | |
674 | looks for a debug register which is already set to watch the same | |
675 | region for the same access types; if found, it just increments the | |
676 | reference count of that debug register, thus implementing debug | |
677 | register sharing between watchpoints. If no such register is found, | |
937f164b FF |
678 | the function looks for a vacant debug register, sets its mirrored |
679 | value to @var{addr}, sets the mirrored value of DR7 Debug Control | |
9742079a EZ |
680 | register as appropriate for the @var{len} and @var{type} parameters, |
681 | and then passes the new values of the debug register and DR7 to the | |
682 | inferior by calling @code{I386_DR_LOW_SET_ADDR} and | |
683 | @code{I386_DR_LOW_SET_CONTROL}. If more than one debug register is | |
684 | required to cover the given region, the above process is repeated for | |
685 | each debug register. | |
686 | ||
687 | @code{i386_remove_watchpoint} does the opposite: it resets the address | |
937f164b FF |
688 | in the mirrored value of the debug register and its read/write and |
689 | length bits in the mirrored value of DR7, then passes these new | |
9742079a EZ |
690 | values to the inferior via @code{I386_DR_LOW_RESET_ADDR} and |
691 | @code{I386_DR_LOW_SET_CONTROL}. If a register is shared by several | |
692 | watchpoints, each time a @code{i386_remove_watchpoint} is called, it | |
693 | decrements the reference count, and only calls | |
694 | @code{I386_DR_LOW_RESET_ADDR} and @code{I386_DR_LOW_SET_CONTROL} when | |
695 | the count goes to zero. | |
696 | ||
697 | @findex i386_insert_hw_breakpoint | |
698 | @findex i386_remove_hw_breakpoint | |
699 | @item i386_insert_hw_breakpoint (@var{addr}, @var{shadow} | |
700 | @itemx i386_remove_hw_breakpoint (@var{addr}, @var{shadow}) | |
701 | These functions insert and remove hardware-assisted breakpoints. The | |
702 | macros @code{target_insert_hw_breakpoint} and | |
703 | @code{target_remove_hw_breakpoint} are set to call these functions. | |
704 | These functions work like @code{i386_insert_watchpoint} and | |
705 | @code{i386_remove_watchpoint}, respectively, except that they set up | |
706 | the debug registers to watch instruction execution, and each | |
707 | hardware-assisted breakpoint always requires exactly one debug | |
708 | register. | |
709 | ||
710 | @findex i386_stopped_by_hwbp | |
711 | @item i386_stopped_by_hwbp (void) | |
712 | This function returns non-zero if the inferior has some watchpoint or | |
713 | hardware breakpoint that triggered. It works like | |
ac77d04f | 714 | @code{i386_stopped_data_address}, except that it doesn't record the |
9742079a EZ |
715 | address whose watchpoint triggered. |
716 | ||
717 | @findex i386_cleanup_dregs | |
718 | @item i386_cleanup_dregs (void) | |
719 | This function clears all the reference counts, addresses, and control | |
720 | bits in the mirror images of the debug registers. It doesn't affect | |
721 | the actual debug registers in the inferior process. | |
722 | @end table | |
723 | ||
724 | @noindent | |
725 | @strong{Notes:} | |
726 | @enumerate 1 | |
727 | @item | |
728 | x86 processors support setting watchpoints on I/O reads or writes. | |
729 | However, since no target supports this (as of March 2001), and since | |
730 | @code{enum target_hw_bp_type} doesn't even have an enumeration for I/O | |
731 | watchpoints, this feature is not yet available to @value{GDBN} running | |
732 | on x86. | |
733 | ||
734 | @item | |
735 | x86 processors can enable watchpoints locally, for the current task | |
736 | only, or globally, for all the tasks. For each debug register, | |
737 | there's a bit in the DR7 Debug Control register that determines | |
738 | whether the associated address is watched locally or globally. The | |
739 | current implementation of x86 watchpoint support in @value{GDBN} | |
740 | always sets watchpoints to be locally enabled, since global | |
741 | watchpoints might interfere with the underlying OS and are probably | |
742 | unavailable in many platforms. | |
743 | @end enumerate | |
744 | ||
5c95884b MS |
745 | @section Checkpoints |
746 | @cindex checkpoints | |
747 | @cindex restart | |
748 | In the abstract, a checkpoint is a point in the execution history of | |
749 | the program, which the user may wish to return to at some later time. | |
750 | ||
751 | Internally, a checkpoint is a saved copy of the program state, including | |
752 | whatever information is required in order to restore the program to that | |
753 | state at a later time. This can be expected to include the state of | |
754 | registers and memory, and may include external state such as the state | |
755 | of open files and devices. | |
756 | ||
757 | There are a number of ways in which checkpoints may be implemented | |
758 | in gdb, eg. as corefiles, as forked processes, and as some opaque | |
759 | method implemented on the target side. | |
760 | ||
761 | A corefile can be used to save an image of target memory and register | |
762 | state, which can in principle be restored later --- but corefiles do | |
763 | not typically include information about external entities such as | |
764 | open files. Currently this method is not implemented in gdb. | |
765 | ||
766 | A forked process can save the state of user memory and registers, | |
767 | as well as some subset of external (kernel) state. This method | |
768 | is used to implement checkpoints on Linux, and in principle might | |
769 | be used on other systems. | |
770 | ||
771 | Some targets, eg.@: simulators, might have their own built-in | |
772 | method for saving checkpoints, and gdb might be able to take | |
773 | advantage of that capability without necessarily knowing any | |
774 | details of how it is done. | |
775 | ||
776 | ||
bcd7e15f JB |
777 | @section Observing changes in @value{GDBN} internals |
778 | @cindex observer pattern interface | |
779 | @cindex notifications about changes in internals | |
780 | ||
781 | In order to function properly, several modules need to be notified when | |
782 | some changes occur in the @value{GDBN} internals. Traditionally, these | |
783 | modules have relied on several paradigms, the most common ones being | |
784 | hooks and gdb-events. Unfortunately, none of these paradigms was | |
785 | versatile enough to become the standard notification mechanism in | |
786 | @value{GDBN}. The fact that they only supported one ``client'' was also | |
787 | a strong limitation. | |
788 | ||
789 | A new paradigm, based on the Observer pattern of the @cite{Design | |
790 | Patterns} book, has therefore been implemented. The goal was to provide | |
791 | a new interface overcoming the issues with the notification mechanisms | |
792 | previously available. This new interface needed to be strongly typed, | |
793 | easy to extend, and versatile enough to be used as the standard | |
794 | interface when adding new notifications. | |
795 | ||
796 | See @ref{GDB Observers} for a brief description of the observers | |
797 | currently implemented in GDB. The rationale for the current | |
798 | implementation is also briefly discussed. | |
799 | ||
c906108c SS |
800 | @node User Interface |
801 | ||
802 | @chapter User Interface | |
803 | ||
25822942 | 804 | @value{GDBN} has several user interfaces. Although the command-line interface |
c906108c SS |
805 | is the most common and most familiar, there are others. |
806 | ||
807 | @section Command Interpreter | |
808 | ||
56caf160 | 809 | @cindex command interpreter |
0ee54786 | 810 | @cindex CLI |
25822942 | 811 | The command interpreter in @value{GDBN} is fairly simple. It is designed to |
c906108c SS |
812 | allow for the set of commands to be augmented dynamically, and also |
813 | has a recursive subcommand capability, where the first argument to | |
814 | a command may itself direct a lookup on a different command list. | |
815 | ||
56caf160 EZ |
816 | For instance, the @samp{set} command just starts a lookup on the |
817 | @code{setlist} command list, while @samp{set thread} recurses | |
c906108c SS |
818 | to the @code{set_thread_cmd_list}. |
819 | ||
56caf160 EZ |
820 | @findex add_cmd |
821 | @findex add_com | |
c906108c SS |
822 | To add commands in general, use @code{add_cmd}. @code{add_com} adds to |
823 | the main command list, and should be used for those commands. The usual | |
cfeada60 | 824 | place to add commands is in the @code{_initialize_@var{xyz}} routines at |
9742079a | 825 | the ends of most source files. |
cfeada60 | 826 | |
40dd2248 TT |
827 | @findex add_setshow_cmd |
828 | @findex add_setshow_cmd_full | |
829 | To add paired @samp{set} and @samp{show} commands, use | |
830 | @code{add_setshow_cmd} or @code{add_setshow_cmd_full}. The former is | |
831 | a slightly simpler interface which is useful when you don't need to | |
832 | further modify the new command structures, while the latter returns | |
833 | the new command structures for manipulation. | |
834 | ||
56caf160 EZ |
835 | @cindex deprecating commands |
836 | @findex deprecate_cmd | |
cfeada60 FN |
837 | Before removing commands from the command set it is a good idea to |
838 | deprecate them for some time. Use @code{deprecate_cmd} on commands or | |
839 | aliases to set the deprecated flag. @code{deprecate_cmd} takes a | |
840 | @code{struct cmd_list_element} as it's first argument. You can use the | |
841 | return value from @code{add_com} or @code{add_cmd} to deprecate the | |
842 | command immediately after it is created. | |
843 | ||
c72e7388 | 844 | The first time a command is used the user will be warned and offered a |
cfeada60 FN |
845 | replacement (if one exists). Note that the replacement string passed to |
846 | @code{deprecate_cmd} should be the full name of the command, i.e. the | |
847 | entire string the user should type at the command line. | |
c906108c | 848 | |
0ee54786 EZ |
849 | @section UI-Independent Output---the @code{ui_out} Functions |
850 | @c This section is based on the documentation written by Fernando | |
851 | @c Nasser <fnasser@redhat.com>. | |
852 | ||
853 | @cindex @code{ui_out} functions | |
854 | The @code{ui_out} functions present an abstraction level for the | |
855 | @value{GDBN} output code. They hide the specifics of different user | |
856 | interfaces supported by @value{GDBN}, and thus free the programmer | |
857 | from the need to write several versions of the same code, one each for | |
858 | every UI, to produce output. | |
859 | ||
860 | @subsection Overview and Terminology | |
861 | ||
862 | In general, execution of each @value{GDBN} command produces some sort | |
863 | of output, and can even generate an input request. | |
864 | ||
865 | Output can be generated for the following purposes: | |
866 | ||
867 | @itemize @bullet | |
868 | @item | |
869 | to display a @emph{result} of an operation; | |
870 | ||
871 | @item | |
872 | to convey @emph{info} or produce side-effects of a requested | |
873 | operation; | |
874 | ||
875 | @item | |
876 | to provide a @emph{notification} of an asynchronous event (including | |
877 | progress indication of a prolonged asynchronous operation); | |
878 | ||
879 | @item | |
880 | to display @emph{error messages} (including warnings); | |
881 | ||
882 | @item | |
883 | to show @emph{debug data}; | |
884 | ||
885 | @item | |
886 | to @emph{query} or prompt a user for input (a special case). | |
887 | @end itemize | |
888 | ||
889 | @noindent | |
890 | This section mainly concentrates on how to build result output, | |
891 | although some of it also applies to other kinds of output. | |
892 | ||
893 | Generation of output that displays the results of an operation | |
894 | involves one or more of the following: | |
895 | ||
896 | @itemize @bullet | |
897 | @item | |
898 | output of the actual data | |
899 | ||
900 | @item | |
901 | formatting the output as appropriate for console output, to make it | |
902 | easily readable by humans | |
903 | ||
904 | @item | |
905 | machine oriented formatting--a more terse formatting to allow for easy | |
906 | parsing by programs which read @value{GDBN}'s output | |
907 | ||
908 | @item | |
c72e7388 AC |
909 | annotation, whose purpose is to help legacy GUIs to identify interesting |
910 | parts in the output | |
0ee54786 EZ |
911 | @end itemize |
912 | ||
913 | The @code{ui_out} routines take care of the first three aspects. | |
c72e7388 AC |
914 | Annotations are provided by separate annotation routines. Note that use |
915 | of annotations for an interface between a GUI and @value{GDBN} is | |
0ee54786 EZ |
916 | deprecated. |
917 | ||
c72e7388 AC |
918 | Output can be in the form of a single item, which we call a @dfn{field}; |
919 | a @dfn{list} consisting of identical fields; a @dfn{tuple} consisting of | |
920 | non-identical fields; or a @dfn{table}, which is a tuple consisting of a | |
921 | header and a body. In a BNF-like form: | |
0ee54786 | 922 | |
c72e7388 AC |
923 | @table @code |
924 | @item <table> @expansion{} | |
925 | @code{<header> <body>} | |
926 | @item <header> @expansion{} | |
927 | @code{@{ <column> @}} | |
928 | @item <column> @expansion{} | |
929 | @code{<width> <alignment> <title>} | |
930 | @item <body> @expansion{} | |
931 | @code{@{<row>@}} | |
932 | @end table | |
0ee54786 EZ |
933 | |
934 | ||
935 | @subsection General Conventions | |
936 | ||
c72e7388 AC |
937 | Most @code{ui_out} routines are of type @code{void}, the exceptions are |
938 | @code{ui_out_stream_new} (which returns a pointer to the newly created | |
939 | object) and the @code{make_cleanup} routines. | |
0ee54786 | 940 | |
c72e7388 AC |
941 | The first parameter is always the @code{ui_out} vector object, a pointer |
942 | to a @code{struct ui_out}. | |
0ee54786 | 943 | |
c72e7388 AC |
944 | The @var{format} parameter is like in @code{printf} family of functions. |
945 | When it is present, there must also be a variable list of arguments | |
946 | sufficient used to satisfy the @code{%} specifiers in the supplied | |
0ee54786 EZ |
947 | format. |
948 | ||
c72e7388 AC |
949 | When a character string argument is not used in a @code{ui_out} function |
950 | call, a @code{NULL} pointer has to be supplied instead. | |
0ee54786 EZ |
951 | |
952 | ||
c72e7388 | 953 | @subsection Table, Tuple and List Functions |
0ee54786 EZ |
954 | |
955 | @cindex list output functions | |
956 | @cindex table output functions | |
c72e7388 AC |
957 | @cindex tuple output functions |
958 | This section introduces @code{ui_out} routines for building lists, | |
959 | tuples and tables. The routines to output the actual data items | |
960 | (fields) are presented in the next section. | |
0ee54786 | 961 | |
c72e7388 AC |
962 | To recap: A @dfn{tuple} is a sequence of @dfn{fields}, each field |
963 | containing information about an object; a @dfn{list} is a sequence of | |
964 | fields where each field describes an identical object. | |
0ee54786 | 965 | |
c72e7388 AC |
966 | Use the @dfn{table} functions when your output consists of a list of |
967 | rows (tuples) and the console output should include a heading. Use this | |
968 | even when you are listing just one object but you still want the header. | |
0ee54786 EZ |
969 | |
970 | @cindex nesting level in @code{ui_out} functions | |
c72e7388 AC |
971 | Tables can not be nested. Tuples and lists can be nested up to a |
972 | maximum of five levels. | |
0ee54786 EZ |
973 | |
974 | The overall structure of the table output code is something like this: | |
975 | ||
474c8240 | 976 | @smallexample |
0ee54786 EZ |
977 | ui_out_table_begin |
978 | ui_out_table_header | |
c72e7388 | 979 | @dots{} |
0ee54786 | 980 | ui_out_table_body |
c72e7388 | 981 | ui_out_tuple_begin |
0ee54786 | 982 | ui_out_field_* |
c72e7388 AC |
983 | @dots{} |
984 | ui_out_tuple_end | |
985 | @dots{} | |
0ee54786 | 986 | ui_out_table_end |
474c8240 | 987 | @end smallexample |
0ee54786 | 988 | |
c72e7388 | 989 | Here is the description of table-, tuple- and list-related @code{ui_out} |
0ee54786 EZ |
990 | functions: |
991 | ||
c72e7388 AC |
992 | @deftypefun void ui_out_table_begin (struct ui_out *@var{uiout}, int @var{nbrofcols}, int @var{nr_rows}, const char *@var{tblid}) |
993 | The function @code{ui_out_table_begin} marks the beginning of the output | |
994 | of a table. It should always be called before any other @code{ui_out} | |
995 | function for a given table. @var{nbrofcols} is the number of columns in | |
996 | the table. @var{nr_rows} is the number of rows in the table. | |
997 | @var{tblid} is an optional string identifying the table. The string | |
998 | pointed to by @var{tblid} is copied by the implementation of | |
999 | @code{ui_out_table_begin}, so the application can free the string if it | |
1000 | was @code{malloc}ed. | |
0ee54786 EZ |
1001 | |
1002 | The companion function @code{ui_out_table_end}, described below, marks | |
1003 | the end of the table's output. | |
1004 | @end deftypefun | |
1005 | ||
c72e7388 AC |
1006 | @deftypefun void ui_out_table_header (struct ui_out *@var{uiout}, int @var{width}, enum ui_align @var{alignment}, const char *@var{colhdr}) |
1007 | @code{ui_out_table_header} provides the header information for a single | |
1008 | table column. You call this function several times, one each for every | |
1009 | column of the table, after @code{ui_out_table_begin}, but before | |
1010 | @code{ui_out_table_body}. | |
0ee54786 EZ |
1011 | |
1012 | The value of @var{width} gives the column width in characters. The | |
1013 | value of @var{alignment} is one of @code{left}, @code{center}, and | |
1014 | @code{right}, and it specifies how to align the header: left-justify, | |
1015 | center, or right-justify it. @var{colhdr} points to a string that | |
1016 | specifies the column header; the implementation copies that string, so | |
c72e7388 AC |
1017 | column header strings in @code{malloc}ed storage can be freed after the |
1018 | call. | |
0ee54786 EZ |
1019 | @end deftypefun |
1020 | ||
1021 | @deftypefun void ui_out_table_body (struct ui_out *@var{uiout}) | |
c72e7388 | 1022 | This function delimits the table header from the table body. |
0ee54786 EZ |
1023 | @end deftypefun |
1024 | ||
1025 | @deftypefun void ui_out_table_end (struct ui_out *@var{uiout}) | |
c72e7388 AC |
1026 | This function signals the end of a table's output. It should be called |
1027 | after the table body has been produced by the list and field output | |
1028 | functions. | |
0ee54786 EZ |
1029 | |
1030 | There should be exactly one call to @code{ui_out_table_end} for each | |
c72e7388 AC |
1031 | call to @code{ui_out_table_begin}, otherwise the @code{ui_out} functions |
1032 | will signal an internal error. | |
0ee54786 EZ |
1033 | @end deftypefun |
1034 | ||
c72e7388 | 1035 | The output of the tuples that represent the table rows must follow the |
0ee54786 | 1036 | call to @code{ui_out_table_body} and precede the call to |
c72e7388 AC |
1037 | @code{ui_out_table_end}. You build a tuple by calling |
1038 | @code{ui_out_tuple_begin} and @code{ui_out_tuple_end}, with suitable | |
0ee54786 EZ |
1039 | calls to functions which actually output fields between them. |
1040 | ||
c72e7388 AC |
1041 | @deftypefun void ui_out_tuple_begin (struct ui_out *@var{uiout}, const char *@var{id}) |
1042 | This function marks the beginning of a tuple output. @var{id} points | |
1043 | to an optional string that identifies the tuple; it is copied by the | |
1044 | implementation, and so strings in @code{malloc}ed storage can be freed | |
1045 | after the call. | |
1046 | @end deftypefun | |
1047 | ||
1048 | @deftypefun void ui_out_tuple_end (struct ui_out *@var{uiout}) | |
1049 | This function signals an end of a tuple output. There should be exactly | |
1050 | one call to @code{ui_out_tuple_end} for each call to | |
1051 | @code{ui_out_tuple_begin}, otherwise an internal @value{GDBN} error will | |
1052 | be signaled. | |
1053 | @end deftypefun | |
1054 | ||
1055 | @deftypefun struct cleanup *make_cleanup_ui_out_tuple_begin_end (struct ui_out *@var{uiout}, const char *@var{id}) | |
1056 | This function first opens the tuple and then establishes a cleanup | |
1057 | (@pxref{Coding, Cleanups}) to close the tuple. It provides a convenient | |
1058 | and correct implementation of the non-portable@footnote{The function | |
b9aa90c9 | 1059 | cast is not portable ISO C.} code sequence: |
c72e7388 AC |
1060 | @smallexample |
1061 | struct cleanup *old_cleanup; | |
1062 | ui_out_tuple_begin (uiout, "..."); | |
1063 | old_cleanup = make_cleanup ((void(*)(void *)) ui_out_tuple_end, | |
1064 | uiout); | |
1065 | @end smallexample | |
1066 | @end deftypefun | |
1067 | ||
1068 | @deftypefun void ui_out_list_begin (struct ui_out *@var{uiout}, const char *@var{id}) | |
1069 | This function marks the beginning of a list output. @var{id} points to | |
1070 | an optional string that identifies the list; it is copied by the | |
1071 | implementation, and so strings in @code{malloc}ed storage can be freed | |
1072 | after the call. | |
0ee54786 EZ |
1073 | @end deftypefun |
1074 | ||
1075 | @deftypefun void ui_out_list_end (struct ui_out *@var{uiout}) | |
c72e7388 AC |
1076 | This function signals an end of a list output. There should be exactly |
1077 | one call to @code{ui_out_list_end} for each call to | |
1078 | @code{ui_out_list_begin}, otherwise an internal @value{GDBN} error will | |
1079 | be signaled. | |
1080 | @end deftypefun | |
1081 | ||
1082 | @deftypefun struct cleanup *make_cleanup_ui_out_list_begin_end (struct ui_out *@var{uiout}, const char *@var{id}) | |
1083 | Similar to @code{make_cleanup_ui_out_tuple_begin_end}, this function | |
1084 | opens a list and then establishes cleanup (@pxref{Coding, Cleanups}) | |
1085 | that will close the list.list. | |
0ee54786 EZ |
1086 | @end deftypefun |
1087 | ||
1088 | @subsection Item Output Functions | |
1089 | ||
1090 | @cindex item output functions | |
1091 | @cindex field output functions | |
1092 | @cindex data output | |
1093 | The functions described below produce output for the actual data | |
1094 | items, or fields, which contain information about the object. | |
1095 | ||
1096 | Choose the appropriate function accordingly to your particular needs. | |
1097 | ||
1098 | @deftypefun void ui_out_field_fmt (struct ui_out *@var{uiout}, char *@var{fldname}, char *@var{format}, ...) | |
1099 | This is the most general output function. It produces the | |
1100 | representation of the data in the variable-length argument list | |
1101 | according to formatting specifications in @var{format}, a | |
1102 | @code{printf}-like format string. The optional argument @var{fldname} | |
1103 | supplies the name of the field. The data items themselves are | |
1104 | supplied as additional arguments after @var{format}. | |
1105 | ||
1106 | This generic function should be used only when it is not possible to | |
1107 | use one of the specialized versions (see below). | |
1108 | @end deftypefun | |
1109 | ||
c72e7388 | 1110 | @deftypefun void ui_out_field_int (struct ui_out *@var{uiout}, const char *@var{fldname}, int @var{value}) |
0ee54786 EZ |
1111 | This function outputs a value of an @code{int} variable. It uses the |
1112 | @code{"%d"} output conversion specification. @var{fldname} specifies | |
1113 | the name of the field. | |
1114 | @end deftypefun | |
8d19fbd2 JJ |
1115 | |
1116 | @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}) | |
1117 | This function outputs a value of an @code{int} variable. It differs from | |
1118 | @code{ui_out_field_int} in that the caller specifies the desired @var{width} and @var{alignment} of the output. | |
1119 | @var{fldname} specifies | |
1120 | the name of the field. | |
1121 | @end deftypefun | |
0ee54786 | 1122 | |
c72e7388 | 1123 | @deftypefun void ui_out_field_core_addr (struct ui_out *@var{uiout}, const char *@var{fldname}, CORE_ADDR @var{address}) |
0ee54786 EZ |
1124 | This function outputs an address. |
1125 | @end deftypefun | |
1126 | ||
c72e7388 | 1127 | @deftypefun void ui_out_field_string (struct ui_out *@var{uiout}, const char *@var{fldname}, const char *@var{string}) |
0ee54786 EZ |
1128 | This function outputs a string using the @code{"%s"} conversion |
1129 | specification. | |
1130 | @end deftypefun | |
1131 | ||
1132 | Sometimes, there's a need to compose your output piece by piece using | |
1133 | functions that operate on a stream, such as @code{value_print} or | |
1134 | @code{fprintf_symbol_filtered}. These functions accept an argument of | |
1135 | the type @code{struct ui_file *}, a pointer to a @code{ui_file} object | |
1136 | used to store the data stream used for the output. When you use one | |
1137 | of these functions, you need a way to pass their results stored in a | |
1138 | @code{ui_file} object to the @code{ui_out} functions. To this end, | |
1139 | you first create a @code{ui_stream} object by calling | |
1140 | @code{ui_out_stream_new}, pass the @code{stream} member of that | |
1141 | @code{ui_stream} object to @code{value_print} and similar functions, | |
1142 | and finally call @code{ui_out_field_stream} to output the field you | |
1143 | constructed. When the @code{ui_stream} object is no longer needed, | |
1144 | you should destroy it and free its memory by calling | |
1145 | @code{ui_out_stream_delete}. | |
1146 | ||
1147 | @deftypefun struct ui_stream *ui_out_stream_new (struct ui_out *@var{uiout}) | |
1148 | This function creates a new @code{ui_stream} object which uses the | |
1149 | same output methods as the @code{ui_out} object whose pointer is | |
1150 | passed in @var{uiout}. It returns a pointer to the newly created | |
1151 | @code{ui_stream} object. | |
1152 | @end deftypefun | |
1153 | ||
1154 | @deftypefun void ui_out_stream_delete (struct ui_stream *@var{streambuf}) | |
1155 | This functions destroys a @code{ui_stream} object specified by | |
1156 | @var{streambuf}. | |
1157 | @end deftypefun | |
1158 | ||
c72e7388 | 1159 | @deftypefun void ui_out_field_stream (struct ui_out *@var{uiout}, const char *@var{fieldname}, struct ui_stream *@var{streambuf}) |
0ee54786 EZ |
1160 | This function consumes all the data accumulated in |
1161 | @code{streambuf->stream} and outputs it like | |
1162 | @code{ui_out_field_string} does. After a call to | |
1163 | @code{ui_out_field_stream}, the accumulated data no longer exists, but | |
1164 | the stream is still valid and may be used for producing more fields. | |
1165 | @end deftypefun | |
1166 | ||
1167 | @strong{Important:} If there is any chance that your code could bail | |
1168 | out before completing output generation and reaching the point where | |
1169 | @code{ui_out_stream_delete} is called, it is necessary to set up a | |
1170 | cleanup, to avoid leaking memory and other resources. Here's a | |
1171 | skeleton code to do that: | |
1172 | ||
1173 | @smallexample | |
1174 | struct ui_stream *mybuf = ui_out_stream_new (uiout); | |
1175 | struct cleanup *old = make_cleanup (ui_out_stream_delete, mybuf); | |
1176 | ... | |
1177 | do_cleanups (old); | |
1178 | @end smallexample | |
1179 | ||
1180 | If the function already has the old cleanup chain set (for other kinds | |
1181 | of cleanups), you just have to add your cleanup to it: | |
1182 | ||
1183 | @smallexample | |
1184 | mybuf = ui_out_stream_new (uiout); | |
1185 | make_cleanup (ui_out_stream_delete, mybuf); | |
1186 | @end smallexample | |
1187 | ||
1188 | Note that with cleanups in place, you should not call | |
1189 | @code{ui_out_stream_delete} directly, or you would attempt to free the | |
1190 | same buffer twice. | |
1191 | ||
1192 | @subsection Utility Output Functions | |
1193 | ||
c72e7388 | 1194 | @deftypefun void ui_out_field_skip (struct ui_out *@var{uiout}, const char *@var{fldname}) |
0ee54786 EZ |
1195 | This function skips a field in a table. Use it if you have to leave |
1196 | an empty field without disrupting the table alignment. The argument | |
1197 | @var{fldname} specifies a name for the (missing) filed. | |
1198 | @end deftypefun | |
1199 | ||
c72e7388 | 1200 | @deftypefun void ui_out_text (struct ui_out *@var{uiout}, const char *@var{string}) |
0ee54786 EZ |
1201 | This function outputs the text in @var{string} in a way that makes it |
1202 | easy to be read by humans. For example, the console implementation of | |
1203 | this method filters the text through a built-in pager, to prevent it | |
1204 | from scrolling off the visible portion of the screen. | |
1205 | ||
1206 | Use this function for printing relatively long chunks of text around | |
1207 | the actual field data: the text it produces is not aligned according | |
1208 | to the table's format. Use @code{ui_out_field_string} to output a | |
1209 | string field, and use @code{ui_out_message}, described below, to | |
1210 | output short messages. | |
1211 | @end deftypefun | |
1212 | ||
1213 | @deftypefun void ui_out_spaces (struct ui_out *@var{uiout}, int @var{nspaces}) | |
1214 | This function outputs @var{nspaces} spaces. It is handy to align the | |
1215 | text produced by @code{ui_out_text} with the rest of the table or | |
1216 | list. | |
1217 | @end deftypefun | |
1218 | ||
c72e7388 | 1219 | @deftypefun void ui_out_message (struct ui_out *@var{uiout}, int @var{verbosity}, const char *@var{format}, ...) |
0ee54786 EZ |
1220 | This function produces a formatted message, provided that the current |
1221 | verbosity level is at least as large as given by @var{verbosity}. The | |
1222 | current verbosity level is specified by the user with the @samp{set | |
1223 | verbositylevel} command.@footnote{As of this writing (April 2001), | |
1224 | setting verbosity level is not yet implemented, and is always returned | |
1225 | as zero. So calling @code{ui_out_message} with a @var{verbosity} | |
1226 | argument more than zero will cause the message to never be printed.} | |
1227 | @end deftypefun | |
1228 | ||
1229 | @deftypefun void ui_out_wrap_hint (struct ui_out *@var{uiout}, char *@var{indent}) | |
1230 | This function gives the console output filter (a paging filter) a hint | |
1231 | of where to break lines which are too long. Ignored for all other | |
1232 | output consumers. @var{indent}, if non-@code{NULL}, is the string to | |
1233 | be printed to indent the wrapped text on the next line; it must remain | |
1234 | accessible until the next call to @code{ui_out_wrap_hint}, or until an | |
1235 | explicit newline is produced by one of the other functions. If | |
1236 | @var{indent} is @code{NULL}, the wrapped text will not be indented. | |
1237 | @end deftypefun | |
1238 | ||
1239 | @deftypefun void ui_out_flush (struct ui_out *@var{uiout}) | |
1240 | This function flushes whatever output has been accumulated so far, if | |
1241 | the UI buffers output. | |
1242 | @end deftypefun | |
1243 | ||
1244 | ||
1245 | @subsection Examples of Use of @code{ui_out} functions | |
1246 | ||
1247 | @cindex using @code{ui_out} functions | |
1248 | @cindex @code{ui_out} functions, usage examples | |
1249 | This section gives some practical examples of using the @code{ui_out} | |
1250 | functions to generalize the old console-oriented code in | |
1251 | @value{GDBN}. The examples all come from functions defined on the | |
1252 | @file{breakpoints.c} file. | |
1253 | ||
1254 | This example, from the @code{breakpoint_1} function, shows how to | |
1255 | produce a table. | |
1256 | ||
1257 | The original code was: | |
1258 | ||
474c8240 | 1259 | @smallexample |
0ee54786 EZ |
1260 | if (!found_a_breakpoint++) |
1261 | @{ | |
1262 | annotate_breakpoints_headers (); | |
1263 | ||
1264 | annotate_field (0); | |
1265 | printf_filtered ("Num "); | |
1266 | annotate_field (1); | |
1267 | printf_filtered ("Type "); | |
1268 | annotate_field (2); | |
1269 | printf_filtered ("Disp "); | |
1270 | annotate_field (3); | |
1271 | printf_filtered ("Enb "); | |
1272 | if (addressprint) | |
1273 | @{ | |
1274 | annotate_field (4); | |
1275 | printf_filtered ("Address "); | |
1276 | @} | |
1277 | annotate_field (5); | |
1278 | printf_filtered ("What\n"); | |
1279 | ||
1280 | annotate_breakpoints_table (); | |
1281 | @} | |
474c8240 | 1282 | @end smallexample |
0ee54786 EZ |
1283 | |
1284 | Here's the new version: | |
1285 | ||
474c8240 | 1286 | @smallexample |
c72e7388 AC |
1287 | nr_printable_breakpoints = @dots{}; |
1288 | ||
1289 | if (addressprint) | |
1290 | ui_out_table_begin (ui, 6, nr_printable_breakpoints, "BreakpointTable"); | |
1291 | else | |
1292 | ui_out_table_begin (ui, 5, nr_printable_breakpoints, "BreakpointTable"); | |
1293 | ||
1294 | if (nr_printable_breakpoints > 0) | |
1295 | annotate_breakpoints_headers (); | |
1296 | if (nr_printable_breakpoints > 0) | |
1297 | annotate_field (0); | |
1298 | ui_out_table_header (uiout, 3, ui_left, "number", "Num"); /* 1 */ | |
1299 | if (nr_printable_breakpoints > 0) | |
1300 | annotate_field (1); | |
1301 | ui_out_table_header (uiout, 14, ui_left, "type", "Type"); /* 2 */ | |
1302 | if (nr_printable_breakpoints > 0) | |
1303 | annotate_field (2); | |
1304 | ui_out_table_header (uiout, 4, ui_left, "disp", "Disp"); /* 3 */ | |
1305 | if (nr_printable_breakpoints > 0) | |
1306 | annotate_field (3); | |
1307 | ui_out_table_header (uiout, 3, ui_left, "enabled", "Enb"); /* 4 */ | |
1308 | if (addressprint) | |
1309 | @{ | |
1310 | if (nr_printable_breakpoints > 0) | |
1311 | annotate_field (4); | |
1312 | if (TARGET_ADDR_BIT <= 32) | |
1313 | ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */ | |
0ee54786 | 1314 | else |
c72e7388 AC |
1315 | ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */ |
1316 | @} | |
1317 | if (nr_printable_breakpoints > 0) | |
1318 | annotate_field (5); | |
1319 | ui_out_table_header (uiout, 40, ui_noalign, "what", "What"); /* 6 */ | |
1320 | ui_out_table_body (uiout); | |
1321 | if (nr_printable_breakpoints > 0) | |
1322 | annotate_breakpoints_table (); | |
474c8240 | 1323 | @end smallexample |
0ee54786 EZ |
1324 | |
1325 | This example, from the @code{print_one_breakpoint} function, shows how | |
1326 | to produce the actual data for the table whose structure was defined | |
1327 | in the above example. The original code was: | |
1328 | ||
474c8240 | 1329 | @smallexample |
0ee54786 EZ |
1330 | annotate_record (); |
1331 | annotate_field (0); | |
1332 | printf_filtered ("%-3d ", b->number); | |
1333 | annotate_field (1); | |
1334 | if ((int)b->type > (sizeof(bptypes)/sizeof(bptypes[0])) | |
1335 | || ((int) b->type != bptypes[(int) b->type].type)) | |
1336 | internal_error ("bptypes table does not describe type #%d.", | |
1337 | (int)b->type); | |
1338 | printf_filtered ("%-14s ", bptypes[(int)b->type].description); | |
1339 | annotate_field (2); | |
1340 | printf_filtered ("%-4s ", bpdisps[(int)b->disposition]); | |
1341 | annotate_field (3); | |
1342 | printf_filtered ("%-3c ", bpenables[(int)b->enable]); | |
c72e7388 | 1343 | @dots{} |
474c8240 | 1344 | @end smallexample |
0ee54786 EZ |
1345 | |
1346 | This is the new version: | |
1347 | ||
474c8240 | 1348 | @smallexample |
0ee54786 | 1349 | annotate_record (); |
c72e7388 | 1350 | ui_out_tuple_begin (uiout, "bkpt"); |
0ee54786 EZ |
1351 | annotate_field (0); |
1352 | ui_out_field_int (uiout, "number", b->number); | |
1353 | annotate_field (1); | |
1354 | if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0]))) | |
1355 | || ((int) b->type != bptypes[(int) b->type].type)) | |
1356 | internal_error ("bptypes table does not describe type #%d.", | |
1357 | (int) b->type); | |
1358 | ui_out_field_string (uiout, "type", bptypes[(int)b->type].description); | |
1359 | annotate_field (2); | |
1360 | ui_out_field_string (uiout, "disp", bpdisps[(int)b->disposition]); | |
1361 | annotate_field (3); | |
1362 | ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)b->enable]); | |
c72e7388 | 1363 | @dots{} |
474c8240 | 1364 | @end smallexample |
0ee54786 EZ |
1365 | |
1366 | This example, also from @code{print_one_breakpoint}, shows how to | |
1367 | produce a complicated output field using the @code{print_expression} | |
1368 | functions which requires a stream to be passed. It also shows how to | |
1369 | automate stream destruction with cleanups. The original code was: | |
1370 | ||
474c8240 | 1371 | @smallexample |
0ee54786 EZ |
1372 | annotate_field (5); |
1373 | print_expression (b->exp, gdb_stdout); | |
474c8240 | 1374 | @end smallexample |
0ee54786 EZ |
1375 | |
1376 | The new version is: | |
1377 | ||
474c8240 | 1378 | @smallexample |
0ee54786 EZ |
1379 | struct ui_stream *stb = ui_out_stream_new (uiout); |
1380 | struct cleanup *old_chain = make_cleanup_ui_out_stream_delete (stb); | |
1381 | ... | |
1382 | annotate_field (5); | |
1383 | print_expression (b->exp, stb->stream); | |
1384 | ui_out_field_stream (uiout, "what", local_stream); | |
474c8240 | 1385 | @end smallexample |
0ee54786 EZ |
1386 | |
1387 | This example, also from @code{print_one_breakpoint}, shows how to use | |
1388 | @code{ui_out_text} and @code{ui_out_field_string}. The original code | |
1389 | was: | |
1390 | ||
474c8240 | 1391 | @smallexample |
0ee54786 EZ |
1392 | annotate_field (5); |
1393 | if (b->dll_pathname == NULL) | |
1394 | printf_filtered ("<any library> "); | |
1395 | else | |
1396 | printf_filtered ("library \"%s\" ", b->dll_pathname); | |
474c8240 | 1397 | @end smallexample |
0ee54786 EZ |
1398 | |
1399 | It became: | |
1400 | ||
474c8240 | 1401 | @smallexample |
0ee54786 EZ |
1402 | annotate_field (5); |
1403 | if (b->dll_pathname == NULL) | |
1404 | @{ | |
1405 | ui_out_field_string (uiout, "what", "<any library>"); | |
1406 | ui_out_spaces (uiout, 1); | |
1407 | @} | |
1408 | else | |
1409 | @{ | |
1410 | ui_out_text (uiout, "library \""); | |
1411 | ui_out_field_string (uiout, "what", b->dll_pathname); | |
1412 | ui_out_text (uiout, "\" "); | |
1413 | @} | |
474c8240 | 1414 | @end smallexample |
0ee54786 EZ |
1415 | |
1416 | The following example from @code{print_one_breakpoint} shows how to | |
1417 | use @code{ui_out_field_int} and @code{ui_out_spaces}. The original | |
1418 | code was: | |
1419 | ||
474c8240 | 1420 | @smallexample |
0ee54786 EZ |
1421 | annotate_field (5); |
1422 | if (b->forked_inferior_pid != 0) | |
1423 | printf_filtered ("process %d ", b->forked_inferior_pid); | |
474c8240 | 1424 | @end smallexample |
0ee54786 EZ |
1425 | |
1426 | It became: | |
1427 | ||
474c8240 | 1428 | @smallexample |
0ee54786 EZ |
1429 | annotate_field (5); |
1430 | if (b->forked_inferior_pid != 0) | |
1431 | @{ | |
1432 | ui_out_text (uiout, "process "); | |
1433 | ui_out_field_int (uiout, "what", b->forked_inferior_pid); | |
1434 | ui_out_spaces (uiout, 1); | |
1435 | @} | |
474c8240 | 1436 | @end smallexample |
0ee54786 EZ |
1437 | |
1438 | Here's an example of using @code{ui_out_field_string}. The original | |
1439 | code was: | |
1440 | ||
474c8240 | 1441 | @smallexample |
0ee54786 EZ |
1442 | annotate_field (5); |
1443 | if (b->exec_pathname != NULL) | |
1444 | printf_filtered ("program \"%s\" ", b->exec_pathname); | |
474c8240 | 1445 | @end smallexample |
0ee54786 EZ |
1446 | |
1447 | It became: | |
1448 | ||
474c8240 | 1449 | @smallexample |
0ee54786 EZ |
1450 | annotate_field (5); |
1451 | if (b->exec_pathname != NULL) | |
1452 | @{ | |
1453 | ui_out_text (uiout, "program \""); | |
1454 | ui_out_field_string (uiout, "what", b->exec_pathname); | |
1455 | ui_out_text (uiout, "\" "); | |
1456 | @} | |
474c8240 | 1457 | @end smallexample |
0ee54786 EZ |
1458 | |
1459 | Finally, here's an example of printing an address. The original code: | |
1460 | ||
474c8240 | 1461 | @smallexample |
0ee54786 EZ |
1462 | annotate_field (4); |
1463 | printf_filtered ("%s ", | |
15a661f3 | 1464 | hex_string_custom ((unsigned long) b->address, 8)); |
474c8240 | 1465 | @end smallexample |
0ee54786 EZ |
1466 | |
1467 | It became: | |
1468 | ||
474c8240 | 1469 | @smallexample |
0ee54786 EZ |
1470 | annotate_field (4); |
1471 | ui_out_field_core_addr (uiout, "Address", b->address); | |
474c8240 | 1472 | @end smallexample |
0ee54786 EZ |
1473 | |
1474 | ||
c906108c SS |
1475 | @section Console Printing |
1476 | ||
1477 | @section TUI | |
1478 | ||
89437448 | 1479 | @node libgdb |
c906108c | 1480 | |
89437448 AC |
1481 | @chapter libgdb |
1482 | ||
1483 | @section libgdb 1.0 | |
1484 | @cindex @code{libgdb} | |
1485 | @code{libgdb} 1.0 was an abortive project of years ago. The theory was | |
1486 | to provide an API to @value{GDBN}'s functionality. | |
1487 | ||
1488 | @section libgdb 2.0 | |
56caf160 | 1489 | @cindex @code{libgdb} |
89437448 AC |
1490 | @code{libgdb} 2.0 is an ongoing effort to update @value{GDBN} so that is |
1491 | better able to support graphical and other environments. | |
1492 | ||
1493 | Since @code{libgdb} development is on-going, its architecture is still | |
1494 | evolving. The following components have so far been identified: | |
1495 | ||
1496 | @itemize @bullet | |
1497 | @item | |
1498 | Observer - @file{gdb-events.h}. | |
1499 | @item | |
1500 | Builder - @file{ui-out.h} | |
1501 | @item | |
1502 | Event Loop - @file{event-loop.h} | |
1503 | @item | |
1504 | Library - @file{gdb.h} | |
1505 | @end itemize | |
1506 | ||
1507 | The model that ties these components together is described below. | |
1508 | ||
1509 | @section The @code{libgdb} Model | |
1510 | ||
1511 | A client of @code{libgdb} interacts with the library in two ways. | |
1512 | ||
1513 | @itemize @bullet | |
1514 | @item | |
1515 | As an observer (using @file{gdb-events}) receiving notifications from | |
1516 | @code{libgdb} of any internal state changes (break point changes, run | |
1517 | state, etc). | |
1518 | @item | |
1519 | As a client querying @code{libgdb} (using the @file{ui-out} builder) to | |
1520 | obtain various status values from @value{GDBN}. | |
1521 | @end itemize | |
1522 | ||
c1468174 | 1523 | Since @code{libgdb} could have multiple clients (e.g., a GUI supporting |
89437448 AC |
1524 | the existing @value{GDBN} CLI), those clients must co-operate when |
1525 | controlling @code{libgdb}. In particular, a client must ensure that | |
1526 | @code{libgdb} is idle (i.e. no other client is using @code{libgdb}) | |
1527 | before responding to a @file{gdb-event} by making a query. | |
1528 | ||
1529 | @section CLI support | |
1530 | ||
1531 | At present @value{GDBN}'s CLI is very much entangled in with the core of | |
1532 | @code{libgdb}. Consequently, a client wishing to include the CLI in | |
1533 | their interface needs to carefully co-ordinate its own and the CLI's | |
1534 | requirements. | |
1535 | ||
1536 | It is suggested that the client set @code{libgdb} up to be bi-modal | |
1537 | (alternate between CLI and client query modes). The notes below sketch | |
1538 | out the theory: | |
1539 | ||
1540 | @itemize @bullet | |
1541 | @item | |
1542 | The client registers itself as an observer of @code{libgdb}. | |
1543 | @item | |
1544 | The client create and install @code{cli-out} builder using its own | |
1545 | versions of the @code{ui-file} @code{gdb_stderr}, @code{gdb_stdtarg} and | |
1546 | @code{gdb_stdout} streams. | |
1547 | @item | |
1548 | The client creates a separate custom @code{ui-out} builder that is only | |
1549 | used while making direct queries to @code{libgdb}. | |
1550 | @end itemize | |
1551 | ||
1552 | When the client receives input intended for the CLI, it simply passes it | |
1553 | along. Since the @code{cli-out} builder is installed by default, all | |
1554 | the CLI output in response to that command is routed (pronounced rooted) | |
1555 | through to the client controlled @code{gdb_stdout} et.@: al.@: streams. | |
1556 | At the same time, the client is kept abreast of internal changes by | |
1557 | virtue of being a @code{libgdb} observer. | |
1558 | ||
1559 | The only restriction on the client is that it must wait until | |
1560 | @code{libgdb} becomes idle before initiating any queries (using the | |
1561 | client's custom builder). | |
1562 | ||
1563 | @section @code{libgdb} components | |
1564 | ||
1565 | @subheading Observer - @file{gdb-events.h} | |
1566 | @file{gdb-events} provides the client with a very raw mechanism that can | |
1567 | be used to implement an observer. At present it only allows for one | |
1568 | observer and that observer must, internally, handle the need to delay | |
1569 | the processing of any event notifications until after @code{libgdb} has | |
1570 | finished the current command. | |
1571 | ||
1572 | @subheading Builder - @file{ui-out.h} | |
1573 | @file{ui-out} provides the infrastructure necessary for a client to | |
1574 | create a builder. That builder is then passed down to @code{libgdb} | |
1575 | when doing any queries. | |
1576 | ||
1577 | @subheading Event Loop - @file{event-loop.h} | |
1578 | @c There could be an entire section on the event-loop | |
1579 | @file{event-loop}, currently non-re-entrant, provides a simple event | |
1580 | loop. A client would need to either plug its self into this loop or, | |
1581 | implement a new event-loop that GDB would use. | |
1582 | ||
1583 | The event-loop will eventually be made re-entrant. This is so that | |
a9f12a31 | 1584 | @value{GDBN} can better handle the problem of some commands blocking |
89437448 AC |
1585 | instead of returning. |
1586 | ||
1587 | @subheading Library - @file{gdb.h} | |
1588 | @file{libgdb} is the most obvious component of this system. It provides | |
1589 | the query interface. Each function is parameterized by a @code{ui-out} | |
1590 | builder. The result of the query is constructed using that builder | |
1591 | before the query function returns. | |
c906108c SS |
1592 | |
1593 | @node Symbol Handling | |
1594 | ||
1595 | @chapter Symbol Handling | |
1596 | ||
25822942 | 1597 | Symbols are a key part of @value{GDBN}'s operation. Symbols include variables, |
c906108c SS |
1598 | functions, and types. |
1599 | ||
1600 | @section Symbol Reading | |
1601 | ||
56caf160 EZ |
1602 | @cindex symbol reading |
1603 | @cindex reading of symbols | |
1604 | @cindex symbol files | |
1605 | @value{GDBN} reads symbols from @dfn{symbol files}. The usual symbol | |
1606 | file is the file containing the program which @value{GDBN} is | |
1607 | debugging. @value{GDBN} can be directed to use a different file for | |
1608 | symbols (with the @samp{symbol-file} command), and it can also read | |
1609 | more symbols via the @samp{add-file} and @samp{load} commands, or while | |
1610 | reading symbols from shared libraries. | |
1611 | ||
1612 | @findex find_sym_fns | |
1613 | Symbol files are initially opened by code in @file{symfile.c} using | |
1614 | the BFD library (@pxref{Support Libraries}). BFD identifies the type | |
1615 | of the file by examining its header. @code{find_sym_fns} then uses | |
1616 | this identification to locate a set of symbol-reading functions. | |
1617 | ||
1618 | @findex add_symtab_fns | |
1619 | @cindex @code{sym_fns} structure | |
1620 | @cindex adding a symbol-reading module | |
1621 | Symbol-reading modules identify themselves to @value{GDBN} by calling | |
c906108c SS |
1622 | @code{add_symtab_fns} during their module initialization. The argument |
1623 | to @code{add_symtab_fns} is a @code{struct sym_fns} which contains the | |
1624 | name (or name prefix) of the symbol format, the length of the prefix, | |
1625 | and pointers to four functions. These functions are called at various | |
56caf160 | 1626 | times to process symbol files whose identification matches the specified |
c906108c SS |
1627 | prefix. |
1628 | ||
1629 | The functions supplied by each module are: | |
1630 | ||
1631 | @table @code | |
1632 | @item @var{xyz}_symfile_init(struct sym_fns *sf) | |
1633 | ||
56caf160 | 1634 | @cindex secondary symbol file |
c906108c SS |
1635 | Called from @code{symbol_file_add} when we are about to read a new |
1636 | symbol file. This function should clean up any internal state (possibly | |
1637 | resulting from half-read previous files, for example) and prepare to | |
56caf160 EZ |
1638 | read a new symbol file. Note that the symbol file which we are reading |
1639 | might be a new ``main'' symbol file, or might be a secondary symbol file | |
c906108c SS |
1640 | whose symbols are being added to the existing symbol table. |
1641 | ||
1642 | The argument to @code{@var{xyz}_symfile_init} is a newly allocated | |
1643 | @code{struct sym_fns} whose @code{bfd} field contains the BFD for the | |
1644 | new symbol file being read. Its @code{private} field has been zeroed, | |
1645 | and can be modified as desired. Typically, a struct of private | |
1646 | information will be @code{malloc}'d, and a pointer to it will be placed | |
1647 | in the @code{private} field. | |
1648 | ||
1649 | There is no result from @code{@var{xyz}_symfile_init}, but it can call | |
1650 | @code{error} if it detects an unavoidable problem. | |
1651 | ||
1652 | @item @var{xyz}_new_init() | |
1653 | ||
1654 | Called from @code{symbol_file_add} when discarding existing symbols. | |
56caf160 EZ |
1655 | This function needs only handle the symbol-reading module's internal |
1656 | state; the symbol table data structures visible to the rest of | |
1657 | @value{GDBN} will be discarded by @code{symbol_file_add}. It has no | |
1658 | arguments and no result. It may be called after | |
1659 | @code{@var{xyz}_symfile_init}, if a new symbol table is being read, or | |
1660 | may be called alone if all symbols are simply being discarded. | |
c906108c SS |
1661 | |
1662 | @item @var{xyz}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline) | |
1663 | ||
1664 | Called from @code{symbol_file_add} to actually read the symbols from a | |
1665 | symbol-file into a set of psymtabs or symtabs. | |
1666 | ||
56caf160 | 1667 | @code{sf} points to the @code{struct sym_fns} originally passed to |
c906108c SS |
1668 | @code{@var{xyz}_sym_init} for possible initialization. @code{addr} is |
1669 | the offset between the file's specified start address and its true | |
1670 | address in memory. @code{mainline} is 1 if this is the main symbol | |
c1468174 | 1671 | table being read, and 0 if a secondary symbol file (e.g., shared library |
c906108c SS |
1672 | or dynamically loaded file) is being read.@refill |
1673 | @end table | |
1674 | ||
1675 | In addition, if a symbol-reading module creates psymtabs when | |
1676 | @var{xyz}_symfile_read is called, these psymtabs will contain a pointer | |
1677 | to a function @code{@var{xyz}_psymtab_to_symtab}, which can be called | |
25822942 | 1678 | from any point in the @value{GDBN} symbol-handling code. |
c906108c SS |
1679 | |
1680 | @table @code | |
1681 | @item @var{xyz}_psymtab_to_symtab (struct partial_symtab *pst) | |
1682 | ||
56caf160 | 1683 | Called from @code{psymtab_to_symtab} (or the @code{PSYMTAB_TO_SYMTAB} macro) if |
c906108c SS |
1684 | the psymtab has not already been read in and had its @code{pst->symtab} |
1685 | pointer set. The argument is the psymtab to be fleshed-out into a | |
56caf160 EZ |
1686 | symtab. Upon return, @code{pst->readin} should have been set to 1, and |
1687 | @code{pst->symtab} should contain a pointer to the new corresponding symtab, or | |
c906108c SS |
1688 | zero if there were no symbols in that part of the symbol file. |
1689 | @end table | |
1690 | ||
1691 | @section Partial Symbol Tables | |
1692 | ||
56caf160 | 1693 | @value{GDBN} has three types of symbol tables: |
c906108c SS |
1694 | |
1695 | @itemize @bullet | |
56caf160 EZ |
1696 | @cindex full symbol table |
1697 | @cindex symtabs | |
1698 | @item | |
1699 | Full symbol tables (@dfn{symtabs}). These contain the main | |
1700 | information about symbols and addresses. | |
c906108c | 1701 | |
56caf160 EZ |
1702 | @cindex psymtabs |
1703 | @item | |
1704 | Partial symbol tables (@dfn{psymtabs}). These contain enough | |
c906108c SS |
1705 | information to know when to read the corresponding part of the full |
1706 | symbol table. | |
1707 | ||
56caf160 EZ |
1708 | @cindex minimal symbol table |
1709 | @cindex minsymtabs | |
1710 | @item | |
1711 | Minimal symbol tables (@dfn{msymtabs}). These contain information | |
c906108c | 1712 | gleaned from non-debugging symbols. |
c906108c SS |
1713 | @end itemize |
1714 | ||
56caf160 | 1715 | @cindex partial symbol table |
c906108c SS |
1716 | This section describes partial symbol tables. |
1717 | ||
1718 | A psymtab is constructed by doing a very quick pass over an executable | |
1719 | file's debugging information. Small amounts of information are | |
56caf160 | 1720 | extracted---enough to identify which parts of the symbol table will |
c906108c | 1721 | need to be re-read and fully digested later, when the user needs the |
25822942 | 1722 | information. The speed of this pass causes @value{GDBN} to start up very |
c906108c SS |
1723 | quickly. Later, as the detailed rereading occurs, it occurs in small |
1724 | pieces, at various times, and the delay therefrom is mostly invisible to | |
1725 | the user. | |
1726 | @c (@xref{Symbol Reading}.) | |
1727 | ||
1728 | The symbols that show up in a file's psymtab should be, roughly, those | |
1729 | visible to the debugger's user when the program is not running code from | |
1730 | that file. These include external symbols and types, static symbols and | |
56caf160 | 1731 | types, and @code{enum} values declared at file scope. |
c906108c SS |
1732 | |
1733 | The psymtab also contains the range of instruction addresses that the | |
1734 | full symbol table would represent. | |
1735 | ||
56caf160 EZ |
1736 | @cindex finding a symbol |
1737 | @cindex symbol lookup | |
c906108c SS |
1738 | The idea is that there are only two ways for the user (or much of the |
1739 | code in the debugger) to reference a symbol: | |
1740 | ||
1741 | @itemize @bullet | |
56caf160 EZ |
1742 | @findex find_pc_function |
1743 | @findex find_pc_line | |
1744 | @item | |
c1468174 | 1745 | By its address (e.g., execution stops at some address which is inside a |
56caf160 EZ |
1746 | function in this file). The address will be noticed to be in the |
1747 | range of this psymtab, and the full symtab will be read in. | |
1748 | @code{find_pc_function}, @code{find_pc_line}, and other | |
1749 | @code{find_pc_@dots{}} functions handle this. | |
c906108c | 1750 | |
56caf160 EZ |
1751 | @cindex lookup_symbol |
1752 | @item | |
1753 | By its name | |
c1468174 | 1754 | (e.g., the user asks to print a variable, or set a breakpoint on a |
c906108c SS |
1755 | function). Global names and file-scope names will be found in the |
1756 | psymtab, which will cause the symtab to be pulled in. Local names will | |
1757 | have to be qualified by a global name, or a file-scope name, in which | |
1758 | case we will have already read in the symtab as we evaluated the | |
56caf160 | 1759 | qualifier. Or, a local symbol can be referenced when we are ``in'' a |
c906108c SS |
1760 | local scope, in which case the first case applies. @code{lookup_symbol} |
1761 | does most of the work here. | |
c906108c SS |
1762 | @end itemize |
1763 | ||
1764 | The only reason that psymtabs exist is to cause a symtab to be read in | |
1765 | at the right moment. Any symbol that can be elided from a psymtab, | |
1766 | while still causing that to happen, should not appear in it. Since | |
1767 | psymtabs don't have the idea of scope, you can't put local symbols in | |
1768 | them anyway. Psymtabs don't have the idea of the type of a symbol, | |
1769 | either, so types need not appear, unless they will be referenced by | |
1770 | name. | |
1771 | ||
56caf160 EZ |
1772 | It is a bug for @value{GDBN} to behave one way when only a psymtab has |
1773 | been read, and another way if the corresponding symtab has been read | |
1774 | in. Such bugs are typically caused by a psymtab that does not contain | |
1775 | all the visible symbols, or which has the wrong instruction address | |
1776 | ranges. | |
c906108c | 1777 | |
56caf160 | 1778 | The psymtab for a particular section of a symbol file (objfile) could be |
c906108c SS |
1779 | thrown away after the symtab has been read in. The symtab should always |
1780 | be searched before the psymtab, so the psymtab will never be used (in a | |
1781 | bug-free environment). Currently, psymtabs are allocated on an obstack, | |
1782 | and all the psymbols themselves are allocated in a pair of large arrays | |
1783 | on an obstack, so there is little to be gained by trying to free them | |
1784 | unless you want to do a lot more work. | |
1785 | ||
1786 | @section Types | |
1787 | ||
56caf160 | 1788 | @unnumberedsubsec Fundamental Types (e.g., @code{FT_VOID}, @code{FT_BOOLEAN}). |
c906108c | 1789 | |
56caf160 | 1790 | @cindex fundamental types |
25822942 | 1791 | These are the fundamental types that @value{GDBN} uses internally. Fundamental |
c906108c SS |
1792 | types from the various debugging formats (stabs, ELF, etc) are mapped |
1793 | into one of these. They are basically a union of all fundamental types | |
56caf160 EZ |
1794 | that @value{GDBN} knows about for all the languages that @value{GDBN} |
1795 | knows about. | |
c906108c | 1796 | |
56caf160 | 1797 | @unnumberedsubsec Type Codes (e.g., @code{TYPE_CODE_PTR}, @code{TYPE_CODE_ARRAY}). |
c906108c | 1798 | |
56caf160 EZ |
1799 | @cindex type codes |
1800 | Each time @value{GDBN} builds an internal type, it marks it with one | |
1801 | of these types. The type may be a fundamental type, such as | |
1802 | @code{TYPE_CODE_INT}, or a derived type, such as @code{TYPE_CODE_PTR} | |
1803 | which is a pointer to another type. Typically, several @code{FT_*} | |
1804 | types map to one @code{TYPE_CODE_*} type, and are distinguished by | |
1805 | other members of the type struct, such as whether the type is signed | |
1806 | or unsigned, and how many bits it uses. | |
c906108c | 1807 | |
56caf160 | 1808 | @unnumberedsubsec Builtin Types (e.g., @code{builtin_type_void}, @code{builtin_type_char}). |
c906108c SS |
1809 | |
1810 | These are instances of type structs that roughly correspond to | |
56caf160 EZ |
1811 | fundamental types and are created as global types for @value{GDBN} to |
1812 | use for various ugly historical reasons. We eventually want to | |
1813 | eliminate these. Note for example that @code{builtin_type_int} | |
1814 | initialized in @file{gdbtypes.c} is basically the same as a | |
1815 | @code{TYPE_CODE_INT} type that is initialized in @file{c-lang.c} for | |
1816 | an @code{FT_INTEGER} fundamental type. The difference is that the | |
1817 | @code{builtin_type} is not associated with any particular objfile, and | |
1818 | only one instance exists, while @file{c-lang.c} builds as many | |
1819 | @code{TYPE_CODE_INT} types as needed, with each one associated with | |
1820 | some particular objfile. | |
c906108c SS |
1821 | |
1822 | @section Object File Formats | |
56caf160 | 1823 | @cindex object file formats |
c906108c SS |
1824 | |
1825 | @subsection a.out | |
1826 | ||
56caf160 EZ |
1827 | @cindex @code{a.out} format |
1828 | The @code{a.out} format is the original file format for Unix. It | |
1829 | consists of three sections: @code{text}, @code{data}, and @code{bss}, | |
1830 | which are for program code, initialized data, and uninitialized data, | |
1831 | respectively. | |
c906108c | 1832 | |
56caf160 | 1833 | The @code{a.out} format is so simple that it doesn't have any reserved |
c906108c | 1834 | place for debugging information. (Hey, the original Unix hackers used |
56caf160 EZ |
1835 | @samp{adb}, which is a machine-language debugger!) The only debugging |
1836 | format for @code{a.out} is stabs, which is encoded as a set of normal | |
c906108c SS |
1837 | symbols with distinctive attributes. |
1838 | ||
56caf160 | 1839 | The basic @code{a.out} reader is in @file{dbxread.c}. |
c906108c SS |
1840 | |
1841 | @subsection COFF | |
1842 | ||
56caf160 | 1843 | @cindex COFF format |
c906108c SS |
1844 | The COFF format was introduced with System V Release 3 (SVR3) Unix. |
1845 | COFF files may have multiple sections, each prefixed by a header. The | |
1846 | number of sections is limited. | |
1847 | ||
1848 | The COFF specification includes support for debugging. Although this | |
1849 | was a step forward, the debugging information was woefully limited. For | |
1850 | instance, it was not possible to represent code that came from an | |
1851 | included file. | |
1852 | ||
1853 | The COFF reader is in @file{coffread.c}. | |
1854 | ||
1855 | @subsection ECOFF | |
1856 | ||
56caf160 | 1857 | @cindex ECOFF format |
c906108c SS |
1858 | ECOFF is an extended COFF originally introduced for Mips and Alpha |
1859 | workstations. | |
1860 | ||
1861 | The basic ECOFF reader is in @file{mipsread.c}. | |
1862 | ||
1863 | @subsection XCOFF | |
1864 | ||
56caf160 | 1865 | @cindex XCOFF format |
c906108c SS |
1866 | The IBM RS/6000 running AIX uses an object file format called XCOFF. |
1867 | The COFF sections, symbols, and line numbers are used, but debugging | |
56caf160 EZ |
1868 | symbols are @code{dbx}-style stabs whose strings are located in the |
1869 | @code{.debug} section (rather than the string table). For more | |
1870 | information, see @ref{Top,,,stabs,The Stabs Debugging Format}. | |
c906108c SS |
1871 | |
1872 | The shared library scheme has a clean interface for figuring out what | |
1873 | shared libraries are in use, but the catch is that everything which | |
1874 | refers to addresses (symbol tables and breakpoints at least) needs to be | |
1875 | relocated for both shared libraries and the main executable. At least | |
1876 | using the standard mechanism this can only be done once the program has | |
1877 | been run (or the core file has been read). | |
1878 | ||
1879 | @subsection PE | |
1880 | ||
56caf160 EZ |
1881 | @cindex PE-COFF format |
1882 | Windows 95 and NT use the PE (@dfn{Portable Executable}) format for their | |
c906108c SS |
1883 | executables. PE is basically COFF with additional headers. |
1884 | ||
25822942 | 1885 | While BFD includes special PE support, @value{GDBN} needs only the basic |
c906108c SS |
1886 | COFF reader. |
1887 | ||
1888 | @subsection ELF | |
1889 | ||
56caf160 | 1890 | @cindex ELF format |
c906108c SS |
1891 | The ELF format came with System V Release 4 (SVR4) Unix. ELF is similar |
1892 | to COFF in being organized into a number of sections, but it removes | |
1893 | many of COFF's limitations. | |
1894 | ||
1895 | The basic ELF reader is in @file{elfread.c}. | |
1896 | ||
1897 | @subsection SOM | |
1898 | ||
56caf160 | 1899 | @cindex SOM format |
c906108c SS |
1900 | SOM is HP's object file and debug format (not to be confused with IBM's |
1901 | SOM, which is a cross-language ABI). | |
1902 | ||
1903 | The SOM reader is in @file{hpread.c}. | |
1904 | ||
1905 | @subsection Other File Formats | |
1906 | ||
56caf160 | 1907 | @cindex Netware Loadable Module format |
25822942 | 1908 | Other file formats that have been supported by @value{GDBN} include Netware |
4a98ee0e | 1909 | Loadable Modules (@file{nlmread.c}). |
c906108c SS |
1910 | |
1911 | @section Debugging File Formats | |
1912 | ||
1913 | This section describes characteristics of debugging information that | |
1914 | are independent of the object file format. | |
1915 | ||
1916 | @subsection stabs | |
1917 | ||
56caf160 | 1918 | @cindex stabs debugging info |
c906108c SS |
1919 | @code{stabs} started out as special symbols within the @code{a.out} |
1920 | format. Since then, it has been encapsulated into other file | |
1921 | formats, such as COFF and ELF. | |
1922 | ||
1923 | While @file{dbxread.c} does some of the basic stab processing, | |
1924 | including for encapsulated versions, @file{stabsread.c} does | |
1925 | the real work. | |
1926 | ||
1927 | @subsection COFF | |
1928 | ||
56caf160 | 1929 | @cindex COFF debugging info |
c906108c SS |
1930 | The basic COFF definition includes debugging information. The level |
1931 | of support is minimal and non-extensible, and is not often used. | |
1932 | ||
1933 | @subsection Mips debug (Third Eye) | |
1934 | ||
56caf160 | 1935 | @cindex ECOFF debugging info |
c906108c SS |
1936 | ECOFF includes a definition of a special debug format. |
1937 | ||
1938 | The file @file{mdebugread.c} implements reading for this format. | |
1939 | ||
1940 | @subsection DWARF 1 | |
1941 | ||
56caf160 | 1942 | @cindex DWARF 1 debugging info |
c906108c SS |
1943 | DWARF 1 is a debugging format that was originally designed to be |
1944 | used with ELF in SVR4 systems. | |
1945 | ||
c906108c SS |
1946 | @c GCC_PRODUCER |
1947 | @c GPLUS_PRODUCER | |
1948 | @c LCC_PRODUCER | |
1949 | @c If defined, these are the producer strings in a DWARF 1 file. All of | |
1950 | @c these have reasonable defaults already. | |
1951 | ||
1952 | The DWARF 1 reader is in @file{dwarfread.c}. | |
1953 | ||
1954 | @subsection DWARF 2 | |
1955 | ||
56caf160 | 1956 | @cindex DWARF 2 debugging info |
c906108c SS |
1957 | DWARF 2 is an improved but incompatible version of DWARF 1. |
1958 | ||
1959 | The DWARF 2 reader is in @file{dwarf2read.c}. | |
1960 | ||
1961 | @subsection SOM | |
1962 | ||
56caf160 | 1963 | @cindex SOM debugging info |
c906108c SS |
1964 | Like COFF, the SOM definition includes debugging information. |
1965 | ||
25822942 | 1966 | @section Adding a New Symbol Reader to @value{GDBN} |
c906108c | 1967 | |
56caf160 EZ |
1968 | @cindex adding debugging info reader |
1969 | If you are using an existing object file format (@code{a.out}, COFF, ELF, etc), | |
c906108c SS |
1970 | there is probably little to be done. |
1971 | ||
1972 | If you need to add a new object file format, you must first add it to | |
1973 | BFD. This is beyond the scope of this document. | |
1974 | ||
1975 | You must then arrange for the BFD code to provide access to the | |
25822942 | 1976 | debugging symbols. Generally @value{GDBN} will have to call swapping routines |
c906108c | 1977 | from BFD and a few other BFD internal routines to locate the debugging |
25822942 | 1978 | information. As much as possible, @value{GDBN} should not depend on the BFD |
c906108c SS |
1979 | internal data structures. |
1980 | ||
1981 | For some targets (e.g., COFF), there is a special transfer vector used | |
1982 | to call swapping routines, since the external data structures on various | |
1983 | platforms have different sizes and layouts. Specialized routines that | |
1984 | will only ever be implemented by one object file format may be called | |
1985 | directly. This interface should be described in a file | |
56caf160 | 1986 | @file{bfd/lib@var{xyz}.h}, which is included by @value{GDBN}. |
c906108c | 1987 | |
c91d38aa DJ |
1988 | @section Memory Management for Symbol Files |
1989 | ||
1990 | Most memory associated with a loaded symbol file is stored on | |
1991 | its @code{objfile_obstack}. This includes symbols, types, | |
1992 | namespace data, and other information produced by the symbol readers. | |
1993 | ||
1994 | Because this data lives on the objfile's obstack, it is automatically | |
1995 | released when the objfile is unloaded or reloaded. Therefore one | |
1996 | objfile must not reference symbol or type data from another objfile; | |
1997 | they could be unloaded at different times. | |
1998 | ||
1999 | User convenience variables, et cetera, have associated types. Normally | |
2000 | these types live in the associated objfile. However, when the objfile | |
2001 | is unloaded, those types are deep copied to global memory, so that | |
2002 | the values of the user variables and history items are not lost. | |
2003 | ||
c906108c SS |
2004 | |
2005 | @node Language Support | |
2006 | ||
2007 | @chapter Language Support | |
2008 | ||
56caf160 EZ |
2009 | @cindex language support |
2010 | @value{GDBN}'s language support is mainly driven by the symbol reader, | |
2011 | although it is possible for the user to set the source language | |
2012 | manually. | |
c906108c | 2013 | |
56caf160 EZ |
2014 | @value{GDBN} chooses the source language by looking at the extension |
2015 | of the file recorded in the debug info; @file{.c} means C, @file{.f} | |
2016 | means Fortran, etc. It may also use a special-purpose language | |
2017 | identifier if the debug format supports it, like with DWARF. | |
c906108c | 2018 | |
25822942 | 2019 | @section Adding a Source Language to @value{GDBN} |
c906108c | 2020 | |
56caf160 EZ |
2021 | @cindex adding source language |
2022 | To add other languages to @value{GDBN}'s expression parser, follow the | |
2023 | following steps: | |
c906108c SS |
2024 | |
2025 | @table @emph | |
2026 | @item Create the expression parser. | |
2027 | ||
56caf160 | 2028 | @cindex expression parser |
c906108c | 2029 | This should reside in a file @file{@var{lang}-exp.y}. Routines for |
56caf160 | 2030 | building parsed expressions into a @code{union exp_element} list are in |
c906108c SS |
2031 | @file{parse.c}. |
2032 | ||
56caf160 | 2033 | @cindex language parser |
c906108c SS |
2034 | Since we can't depend upon everyone having Bison, and YACC produces |
2035 | parsers that define a bunch of global names, the following lines | |
56caf160 | 2036 | @strong{must} be included at the top of the YACC parser, to prevent the |
c906108c SS |
2037 | various parsers from defining the same global names: |
2038 | ||
474c8240 | 2039 | @smallexample |
56caf160 EZ |
2040 | #define yyparse @var{lang}_parse |
2041 | #define yylex @var{lang}_lex | |
2042 | #define yyerror @var{lang}_error | |
2043 | #define yylval @var{lang}_lval | |
2044 | #define yychar @var{lang}_char | |
2045 | #define yydebug @var{lang}_debug | |
2046 | #define yypact @var{lang}_pact | |
2047 | #define yyr1 @var{lang}_r1 | |
2048 | #define yyr2 @var{lang}_r2 | |
2049 | #define yydef @var{lang}_def | |
2050 | #define yychk @var{lang}_chk | |
2051 | #define yypgo @var{lang}_pgo | |
2052 | #define yyact @var{lang}_act | |
2053 | #define yyexca @var{lang}_exca | |
2054 | #define yyerrflag @var{lang}_errflag | |
2055 | #define yynerrs @var{lang}_nerrs | |
474c8240 | 2056 | @end smallexample |
c906108c SS |
2057 | |
2058 | At the bottom of your parser, define a @code{struct language_defn} and | |
2059 | initialize it with the right values for your language. Define an | |
2060 | @code{initialize_@var{lang}} routine and have it call | |
25822942 | 2061 | @samp{add_language(@var{lang}_language_defn)} to tell the rest of @value{GDBN} |
c906108c SS |
2062 | that your language exists. You'll need some other supporting variables |
2063 | and functions, which will be used via pointers from your | |
2064 | @code{@var{lang}_language_defn}. See the declaration of @code{struct | |
2065 | language_defn} in @file{language.h}, and the other @file{*-exp.y} files, | |
2066 | for more information. | |
2067 | ||
2068 | @item Add any evaluation routines, if necessary | |
2069 | ||
56caf160 EZ |
2070 | @cindex expression evaluation routines |
2071 | @findex evaluate_subexp | |
2072 | @findex prefixify_subexp | |
2073 | @findex length_of_subexp | |
c906108c SS |
2074 | If you need new opcodes (that represent the operations of the language), |
2075 | add them to the enumerated type in @file{expression.h}. Add support | |
56caf160 EZ |
2076 | code for these operations in the @code{evaluate_subexp} function |
2077 | defined in the file @file{eval.c}. Add cases | |
c906108c | 2078 | for new opcodes in two functions from @file{parse.c}: |
56caf160 | 2079 | @code{prefixify_subexp} and @code{length_of_subexp}. These compute |
c906108c SS |
2080 | the number of @code{exp_element}s that a given operation takes up. |
2081 | ||
2082 | @item Update some existing code | |
2083 | ||
2084 | Add an enumerated identifier for your language to the enumerated type | |
2085 | @code{enum language} in @file{defs.h}. | |
2086 | ||
2087 | Update the routines in @file{language.c} so your language is included. | |
2088 | These routines include type predicates and such, which (in some cases) | |
2089 | are language dependent. If your language does not appear in the switch | |
2090 | statement, an error is reported. | |
2091 | ||
56caf160 | 2092 | @vindex current_language |
c906108c SS |
2093 | Also included in @file{language.c} is the code that updates the variable |
2094 | @code{current_language}, and the routines that translate the | |
2095 | @code{language_@var{lang}} enumerated identifier into a printable | |
2096 | string. | |
2097 | ||
56caf160 | 2098 | @findex _initialize_language |
c906108c SS |
2099 | Update the function @code{_initialize_language} to include your |
2100 | language. This function picks the default language upon startup, so is | |
25822942 | 2101 | dependent upon which languages that @value{GDBN} is built for. |
c906108c | 2102 | |
56caf160 | 2103 | @findex allocate_symtab |
c906108c SS |
2104 | Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading |
2105 | code so that the language of each symtab (source file) is set properly. | |
2106 | This is used to determine the language to use at each stack frame level. | |
2107 | Currently, the language is set based upon the extension of the source | |
2108 | file. If the language can be better inferred from the symbol | |
2109 | information, please set the language of the symtab in the symbol-reading | |
2110 | code. | |
2111 | ||
56caf160 EZ |
2112 | @findex print_subexp |
2113 | @findex op_print_tab | |
2114 | Add helper code to @code{print_subexp} (in @file{expprint.c}) to handle any new | |
c906108c SS |
2115 | expression opcodes you have added to @file{expression.h}. Also, add the |
2116 | printed representations of your operators to @code{op_print_tab}. | |
2117 | ||
2118 | @item Add a place of call | |
2119 | ||
56caf160 | 2120 | @findex parse_exp_1 |
c906108c | 2121 | Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in |
56caf160 | 2122 | @code{parse_exp_1} (defined in @file{parse.c}). |
c906108c SS |
2123 | |
2124 | @item Use macros to trim code | |
2125 | ||
56caf160 | 2126 | @cindex trimming language-dependent code |
25822942 DB |
2127 | The user has the option of building @value{GDBN} for some or all of the |
2128 | languages. If the user decides to build @value{GDBN} for the language | |
c906108c SS |
2129 | @var{lang}, then every file dependent on @file{language.h} will have the |
2130 | macro @code{_LANG_@var{lang}} defined in it. Use @code{#ifdef}s to | |
2131 | leave out large routines that the user won't need if he or she is not | |
2132 | using your language. | |
2133 | ||
25822942 | 2134 | Note that you do not need to do this in your YACC parser, since if @value{GDBN} |
c906108c | 2135 | is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the |
25822942 | 2136 | compiled form of your parser) is not linked into @value{GDBN} at all. |
c906108c | 2137 | |
56caf160 EZ |
2138 | See the file @file{configure.in} for how @value{GDBN} is configured |
2139 | for different languages. | |
c906108c SS |
2140 | |
2141 | @item Edit @file{Makefile.in} | |
2142 | ||
2143 | Add dependencies in @file{Makefile.in}. Make sure you update the macro | |
2144 | variables such as @code{HFILES} and @code{OBJS}, otherwise your code may | |
2145 | not get linked in, or, worse yet, it may not get @code{tar}red into the | |
2146 | distribution! | |
c906108c SS |
2147 | @end table |
2148 | ||
2149 | ||
2150 | @node Host Definition | |
2151 | ||
2152 | @chapter Host Definition | |
2153 | ||
56caf160 | 2154 | With the advent of Autoconf, it's rarely necessary to have host |
7fd60527 AC |
2155 | definition machinery anymore. The following information is provided, |
2156 | mainly, as an historical reference. | |
c906108c SS |
2157 | |
2158 | @section Adding a New Host | |
2159 | ||
56caf160 EZ |
2160 | @cindex adding a new host |
2161 | @cindex host, adding | |
7fd60527 AC |
2162 | @value{GDBN}'s host configuration support normally happens via Autoconf. |
2163 | New host-specific definitions should not be needed. Older hosts | |
2164 | @value{GDBN} still use the host-specific definitions and files listed | |
2165 | below, but these mostly exist for historical reasons, and will | |
56caf160 | 2166 | eventually disappear. |
c906108c | 2167 | |
c906108c | 2168 | @table @file |
c906108c | 2169 | @item gdb/config/@var{arch}/@var{xyz}.mh |
7fd60527 AC |
2170 | This file once contained both host and native configuration information |
2171 | (@pxref{Native Debugging}) for the machine @var{xyz}. The host | |
2172 | configuration information is now handed by Autoconf. | |
2173 | ||
2174 | Host configuration information included a definition of | |
2175 | @code{XM_FILE=xm-@var{xyz}.h} and possibly definitions for @code{CC}, | |
7708fa01 AC |
2176 | @code{SYSV_DEFINE}, @code{XM_CFLAGS}, @code{XM_ADD_FILES}, |
2177 | @code{XM_CLIBS}, @code{XM_CDEPS}, etc.; see @file{Makefile.in}. | |
c906108c | 2178 | |
7fd60527 AC |
2179 | New host only configurations do not need this file. |
2180 | ||
c906108c | 2181 | @item gdb/config/@var{arch}/xm-@var{xyz}.h |
7fd60527 AC |
2182 | This file once contained definitions and includes required when hosting |
2183 | gdb on machine @var{xyz}. Those definitions and includes are now | |
2184 | handled by Autoconf. | |
2185 | ||
2186 | New host and native configurations do not need this file. | |
2187 | ||
2188 | @emph{Maintainer's note: Some hosts continue to use the @file{xm-xyz.h} | |
2189 | file to define the macros @var{HOST_FLOAT_FORMAT}, | |
2190 | @var{HOST_DOUBLE_FORMAT} and @var{HOST_LONG_DOUBLE_FORMAT}. That code | |
2191 | also needs to be replaced with either an Autoconf or run-time test.} | |
c906108c | 2192 | |
c906108c SS |
2193 | @end table |
2194 | ||
2195 | @subheading Generic Host Support Files | |
2196 | ||
56caf160 | 2197 | @cindex generic host support |
c906108c SS |
2198 | There are some ``generic'' versions of routines that can be used by |
2199 | various systems. These can be customized in various ways by macros | |
2200 | defined in your @file{xm-@var{xyz}.h} file. If these routines work for | |
2201 | the @var{xyz} host, you can just include the generic file's name (with | |
2202 | @samp{.o}, not @samp{.c}) in @code{XDEPFILES}. | |
2203 | ||
2204 | Otherwise, if your machine needs custom support routines, you will need | |
2205 | to write routines that perform the same functions as the generic file. | |
2206 | Put them into @code{@var{xyz}-xdep.c}, and put @code{@var{xyz}-xdep.o} | |
2207 | into @code{XDEPFILES}. | |
2208 | ||
2209 | @table @file | |
56caf160 EZ |
2210 | @cindex remote debugging support |
2211 | @cindex serial line support | |
c906108c SS |
2212 | @item ser-unix.c |
2213 | This contains serial line support for Unix systems. This is always | |
2214 | included, via the makefile variable @code{SER_HARDWIRE}; override this | |
2215 | variable in the @file{.mh} file to avoid it. | |
2216 | ||
2217 | @item ser-go32.c | |
2218 | This contains serial line support for 32-bit programs running under DOS, | |
56caf160 | 2219 | using the DJGPP (a.k.a.@: GO32) execution environment. |
c906108c | 2220 | |
56caf160 | 2221 | @cindex TCP remote support |
c906108c SS |
2222 | @item ser-tcp.c |
2223 | This contains generic TCP support using sockets. | |
c906108c SS |
2224 | @end table |
2225 | ||
2226 | @section Host Conditionals | |
2227 | ||
56caf160 EZ |
2228 | When @value{GDBN} is configured and compiled, various macros are |
2229 | defined or left undefined, to control compilation based on the | |
2230 | attributes of the host system. These macros and their meanings (or if | |
2231 | the meaning is not documented here, then one of the source files where | |
2232 | they are used is indicated) are: | |
c906108c | 2233 | |
56caf160 | 2234 | @ftable @code |
25822942 | 2235 | @item @value{GDBN}INIT_FILENAME |
56caf160 EZ |
2236 | The default name of @value{GDBN}'s initialization file (normally |
2237 | @file{.gdbinit}). | |
c906108c | 2238 | |
cce74817 JM |
2239 | @item NO_STD_REGS |
2240 | This macro is deprecated. | |
2241 | ||
c906108c SS |
2242 | @item SIGWINCH_HANDLER |
2243 | If your host defines @code{SIGWINCH}, you can define this to be the name | |
2244 | of a function to be called if @code{SIGWINCH} is received. | |
2245 | ||
2246 | @item SIGWINCH_HANDLER_BODY | |
2247 | Define this to expand into code that will define the function named by | |
2248 | the expansion of @code{SIGWINCH_HANDLER}. | |
2249 | ||
2250 | @item ALIGN_STACK_ON_STARTUP | |
56caf160 | 2251 | @cindex stack alignment |
c906108c SS |
2252 | Define this if your system is of a sort that will crash in |
2253 | @code{tgetent} if the stack happens not to be longword-aligned when | |
2254 | @code{main} is called. This is a rare situation, but is known to occur | |
2255 | on several different types of systems. | |
2256 | ||
2257 | @item CRLF_SOURCE_FILES | |
56caf160 | 2258 | @cindex DOS text files |
c906108c SS |
2259 | Define this if host files use @code{\r\n} rather than @code{\n} as a |
2260 | line terminator. This will cause source file listings to omit @code{\r} | |
56caf160 EZ |
2261 | characters when printing and it will allow @code{\r\n} line endings of files |
2262 | which are ``sourced'' by gdb. It must be possible to open files in binary | |
c906108c SS |
2263 | mode using @code{O_BINARY} or, for fopen, @code{"rb"}. |
2264 | ||
2265 | @item DEFAULT_PROMPT | |
56caf160 | 2266 | @cindex prompt |
c906108c SS |
2267 | The default value of the prompt string (normally @code{"(gdb) "}). |
2268 | ||
2269 | @item DEV_TTY | |
56caf160 | 2270 | @cindex terminal device |
c906108c SS |
2271 | The name of the generic TTY device, defaults to @code{"/dev/tty"}. |
2272 | ||
c906108c SS |
2273 | @item FOPEN_RB |
2274 | Define this if binary files are opened the same way as text files. | |
2275 | ||
c906108c | 2276 | @item HAVE_MMAP |
56caf160 | 2277 | @findex mmap |
c906108c SS |
2278 | In some cases, use the system call @code{mmap} for reading symbol |
2279 | tables. For some machines this allows for sharing and quick updates. | |
2280 | ||
c906108c SS |
2281 | @item HAVE_TERMIO |
2282 | Define this if the host system has @code{termio.h}. | |
2283 | ||
c906108c | 2284 | @item INT_MAX |
9742079a EZ |
2285 | @itemx INT_MIN |
2286 | @itemx LONG_MAX | |
2287 | @itemx UINT_MAX | |
2288 | @itemx ULONG_MAX | |
c906108c SS |
2289 | Values for host-side constants. |
2290 | ||
2291 | @item ISATTY | |
2292 | Substitute for isatty, if not available. | |
2293 | ||
2294 | @item LONGEST | |
2295 | This is the longest integer type available on the host. If not defined, | |
2296 | it will default to @code{long long} or @code{long}, depending on | |
2297 | @code{CC_HAS_LONG_LONG}. | |
2298 | ||
2299 | @item CC_HAS_LONG_LONG | |
56caf160 EZ |
2300 | @cindex @code{long long} data type |
2301 | Define this if the host C compiler supports @code{long long}. This is set | |
2302 | by the @code{configure} script. | |
c906108c SS |
2303 | |
2304 | @item PRINTF_HAS_LONG_LONG | |
2305 | Define this if the host can handle printing of long long integers via | |
56caf160 EZ |
2306 | the printf format conversion specifier @code{ll}. This is set by the |
2307 | @code{configure} script. | |
c906108c SS |
2308 | |
2309 | @item HAVE_LONG_DOUBLE | |
56caf160 EZ |
2310 | Define this if the host C compiler supports @code{long double}. This is |
2311 | set by the @code{configure} script. | |
c906108c SS |
2312 | |
2313 | @item PRINTF_HAS_LONG_DOUBLE | |
2314 | Define this if the host can handle printing of long double float-point | |
56caf160 EZ |
2315 | numbers via the printf format conversion specifier @code{Lg}. This is |
2316 | set by the @code{configure} script. | |
c906108c SS |
2317 | |
2318 | @item SCANF_HAS_LONG_DOUBLE | |
2319 | Define this if the host can handle the parsing of long double | |
56caf160 EZ |
2320 | float-point numbers via the scanf format conversion specifier |
2321 | @code{Lg}. This is set by the @code{configure} script. | |
c906108c SS |
2322 | |
2323 | @item LSEEK_NOT_LINEAR | |
2324 | Define this if @code{lseek (n)} does not necessarily move to byte number | |
2325 | @code{n} in the file. This is only used when reading source files. It | |
2326 | is normally faster to define @code{CRLF_SOURCE_FILES} when possible. | |
2327 | ||
2328 | @item L_SET | |
56caf160 EZ |
2329 | This macro is used as the argument to @code{lseek} (or, most commonly, |
2330 | @code{bfd_seek}). FIXME, should be replaced by SEEK_SET instead, | |
2331 | which is the POSIX equivalent. | |
c906108c | 2332 | |
c906108c SS |
2333 | @item NORETURN |
2334 | If defined, this should be one or more tokens, such as @code{volatile}, | |
2335 | that can be used in both the declaration and definition of functions to | |
2336 | indicate that they never return. The default is already set correctly | |
2337 | if compiling with GCC. This will almost never need to be defined. | |
2338 | ||
2339 | @item ATTR_NORETURN | |
2340 | If defined, this should be one or more tokens, such as | |
2341 | @code{__attribute__ ((noreturn))}, that can be used in the declarations | |
2342 | of functions to indicate that they never return. The default is already | |
2343 | set correctly if compiling with GCC. This will almost never need to be | |
2344 | defined. | |
2345 | ||
c906108c | 2346 | @item SEEK_CUR |
9742079a | 2347 | @itemx SEEK_SET |
56caf160 | 2348 | Define these to appropriate value for the system @code{lseek}, if not already |
c906108c SS |
2349 | defined. |
2350 | ||
2351 | @item STOP_SIGNAL | |
56caf160 EZ |
2352 | This is the signal for stopping @value{GDBN}. Defaults to |
2353 | @code{SIGTSTP}. (Only redefined for the Convex.) | |
c906108c | 2354 | |
c906108c SS |
2355 | @item USG |
2356 | Means that System V (prior to SVR4) include files are in use. (FIXME: | |
7ca9f392 AC |
2357 | This symbol is abused in @file{infrun.c}, @file{regex.c}, and |
2358 | @file{utils.c} for other things, at the moment.) | |
c906108c SS |
2359 | |
2360 | @item lint | |
56caf160 | 2361 | Define this to help placate @code{lint} in some situations. |
c906108c SS |
2362 | |
2363 | @item volatile | |
2364 | Define this to override the defaults of @code{__volatile__} or | |
2365 | @code{/**/}. | |
56caf160 | 2366 | @end ftable |
c906108c SS |
2367 | |
2368 | ||
2369 | @node Target Architecture Definition | |
2370 | ||
2371 | @chapter Target Architecture Definition | |
2372 | ||
56caf160 EZ |
2373 | @cindex target architecture definition |
2374 | @value{GDBN}'s target architecture defines what sort of | |
2375 | machine-language programs @value{GDBN} can work with, and how it works | |
2376 | with them. | |
c906108c | 2377 | |
af6c57ea AC |
2378 | The target architecture object is implemented as the C structure |
2379 | @code{struct gdbarch *}. The structure, and its methods, are generated | |
93c2c750 | 2380 | using the Bourne shell script @file{gdbarch.sh}. |
c906108c | 2381 | |
70f80edf JT |
2382 | @section Operating System ABI Variant Handling |
2383 | @cindex OS ABI variants | |
2384 | ||
2385 | @value{GDBN} provides a mechanism for handling variations in OS | |
2386 | ABIs. An OS ABI variant may have influence over any number of | |
2387 | variables in the target architecture definition. There are two major | |
2388 | components in the OS ABI mechanism: sniffers and handlers. | |
2389 | ||
2390 | A @dfn{sniffer} examines a file matching a BFD architecture/flavour pair | |
2391 | (the architecture may be wildcarded) in an attempt to determine the | |
2392 | OS ABI of that file. Sniffers with a wildcarded architecture are considered | |
2393 | to be @dfn{generic}, while sniffers for a specific architecture are | |
2394 | considered to be @dfn{specific}. A match from a specific sniffer | |
2395 | overrides a match from a generic sniffer. Multiple sniffers for an | |
2396 | architecture/flavour may exist, in order to differentiate between two | |
2397 | different operating systems which use the same basic file format. The | |
2398 | OS ABI framework provides a generic sniffer for ELF-format files which | |
2399 | examines the @code{EI_OSABI} field of the ELF header, as well as note | |
2400 | sections known to be used by several operating systems. | |
2401 | ||
2402 | @cindex fine-tuning @code{gdbarch} structure | |
2403 | A @dfn{handler} is used to fine-tune the @code{gdbarch} structure for the | |
2404 | selected OS ABI. There may be only one handler for a given OS ABI | |
2405 | for each BFD architecture. | |
2406 | ||
2407 | The following OS ABI variants are defined in @file{osabi.h}: | |
2408 | ||
2409 | @table @code | |
2410 | ||
2411 | @findex GDB_OSABI_UNKNOWN | |
2412 | @item GDB_OSABI_UNKNOWN | |
2413 | The ABI of the inferior is unknown. The default @code{gdbarch} | |
2414 | settings for the architecture will be used. | |
2415 | ||
2416 | @findex GDB_OSABI_SVR4 | |
2417 | @item GDB_OSABI_SVR4 | |
2418 | UNIX System V Release 4 | |
2419 | ||
2420 | @findex GDB_OSABI_HURD | |
2421 | @item GDB_OSABI_HURD | |
2422 | GNU using the Hurd kernel | |
2423 | ||
2424 | @findex GDB_OSABI_SOLARIS | |
2425 | @item GDB_OSABI_SOLARIS | |
2426 | Sun Solaris | |
2427 | ||
2428 | @findex GDB_OSABI_OSF1 | |
2429 | @item GDB_OSABI_OSF1 | |
2430 | OSF/1, including Digital UNIX and Compaq Tru64 UNIX | |
2431 | ||
2432 | @findex GDB_OSABI_LINUX | |
2433 | @item GDB_OSABI_LINUX | |
2434 | GNU using the Linux kernel | |
2435 | ||
2436 | @findex GDB_OSABI_FREEBSD_AOUT | |
2437 | @item GDB_OSABI_FREEBSD_AOUT | |
2438 | FreeBSD using the a.out executable format | |
2439 | ||
2440 | @findex GDB_OSABI_FREEBSD_ELF | |
2441 | @item GDB_OSABI_FREEBSD_ELF | |
2442 | FreeBSD using the ELF executable format | |
2443 | ||
2444 | @findex GDB_OSABI_NETBSD_AOUT | |
2445 | @item GDB_OSABI_NETBSD_AOUT | |
2446 | NetBSD using the a.out executable format | |
2447 | ||
2448 | @findex GDB_OSABI_NETBSD_ELF | |
2449 | @item GDB_OSABI_NETBSD_ELF | |
2450 | NetBSD using the ELF executable format | |
2451 | ||
2452 | @findex GDB_OSABI_WINCE | |
2453 | @item GDB_OSABI_WINCE | |
2454 | Windows CE | |
2455 | ||
1029b7fa MK |
2456 | @findex GDB_OSABI_GO32 |
2457 | @item GDB_OSABI_GO32 | |
2458 | DJGPP | |
2459 | ||
2460 | @findex GDB_OSABI_NETWARE | |
2461 | @item GDB_OSABI_NETWARE | |
2462 | Novell NetWare | |
2463 | ||
70f80edf JT |
2464 | @findex GDB_OSABI_ARM_EABI_V1 |
2465 | @item GDB_OSABI_ARM_EABI_V1 | |
2466 | ARM Embedded ABI version 1 | |
2467 | ||
2468 | @findex GDB_OSABI_ARM_EABI_V2 | |
2469 | @item GDB_OSABI_ARM_EABI_V2 | |
2470 | ARM Embedded ABI version 2 | |
2471 | ||
2472 | @findex GDB_OSABI_ARM_APCS | |
2473 | @item GDB_OSABI_ARM_APCS | |
2474 | Generic ARM Procedure Call Standard | |
2475 | ||
2476 | @end table | |
2477 | ||
2478 | Here are the functions that make up the OS ABI framework: | |
2479 | ||
2480 | @deftypefun const char *gdbarch_osabi_name (enum gdb_osabi @var{osabi}) | |
2481 | Return the name of the OS ABI corresponding to @var{osabi}. | |
2482 | @end deftypefun | |
2483 | ||
c133ab7a | 2484 | @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 | 2485 | Register the OS ABI handler specified by @var{init_osabi} for the |
c133ab7a MK |
2486 | architecture, machine type and OS ABI specified by @var{arch}, |
2487 | @var{machine} and @var{osabi}. In most cases, a value of zero for the | |
2488 | machine type, which implies the architecture's default machine type, | |
2489 | will suffice. | |
70f80edf JT |
2490 | @end deftypefun |
2491 | ||
2492 | @deftypefun void gdbarch_register_osabi_sniffer (enum bfd_architecture @var{arch}, enum bfd_flavour @var{flavour}, enum gdb_osabi (*@var{sniffer})(bfd *@var{abfd})) | |
2493 | Register the OS ABI file sniffer specified by @var{sniffer} for the | |
2494 | BFD architecture/flavour pair specified by @var{arch} and @var{flavour}. | |
2495 | If @var{arch} is @code{bfd_arch_unknown}, the sniffer is considered to | |
2496 | be generic, and is allowed to examine @var{flavour}-flavoured files for | |
2497 | any architecture. | |
2498 | @end deftypefun | |
2499 | ||
2500 | @deftypefun enum gdb_osabi gdbarch_lookup_osabi (bfd *@var{abfd}) | |
2501 | Examine the file described by @var{abfd} to determine its OS ABI. | |
2502 | The value @code{GDB_OSABI_UNKNOWN} is returned if the OS ABI cannot | |
2503 | be determined. | |
2504 | @end deftypefun | |
2505 | ||
2506 | @deftypefun void gdbarch_init_osabi (struct gdbarch info @var{info}, struct gdbarch *@var{gdbarch}, enum gdb_osabi @var{osabi}) | |
2507 | Invoke the OS ABI handler corresponding to @var{osabi} to fine-tune the | |
2508 | @code{gdbarch} structure specified by @var{gdbarch}. If a handler | |
2509 | corresponding to @var{osabi} has not been registered for @var{gdbarch}'s | |
2510 | architecture, a warning will be issued and the debugging session will continue | |
2511 | with the defaults already established for @var{gdbarch}. | |
2512 | @end deftypefun | |
2513 | ||
c906108c SS |
2514 | @section Registers and Memory |
2515 | ||
56caf160 EZ |
2516 | @value{GDBN}'s model of the target machine is rather simple. |
2517 | @value{GDBN} assumes the machine includes a bank of registers and a | |
2518 | block of memory. Each register may have a different size. | |
c906108c | 2519 | |
56caf160 EZ |
2520 | @value{GDBN} does not have a magical way to match up with the |
2521 | compiler's idea of which registers are which; however, it is critical | |
2522 | that they do match up accurately. The only way to make this work is | |
2523 | to get accurate information about the order that the compiler uses, | |
2524 | and to reflect that in the @code{REGISTER_NAME} and related macros. | |
c906108c | 2525 | |
25822942 | 2526 | @value{GDBN} can handle big-endian, little-endian, and bi-endian architectures. |
c906108c | 2527 | |
93e79dbd JB |
2528 | @section Pointers Are Not Always Addresses |
2529 | @cindex pointer representation | |
2530 | @cindex address representation | |
2531 | @cindex word-addressed machines | |
2532 | @cindex separate data and code address spaces | |
2533 | @cindex spaces, separate data and code address | |
2534 | @cindex address spaces, separate data and code | |
2535 | @cindex code pointers, word-addressed | |
2536 | @cindex converting between pointers and addresses | |
2537 | @cindex D10V addresses | |
2538 | ||
2539 | On almost all 32-bit architectures, the representation of a pointer is | |
2540 | indistinguishable from the representation of some fixed-length number | |
2541 | whose value is the byte address of the object pointed to. On such | |
56caf160 | 2542 | machines, the words ``pointer'' and ``address'' can be used interchangeably. |
93e79dbd JB |
2543 | However, architectures with smaller word sizes are often cramped for |
2544 | address space, so they may choose a pointer representation that breaks this | |
2545 | identity, and allows a larger code address space. | |
2546 | ||
172c2a43 | 2547 | For example, the Renesas D10V is a 16-bit VLIW processor whose |
93e79dbd JB |
2548 | instructions are 32 bits long@footnote{Some D10V instructions are |
2549 | actually pairs of 16-bit sub-instructions. However, since you can't | |
2550 | jump into the middle of such a pair, code addresses can only refer to | |
2551 | full 32 bit instructions, which is what matters in this explanation.}. | |
2552 | If the D10V used ordinary byte addresses to refer to code locations, | |
2553 | then the processor would only be able to address 64kb of instructions. | |
2554 | However, since instructions must be aligned on four-byte boundaries, the | |
56caf160 EZ |
2555 | low two bits of any valid instruction's byte address are always |
2556 | zero---byte addresses waste two bits. So instead of byte addresses, | |
2557 | the D10V uses word addresses---byte addresses shifted right two bits---to | |
93e79dbd JB |
2558 | refer to code. Thus, the D10V can use 16-bit words to address 256kb of |
2559 | code space. | |
2560 | ||
2561 | However, this means that code pointers and data pointers have different | |
2562 | forms on the D10V. The 16-bit word @code{0xC020} refers to byte address | |
2563 | @code{0xC020} when used as a data address, but refers to byte address | |
2564 | @code{0x30080} when used as a code address. | |
2565 | ||
2566 | (The D10V also uses separate code and data address spaces, which also | |
2567 | affects the correspondence between pointers and addresses, but we're | |
2568 | going to ignore that here; this example is already too long.) | |
2569 | ||
56caf160 EZ |
2570 | To cope with architectures like this---the D10V is not the only |
2571 | one!---@value{GDBN} tries to distinguish between @dfn{addresses}, which are | |
93e79dbd JB |
2572 | byte numbers, and @dfn{pointers}, which are the target's representation |
2573 | of an address of a particular type of data. In the example above, | |
2574 | @code{0xC020} is the pointer, which refers to one of the addresses | |
2575 | @code{0xC020} or @code{0x30080}, depending on the type imposed upon it. | |
2576 | @value{GDBN} provides functions for turning a pointer into an address | |
2577 | and vice versa, in the appropriate way for the current architecture. | |
2578 | ||
2579 | Unfortunately, since addresses and pointers are identical on almost all | |
2580 | processors, this distinction tends to bit-rot pretty quickly. Thus, | |
2581 | each time you port @value{GDBN} to an architecture which does | |
2582 | distinguish between pointers and addresses, you'll probably need to | |
2583 | clean up some architecture-independent code. | |
2584 | ||
2585 | Here are functions which convert between pointers and addresses: | |
2586 | ||
2587 | @deftypefun CORE_ADDR extract_typed_address (void *@var{buf}, struct type *@var{type}) | |
2588 | Treat the bytes at @var{buf} as a pointer or reference of type | |
2589 | @var{type}, and return the address it represents, in a manner | |
2590 | appropriate for the current architecture. This yields an address | |
2591 | @value{GDBN} can use to read target memory, disassemble, etc. Note that | |
2592 | @var{buf} refers to a buffer in @value{GDBN}'s memory, not the | |
2593 | inferior's. | |
2594 | ||
2595 | For example, if the current architecture is the Intel x86, this function | |
2596 | extracts a little-endian integer of the appropriate length from | |
2597 | @var{buf} and returns it. However, if the current architecture is the | |
2598 | D10V, this function will return a 16-bit integer extracted from | |
2599 | @var{buf}, multiplied by four if @var{type} is a pointer to a function. | |
2600 | ||
2601 | If @var{type} is not a pointer or reference type, then this function | |
2602 | will signal an internal error. | |
2603 | @end deftypefun | |
2604 | ||
2605 | @deftypefun CORE_ADDR store_typed_address (void *@var{buf}, struct type *@var{type}, CORE_ADDR @var{addr}) | |
2606 | Store the address @var{addr} in @var{buf}, in the proper format for a | |
2607 | pointer of type @var{type} in the current architecture. Note that | |
2608 | @var{buf} refers to a buffer in @value{GDBN}'s memory, not the | |
2609 | inferior's. | |
2610 | ||
2611 | For example, if the current architecture is the Intel x86, this function | |
2612 | stores @var{addr} unmodified as a little-endian integer of the | |
2613 | appropriate length in @var{buf}. However, if the current architecture | |
2614 | is the D10V, this function divides @var{addr} by four if @var{type} is | |
2615 | a pointer to a function, and then stores it in @var{buf}. | |
2616 | ||
2617 | If @var{type} is not a pointer or reference type, then this function | |
2618 | will signal an internal error. | |
2619 | @end deftypefun | |
2620 | ||
f23631e4 | 2621 | @deftypefun CORE_ADDR value_as_address (struct value *@var{val}) |
93e79dbd JB |
2622 | Assuming that @var{val} is a pointer, return the address it represents, |
2623 | as appropriate for the current architecture. | |
2624 | ||
2625 | This function actually works on integral values, as well as pointers. | |
2626 | For pointers, it performs architecture-specific conversions as | |
2627 | described above for @code{extract_typed_address}. | |
2628 | @end deftypefun | |
2629 | ||
2630 | @deftypefun CORE_ADDR value_from_pointer (struct type *@var{type}, CORE_ADDR @var{addr}) | |
2631 | Create and return a value representing a pointer of type @var{type} to | |
2632 | the address @var{addr}, as appropriate for the current architecture. | |
2633 | This function performs architecture-specific conversions as described | |
2634 | above for @code{store_typed_address}. | |
2635 | @end deftypefun | |
2636 | ||
93e79dbd JB |
2637 | Here are some macros which architectures can define to indicate the |
2638 | relationship between pointers and addresses. These have default | |
2639 | definitions, appropriate for architectures on which all pointers are | |
fc0c74b1 | 2640 | simple unsigned byte addresses. |
93e79dbd JB |
2641 | |
2642 | @deftypefn {Target Macro} CORE_ADDR POINTER_TO_ADDRESS (struct type *@var{type}, char *@var{buf}) | |
2643 | Assume that @var{buf} holds a pointer of type @var{type}, in the | |
2644 | appropriate format for the current architecture. Return the byte | |
2645 | address the pointer refers to. | |
2646 | ||
2647 | This function may safely assume that @var{type} is either a pointer or a | |
56caf160 | 2648 | C@t{++} reference type. |
93e79dbd JB |
2649 | @end deftypefn |
2650 | ||
2651 | @deftypefn {Target Macro} void ADDRESS_TO_POINTER (struct type *@var{type}, char *@var{buf}, CORE_ADDR @var{addr}) | |
2652 | Store in @var{buf} a pointer of type @var{type} representing the address | |
2653 | @var{addr}, in the appropriate format for the current architecture. | |
2654 | ||
2655 | This function may safely assume that @var{type} is either a pointer or a | |
56caf160 | 2656 | C@t{++} reference type. |
93e79dbd JB |
2657 | @end deftypefn |
2658 | ||
b5b0480a KB |
2659 | @section Address Classes |
2660 | @cindex address classes | |
2661 | @cindex DW_AT_byte_size | |
2662 | @cindex DW_AT_address_class | |
2663 | ||
2664 | Sometimes information about different kinds of addresses is available | |
2665 | via the debug information. For example, some programming environments | |
2666 | define addresses of several different sizes. If the debug information | |
2667 | distinguishes these kinds of address classes through either the size | |
2668 | info (e.g, @code{DW_AT_byte_size} in @w{DWARF 2}) or through an explicit | |
2669 | address class attribute (e.g, @code{DW_AT_address_class} in @w{DWARF 2}), the | |
2670 | following macros should be defined in order to disambiguate these | |
2671 | types within @value{GDBN} as well as provide the added information to | |
2672 | a @value{GDBN} user when printing type expressions. | |
2673 | ||
2674 | @deftypefn {Target Macro} int ADDRESS_CLASS_TYPE_FLAGS (int @var{byte_size}, int @var{dwarf2_addr_class}) | |
2675 | Returns the type flags needed to construct a pointer type whose size | |
2676 | is @var{byte_size} and whose address class is @var{dwarf2_addr_class}. | |
2677 | This function is normally called from within a symbol reader. See | |
2678 | @file{dwarf2read.c}. | |
2679 | @end deftypefn | |
2680 | ||
2681 | @deftypefn {Target Macro} char *ADDRESS_CLASS_TYPE_FLAGS_TO_NAME (int @var{type_flags}) | |
2682 | Given the type flags representing an address class qualifier, return | |
2683 | its name. | |
2684 | @end deftypefn | |
2685 | @deftypefn {Target Macro} int ADDRESS_CLASS_NAME_to_TYPE_FLAGS (int @var{name}, int *var{type_flags_ptr}) | |
2686 | Given an address qualifier name, set the @code{int} refererenced by @var{type_flags_ptr} to the type flags | |
2687 | for that address class qualifier. | |
2688 | @end deftypefn | |
2689 | ||
2690 | Since the need for address classes is rather rare, none of | |
2691 | the address class macros defined by default. Predicate | |
2692 | macros are provided to detect when they are defined. | |
2693 | ||
2694 | Consider a hypothetical architecture in which addresses are normally | |
2695 | 32-bits wide, but 16-bit addresses are also supported. Furthermore, | |
2696 | suppose that the @w{DWARF 2} information for this architecture simply | |
2697 | uses a @code{DW_AT_byte_size} value of 2 to indicate the use of one | |
2698 | of these "short" pointers. The following functions could be defined | |
2699 | to implement the address class macros: | |
2700 | ||
2701 | @smallexample | |
2702 | somearch_address_class_type_flags (int byte_size, | |
2703 | int dwarf2_addr_class) | |
f2abfe65 | 2704 | @{ |
b5b0480a KB |
2705 | if (byte_size == 2) |
2706 | return TYPE_FLAG_ADDRESS_CLASS_1; | |
2707 | else | |
2708 | return 0; | |
f2abfe65 | 2709 | @} |
b5b0480a KB |
2710 | |
2711 | static char * | |
2712 | somearch_address_class_type_flags_to_name (int type_flags) | |
f2abfe65 | 2713 | @{ |
b5b0480a KB |
2714 | if (type_flags & TYPE_FLAG_ADDRESS_CLASS_1) |
2715 | return "short"; | |
2716 | else | |
2717 | return NULL; | |
f2abfe65 | 2718 | @} |
b5b0480a KB |
2719 | |
2720 | int | |
2721 | somearch_address_class_name_to_type_flags (char *name, | |
2722 | int *type_flags_ptr) | |
f2abfe65 | 2723 | @{ |
b5b0480a | 2724 | if (strcmp (name, "short") == 0) |
f2abfe65 | 2725 | @{ |
b5b0480a KB |
2726 | *type_flags_ptr = TYPE_FLAG_ADDRESS_CLASS_1; |
2727 | return 1; | |
f2abfe65 | 2728 | @} |
b5b0480a KB |
2729 | else |
2730 | return 0; | |
f2abfe65 | 2731 | @} |
b5b0480a KB |
2732 | @end smallexample |
2733 | ||
2734 | The qualifier @code{@@short} is used in @value{GDBN}'s type expressions | |
2735 | to indicate the presence of one of these "short" pointers. E.g, if | |
2736 | the debug information indicates that @code{short_ptr_var} is one of these | |
2737 | short pointers, @value{GDBN} might show the following behavior: | |
2738 | ||
2739 | @smallexample | |
2740 | (gdb) ptype short_ptr_var | |
2741 | type = int * @@short | |
2742 | @end smallexample | |
2743 | ||
93e79dbd | 2744 | |
13d01224 AC |
2745 | @section Raw and Virtual Register Representations |
2746 | @cindex raw register representation | |
2747 | @cindex virtual register representation | |
2748 | @cindex representations, raw and virtual registers | |
2749 | ||
2750 | @emph{Maintainer note: This section is pretty much obsolete. The | |
2751 | functionality described here has largely been replaced by | |
2752 | pseudo-registers and the mechanisms described in @ref{Target | |
2753 | Architecture Definition, , Using Different Register and Memory Data | |
2754 | Representations}. See also @uref{http://www.gnu.org/software/gdb/bugs/, | |
2755 | Bug Tracking Database} and | |
2756 | @uref{http://sources.redhat.com/gdb/current/ari/, ARI Index} for more | |
2757 | up-to-date information.} | |
af6c57ea | 2758 | |
9fb4dd36 JB |
2759 | Some architectures use one representation for a value when it lives in a |
2760 | register, but use a different representation when it lives in memory. | |
25822942 | 2761 | In @value{GDBN}'s terminology, the @dfn{raw} representation is the one used in |
9fb4dd36 | 2762 | the target registers, and the @dfn{virtual} representation is the one |
25822942 | 2763 | used in memory, and within @value{GDBN} @code{struct value} objects. |
9fb4dd36 | 2764 | |
13d01224 AC |
2765 | @emph{Maintainer note: Notice that the same mechanism is being used to |
2766 | both convert a register to a @code{struct value} and alternative | |
2767 | register forms.} | |
2768 | ||
9fb4dd36 JB |
2769 | For almost all data types on almost all architectures, the virtual and |
2770 | raw representations are identical, and no special handling is needed. | |
2771 | However, they do occasionally differ. For example: | |
2772 | ||
2773 | @itemize @bullet | |
9fb4dd36 | 2774 | @item |
56caf160 | 2775 | The x86 architecture supports an 80-bit @code{long double} type. However, when |
9fb4dd36 JB |
2776 | we store those values in memory, they occupy twelve bytes: the |
2777 | floating-point number occupies the first ten, and the final two bytes | |
2778 | are unused. This keeps the values aligned on four-byte boundaries, | |
2779 | allowing more efficient access. Thus, the x86 80-bit floating-point | |
2780 | type is the raw representation, and the twelve-byte loosely-packed | |
2781 | arrangement is the virtual representation. | |
2782 | ||
2783 | @item | |
25822942 DB |
2784 | Some 64-bit MIPS targets present 32-bit registers to @value{GDBN} as 64-bit |
2785 | registers, with garbage in their upper bits. @value{GDBN} ignores the top 32 | |
9fb4dd36 JB |
2786 | bits. Thus, the 64-bit form, with garbage in the upper 32 bits, is the |
2787 | raw representation, and the trimmed 32-bit representation is the | |
2788 | virtual representation. | |
9fb4dd36 JB |
2789 | @end itemize |
2790 | ||
2791 | In general, the raw representation is determined by the architecture, or | |
25822942 DB |
2792 | @value{GDBN}'s interface to the architecture, while the virtual representation |
2793 | can be chosen for @value{GDBN}'s convenience. @value{GDBN}'s register file, | |
56caf160 EZ |
2794 | @code{registers}, holds the register contents in raw format, and the |
2795 | @value{GDBN} remote protocol transmits register values in raw format. | |
9fb4dd36 | 2796 | |
56caf160 EZ |
2797 | Your architecture may define the following macros to request |
2798 | conversions between the raw and virtual format: | |
9fb4dd36 JB |
2799 | |
2800 | @deftypefn {Target Macro} int REGISTER_CONVERTIBLE (int @var{reg}) | |
2801 | Return non-zero if register number @var{reg}'s value needs different raw | |
2802 | and virtual formats. | |
6f6ef15a EZ |
2803 | |
2804 | You should not use @code{REGISTER_CONVERT_TO_VIRTUAL} for a register | |
2805 | unless this macro returns a non-zero value for that register. | |
9fb4dd36 JB |
2806 | @end deftypefn |
2807 | ||
12c266ea | 2808 | @deftypefn {Target Macro} int DEPRECATED_REGISTER_RAW_SIZE (int @var{reg}) |
9fb4dd36 | 2809 | The size of register number @var{reg}'s raw value. This is the number |
25822942 | 2810 | of bytes the register will occupy in @code{registers}, or in a @value{GDBN} |
9fb4dd36 JB |
2811 | remote protocol packet. |
2812 | @end deftypefn | |
2813 | ||
f30992d4 | 2814 | @deftypefn {Target Macro} int DEPRECATED_REGISTER_VIRTUAL_SIZE (int @var{reg}) |
9fb4dd36 JB |
2815 | The size of register number @var{reg}'s value, in its virtual format. |
2816 | This is the size a @code{struct value}'s buffer will have, holding that | |
2817 | register's value. | |
2818 | @end deftypefn | |
2819 | ||
2e092625 | 2820 | @deftypefn {Target Macro} struct type *DEPRECATED_REGISTER_VIRTUAL_TYPE (int @var{reg}) |
9fb4dd36 JB |
2821 | This is the type of the virtual representation of register number |
2822 | @var{reg}. Note that there is no need for a macro giving a type for the | |
25822942 | 2823 | register's raw form; once the register's value has been obtained, @value{GDBN} |
9fb4dd36 JB |
2824 | always uses the virtual form. |
2825 | @end deftypefn | |
2826 | ||
2827 | @deftypefn {Target Macro} void REGISTER_CONVERT_TO_VIRTUAL (int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to}) | |
2828 | Convert the value of register number @var{reg} to @var{type}, which | |
2e092625 | 2829 | should always be @code{DEPRECATED_REGISTER_VIRTUAL_TYPE (@var{reg})}. The buffer |
9fb4dd36 JB |
2830 | at @var{from} holds the register's value in raw format; the macro should |
2831 | convert the value to virtual format, and place it at @var{to}. | |
2832 | ||
6f6ef15a EZ |
2833 | Note that @code{REGISTER_CONVERT_TO_VIRTUAL} and |
2834 | @code{REGISTER_CONVERT_TO_RAW} take their @var{reg} and @var{type} | |
2835 | arguments in different orders. | |
2836 | ||
2837 | You should only use @code{REGISTER_CONVERT_TO_VIRTUAL} with registers | |
2838 | for which the @code{REGISTER_CONVERTIBLE} macro returns a non-zero | |
2839 | value. | |
9fb4dd36 JB |
2840 | @end deftypefn |
2841 | ||
2842 | @deftypefn {Target Macro} void REGISTER_CONVERT_TO_RAW (struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to}) | |
2843 | Convert the value of register number @var{reg} to @var{type}, which | |
2e092625 | 2844 | should always be @code{DEPRECATED_REGISTER_VIRTUAL_TYPE (@var{reg})}. The buffer |
9fb4dd36 JB |
2845 | at @var{from} holds the register's value in raw format; the macro should |
2846 | convert the value to virtual format, and place it at @var{to}. | |
2847 | ||
2848 | Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW take | |
2849 | their @var{reg} and @var{type} arguments in different orders. | |
2850 | @end deftypefn | |
2851 | ||
2852 | ||
13d01224 AC |
2853 | @section Using Different Register and Memory Data Representations |
2854 | @cindex register representation | |
2855 | @cindex memory representation | |
2856 | @cindex representations, register and memory | |
2857 | @cindex register data formats, converting | |
2858 | @cindex @code{struct value}, converting register contents to | |
2859 | ||
2860 | @emph{Maintainer's note: The way GDB manipulates registers is undergoing | |
2861 | significant change. Many of the macros and functions refered to in this | |
2862 | section are likely to be subject to further revision. See | |
2863 | @uref{http://sources.redhat.com/gdb/current/ari/, A.R. Index} and | |
2864 | @uref{http://www.gnu.org/software/gdb/bugs, Bug Tracking Database} for | |
2865 | further information. cagney/2002-05-06.} | |
2866 | ||
2867 | Some architectures can represent a data object in a register using a | |
2868 | form that is different to the objects more normal memory representation. | |
2869 | For example: | |
2870 | ||
2871 | @itemize @bullet | |
2872 | ||
2873 | @item | |
2874 | The Alpha architecture can represent 32 bit integer values in | |
2875 | floating-point registers. | |
2876 | ||
2877 | @item | |
2878 | The x86 architecture supports 80-bit floating-point registers. The | |
2879 | @code{long double} data type occupies 96 bits in memory but only 80 bits | |
2880 | when stored in a register. | |
2881 | ||
2882 | @end itemize | |
2883 | ||
2884 | In general, the register representation of a data type is determined by | |
2885 | the architecture, or @value{GDBN}'s interface to the architecture, while | |
2886 | the memory representation is determined by the Application Binary | |
2887 | Interface. | |
2888 | ||
2889 | For almost all data types on almost all architectures, the two | |
2890 | representations are identical, and no special handling is needed. | |
2891 | However, they do occasionally differ. Your architecture may define the | |
2892 | following macros to request conversions between the register and memory | |
2893 | representations of a data type: | |
2894 | ||
2895 | @deftypefn {Target Macro} int CONVERT_REGISTER_P (int @var{reg}) | |
2896 | Return non-zero if the representation of a data value stored in this | |
2897 | register may be different to the representation of that same data value | |
2898 | when stored in memory. | |
2899 | ||
2900 | When non-zero, the macros @code{REGISTER_TO_VALUE} and | |
2901 | @code{VALUE_TO_REGISTER} are used to perform any necessary conversion. | |
2902 | @end deftypefn | |
2903 | ||
2904 | @deftypefn {Target Macro} void REGISTER_TO_VALUE (int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to}) | |
2905 | Convert the value of register number @var{reg} to a data object of type | |
2906 | @var{type}. The buffer at @var{from} holds the register's value in raw | |
2907 | format; the converted value should be placed in the buffer at @var{to}. | |
2908 | ||
2909 | Note that @code{REGISTER_TO_VALUE} and @code{VALUE_TO_REGISTER} take | |
2910 | their @var{reg} and @var{type} arguments in different orders. | |
2911 | ||
2912 | You should only use @code{REGISTER_TO_VALUE} with registers for which | |
2913 | the @code{CONVERT_REGISTER_P} macro returns a non-zero value. | |
2914 | @end deftypefn | |
2915 | ||
2916 | @deftypefn {Target Macro} void VALUE_TO_REGISTER (struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to}) | |
2917 | Convert a data value of type @var{type} to register number @var{reg}' | |
2918 | raw format. | |
2919 | ||
2920 | Note that @code{REGISTER_TO_VALUE} and @code{VALUE_TO_REGISTER} take | |
2921 | their @var{reg} and @var{type} arguments in different orders. | |
2922 | ||
2923 | You should only use @code{VALUE_TO_REGISTER} with registers for which | |
2924 | the @code{CONVERT_REGISTER_P} macro returns a non-zero value. | |
2925 | @end deftypefn | |
2926 | ||
2927 | @deftypefn {Target Macro} void REGISTER_CONVERT_TO_TYPE (int @var{regnum}, struct type *@var{type}, char *@var{buf}) | |
2928 | See @file{mips-tdep.c}. It does not do what you want. | |
2929 | @end deftypefn | |
2930 | ||
2931 | ||
c906108c SS |
2932 | @section Frame Interpretation |
2933 | ||
2934 | @section Inferior Call Setup | |
2935 | ||
2936 | @section Compiler Characteristics | |
2937 | ||
2938 | @section Target Conditionals | |
2939 | ||
2940 | This section describes the macros that you can use to define the target | |
2941 | machine. | |
2942 | ||
2943 | @table @code | |
2944 | ||
c906108c | 2945 | @item ADDR_BITS_REMOVE (addr) |
56caf160 | 2946 | @findex ADDR_BITS_REMOVE |
adf40b2e JM |
2947 | If a raw machine instruction address includes any bits that are not |
2948 | really part of the address, then define this macro to expand into an | |
56caf160 | 2949 | expression that zeroes those bits in @var{addr}. This is only used for |
adf40b2e JM |
2950 | addresses of instructions, and even then not in all contexts. |
2951 | ||
2952 | For example, the two low-order bits of the PC on the Hewlett-Packard PA | |
2953 | 2.0 architecture contain the privilege level of the corresponding | |
2954 | instruction. Since instructions must always be aligned on four-byte | |
2955 | boundaries, the processor masks out these bits to generate the actual | |
2956 | address of the instruction. ADDR_BITS_REMOVE should filter out these | |
2957 | bits with an expression such as @code{((addr) & ~3)}. | |
c906108c | 2958 | |
b5b0480a KB |
2959 | @item ADDRESS_CLASS_NAME_TO_TYPE_FLAGS (@var{name}, @var{type_flags_ptr}) |
2960 | @findex ADDRESS_CLASS_NAME_TO_TYPE_FLAGS | |
2961 | If @var{name} is a valid address class qualifier name, set the @code{int} | |
2962 | referenced by @var{type_flags_ptr} to the mask representing the qualifier | |
2963 | and return 1. If @var{name} is not a valid address class qualifier name, | |
2964 | return 0. | |
2965 | ||
2966 | The value for @var{type_flags_ptr} should be one of | |
2967 | @code{TYPE_FLAG_ADDRESS_CLASS_1}, @code{TYPE_FLAG_ADDRESS_CLASS_2}, or | |
2968 | possibly some combination of these values or'd together. | |
2969 | @xref{Target Architecture Definition, , Address Classes}. | |
2970 | ||
2971 | @item ADDRESS_CLASS_NAME_TO_TYPE_FLAGS_P () | |
2972 | @findex ADDRESS_CLASS_NAME_TO_TYPE_FLAGS_P | |
2973 | Predicate which indicates whether @code{ADDRESS_CLASS_NAME_TO_TYPE_FLAGS} | |
2974 | has been defined. | |
2975 | ||
2976 | @item ADDRESS_CLASS_TYPE_FLAGS (@var{byte_size}, @var{dwarf2_addr_class}) | |
2977 | @findex ADDRESS_CLASS_TYPE_FLAGS (@var{byte_size}, @var{dwarf2_addr_class}) | |
2978 | Given a pointers byte size (as described by the debug information) and | |
2979 | the possible @code{DW_AT_address_class} value, return the type flags | |
2980 | used by @value{GDBN} to represent this address class. The value | |
2981 | returned should be one of @code{TYPE_FLAG_ADDRESS_CLASS_1}, | |
2982 | @code{TYPE_FLAG_ADDRESS_CLASS_2}, or possibly some combination of these | |
2983 | values or'd together. | |
2984 | @xref{Target Architecture Definition, , Address Classes}. | |
2985 | ||
2986 | @item ADDRESS_CLASS_TYPE_FLAGS_P () | |
2987 | @findex ADDRESS_CLASS_TYPE_FLAGS_P | |
2988 | Predicate which indicates whether @code{ADDRESS_CLASS_TYPE_FLAGS} has | |
2989 | been defined. | |
2990 | ||
2991 | @item ADDRESS_CLASS_TYPE_FLAGS_TO_NAME (@var{type_flags}) | |
2992 | @findex ADDRESS_CLASS_TYPE_FLAGS_TO_NAME | |
2993 | Return the name of the address class qualifier associated with the type | |
2994 | flags given by @var{type_flags}. | |
2995 | ||
2996 | @item ADDRESS_CLASS_TYPE_FLAGS_TO_NAME_P () | |
2997 | @findex ADDRESS_CLASS_TYPE_FLAGS_TO_NAME_P | |
2998 | Predicate which indicates whether @code{ADDRESS_CLASS_TYPE_FLAGS_TO_NAME} has | |
2999 | been defined. | |
3000 | @xref{Target Architecture Definition, , Address Classes}. | |
3001 | ||
93e79dbd | 3002 | @item ADDRESS_TO_POINTER (@var{type}, @var{buf}, @var{addr}) |
56caf160 | 3003 | @findex ADDRESS_TO_POINTER |
93e79dbd JB |
3004 | Store in @var{buf} a pointer of type @var{type} representing the address |
3005 | @var{addr}, in the appropriate format for the current architecture. | |
3006 | This macro may safely assume that @var{type} is either a pointer or a | |
56caf160 | 3007 | C@t{++} reference type. |
93e79dbd JB |
3008 | @xref{Target Architecture Definition, , Pointers Are Not Always Addresses}. |
3009 | ||
c906108c | 3010 | @item BELIEVE_PCC_PROMOTION |
56caf160 EZ |
3011 | @findex BELIEVE_PCC_PROMOTION |
3012 | Define if the compiler promotes a @code{short} or @code{char} | |
3013 | parameter to an @code{int}, but still reports the parameter as its | |
3014 | original type, rather than the promoted type. | |
c906108c | 3015 | |
c906108c | 3016 | @item BITS_BIG_ENDIAN |
56caf160 EZ |
3017 | @findex BITS_BIG_ENDIAN |
3018 | Define this if the numbering of bits in the targets does @strong{not} match the | |
c906108c | 3019 | endianness of the target byte order. A value of 1 means that the bits |
56caf160 | 3020 | are numbered in a big-endian bit order, 0 means little-endian. |
c906108c SS |
3021 | |
3022 | @item BREAKPOINT | |
56caf160 | 3023 | @findex BREAKPOINT |
c906108c SS |
3024 | This is the character array initializer for the bit pattern to put into |
3025 | memory where a breakpoint is set. Although it's common to use a trap | |
3026 | instruction for a breakpoint, it's not required; for instance, the bit | |
3027 | pattern could be an invalid instruction. The breakpoint must be no | |
3028 | longer than the shortest instruction of the architecture. | |
3029 | ||
56caf160 EZ |
3030 | @code{BREAKPOINT} has been deprecated in favor of |
3031 | @code{BREAKPOINT_FROM_PC}. | |
7a292a7a | 3032 | |
c906108c | 3033 | @item BIG_BREAKPOINT |
56caf160 EZ |
3034 | @itemx LITTLE_BREAKPOINT |
3035 | @findex LITTLE_BREAKPOINT | |
3036 | @findex BIG_BREAKPOINT | |
c906108c SS |
3037 | Similar to BREAKPOINT, but used for bi-endian targets. |
3038 | ||
56caf160 EZ |
3039 | @code{BIG_BREAKPOINT} and @code{LITTLE_BREAKPOINT} have been deprecated in |
3040 | favor of @code{BREAKPOINT_FROM_PC}. | |
7a292a7a | 3041 | |
2dd0da42 AC |
3042 | @item DEPRECATED_REMOTE_BREAKPOINT |
3043 | @itemx DEPRECATED_LITTLE_REMOTE_BREAKPOINT | |
3044 | @itemx DEPRECATED_BIG_REMOTE_BREAKPOINT | |
3045 | @findex DEPRECATED_BIG_REMOTE_BREAKPOINT | |
3046 | @findex DEPRECATED_LITTLE_REMOTE_BREAKPOINT | |
3047 | @findex DEPRECATED_REMOTE_BREAKPOINT | |
3048 | Specify the breakpoint instruction sequence for a remote target. | |
3049 | @code{DEPRECATED_REMOTE_BREAKPOINT}, | |
3050 | @code{DEPRECATED_BIG_REMOTE_BREAKPOINT} and | |
3051 | @code{DEPRECATED_LITTLE_REMOTE_BREAKPOINT} have been deprecated in | |
3052 | favor of @code{BREAKPOINT_FROM_PC} (@pxref{BREAKPOINT_FROM_PC}). | |
c906108c | 3053 | |
56caf160 EZ |
3054 | @item BREAKPOINT_FROM_PC (@var{pcptr}, @var{lenptr}) |
3055 | @findex BREAKPOINT_FROM_PC | |
2dd0da42 AC |
3056 | @anchor{BREAKPOINT_FROM_PC} Use the program counter to determine the |
3057 | contents and size of a breakpoint instruction. It returns a pointer to | |
3058 | a string of bytes that encode a breakpoint instruction, stores the | |
3059 | length of the string to @code{*@var{lenptr}}, and adjusts the program | |
3060 | counter (if necessary) to point to the actual memory location where the | |
3061 | breakpoint should be inserted. | |
c906108c SS |
3062 | |
3063 | Although it is common to use a trap instruction for a breakpoint, it's | |
3064 | not required; for instance, the bit pattern could be an invalid | |
3065 | instruction. The breakpoint must be no longer than the shortest | |
3066 | instruction of the architecture. | |
3067 | ||
7a292a7a SS |
3068 | Replaces all the other @var{BREAKPOINT} macros. |
3069 | ||
56caf160 EZ |
3070 | @item MEMORY_INSERT_BREAKPOINT (@var{addr}, @var{contents_cache}) |
3071 | @itemx MEMORY_REMOVE_BREAKPOINT (@var{addr}, @var{contents_cache}) | |
3072 | @findex MEMORY_REMOVE_BREAKPOINT | |
3073 | @findex MEMORY_INSERT_BREAKPOINT | |
917317f4 JM |
3074 | Insert or remove memory based breakpoints. Reasonable defaults |
3075 | (@code{default_memory_insert_breakpoint} and | |
3076 | @code{default_memory_remove_breakpoint} respectively) have been | |
3077 | provided so that it is not necessary to define these for most | |
3078 | architectures. Architectures which may want to define | |
56caf160 | 3079 | @code{MEMORY_INSERT_BREAKPOINT} and @code{MEMORY_REMOVE_BREAKPOINT} will |
917317f4 JM |
3080 | likely have instructions that are oddly sized or are not stored in a |
3081 | conventional manner. | |
3082 | ||
3083 | It may also be desirable (from an efficiency standpoint) to define | |
3084 | custom breakpoint insertion and removal routines if | |
56caf160 | 3085 | @code{BREAKPOINT_FROM_PC} needs to read the target's memory for some |
917317f4 JM |
3086 | reason. |
3087 | ||
1485d690 KB |
3088 | @item ADJUST_BREAKPOINT_ADDRESS (@var{address}) |
3089 | @findex ADJUST_BREAKPOINT_ADDRESS | |
3090 | @cindex breakpoint address adjusted | |
3091 | Given an address at which a breakpoint is desired, return a breakpoint | |
3092 | address adjusted to account for architectural constraints on | |
3093 | breakpoint placement. This method is not needed by most targets. | |
3094 | ||
3095 | The FR-V target (see @file{frv-tdep.c}) requires this method. | |
3096 | The FR-V is a VLIW architecture in which a number of RISC-like | |
3097 | instructions are grouped (packed) together into an aggregate | |
3098 | instruction or instruction bundle. When the processor executes | |
3099 | one of these bundles, the component instructions are executed | |
3100 | in parallel. | |
3101 | ||
3102 | In the course of optimization, the compiler may group instructions | |
3103 | from distinct source statements into the same bundle. The line number | |
3104 | information associated with one of the latter statements will likely | |
3105 | refer to some instruction other than the first one in the bundle. So, | |
3106 | if the user attempts to place a breakpoint on one of these latter | |
3107 | statements, @value{GDBN} must be careful to @emph{not} place the break | |
3108 | instruction on any instruction other than the first one in the bundle. | |
3109 | (Remember though that the instructions within a bundle execute | |
3110 | in parallel, so the @emph{first} instruction is the instruction | |
3111 | at the lowest address and has nothing to do with execution order.) | |
3112 | ||
3113 | The FR-V's @code{ADJUST_BREAKPOINT_ADDRESS} method will adjust a | |
3114 | breakpoint's address by scanning backwards for the beginning of | |
3115 | the bundle, returning the address of the bundle. | |
3116 | ||
3117 | Since the adjustment of a breakpoint may significantly alter a user's | |
3118 | expectation, @value{GDBN} prints a warning when an adjusted breakpoint | |
3119 | is initially set and each time that that breakpoint is hit. | |
3120 | ||
c906108c | 3121 | @item CALL_DUMMY_LOCATION |
56caf160 EZ |
3122 | @findex CALL_DUMMY_LOCATION |
3123 | See the file @file{inferior.h}. | |
7a292a7a | 3124 | |
7043d8dc AC |
3125 | This method has been replaced by @code{push_dummy_code} |
3126 | (@pxref{push_dummy_code}). | |
3127 | ||
56caf160 EZ |
3128 | @item CANNOT_FETCH_REGISTER (@var{regno}) |
3129 | @findex CANNOT_FETCH_REGISTER | |
c906108c SS |
3130 | A C expression that should be nonzero if @var{regno} cannot be fetched |
3131 | from an inferior process. This is only relevant if | |
3132 | @code{FETCH_INFERIOR_REGISTERS} is not defined. | |
3133 | ||
56caf160 EZ |
3134 | @item CANNOT_STORE_REGISTER (@var{regno}) |
3135 | @findex CANNOT_STORE_REGISTER | |
c906108c SS |
3136 | A C expression that should be nonzero if @var{regno} should not be |
3137 | written to the target. This is often the case for program counters, | |
56caf160 EZ |
3138 | status words, and other special registers. If this is not defined, |
3139 | @value{GDBN} will assume that all registers may be written. | |
c906108c | 3140 | |
13d01224 AC |
3141 | @item int CONVERT_REGISTER_P(@var{regnum}) |
3142 | @findex CONVERT_REGISTER_P | |
3143 | Return non-zero if register @var{regnum} can represent data values in a | |
3144 | non-standard form. | |
3145 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. | |
3146 | ||
c906108c | 3147 | @item DECR_PC_AFTER_BREAK |
56caf160 | 3148 | @findex DECR_PC_AFTER_BREAK |
c906108c SS |
3149 | Define this to be the amount by which to decrement the PC after the |
3150 | program encounters a breakpoint. This is often the number of bytes in | |
56caf160 | 3151 | @code{BREAKPOINT}, though not always. For most targets this value will be 0. |
c906108c | 3152 | |
56caf160 EZ |
3153 | @item DISABLE_UNSETTABLE_BREAK (@var{addr}) |
3154 | @findex DISABLE_UNSETTABLE_BREAK | |
c906108c SS |
3155 | If defined, this should evaluate to 1 if @var{addr} is in a shared |
3156 | library in which breakpoints cannot be set and so should be disabled. | |
3157 | ||
5e74b15c | 3158 | @item PRINT_FLOAT_INFO() |
0ab7a791 | 3159 | @findex PRINT_FLOAT_INFO |
5e74b15c RE |
3160 | If defined, then the @samp{info float} command will print information about |
3161 | the processor's floating point unit. | |
3162 | ||
0ab7a791 AC |
3163 | @item print_registers_info (@var{gdbarch}, @var{frame}, @var{regnum}, @var{all}) |
3164 | @findex print_registers_info | |
3165 | If defined, pretty print the value of the register @var{regnum} for the | |
3166 | specified @var{frame}. If the value of @var{regnum} is -1, pretty print | |
3167 | either all registers (@var{all} is non zero) or a select subset of | |
3168 | registers (@var{all} is zero). | |
3169 | ||
3170 | The default method prints one register per line, and if @var{all} is | |
3171 | zero omits floating-point registers. | |
3172 | ||
e76f1f2e AC |
3173 | @item PRINT_VECTOR_INFO() |
3174 | @findex PRINT_VECTOR_INFO | |
3175 | If defined, then the @samp{info vector} command will call this function | |
3176 | to print information about the processor's vector unit. | |
3177 | ||
3178 | By default, the @samp{info vector} command will print all vector | |
3179 | registers (the register's type having the vector attribute). | |
3180 | ||
0dcedd82 | 3181 | @item DWARF_REG_TO_REGNUM |
56caf160 | 3182 | @findex DWARF_REG_TO_REGNUM |
0dcedd82 AC |
3183 | Convert DWARF register number into @value{GDBN} regnum. If not defined, |
3184 | no conversion will be performed. | |
3185 | ||
3186 | @item DWARF2_REG_TO_REGNUM | |
56caf160 | 3187 | @findex DWARF2_REG_TO_REGNUM |
0dcedd82 AC |
3188 | Convert DWARF2 register number into @value{GDBN} regnum. If not |
3189 | defined, no conversion will be performed. | |
3190 | ||
3191 | @item ECOFF_REG_TO_REGNUM | |
56caf160 | 3192 | @findex ECOFF_REG_TO_REGNUM |
0dcedd82 AC |
3193 | Convert ECOFF register number into @value{GDBN} regnum. If not defined, |
3194 | no conversion will be performed. | |
3195 | ||
c906108c | 3196 | @item END_OF_TEXT_DEFAULT |
56caf160 EZ |
3197 | @findex END_OF_TEXT_DEFAULT |
3198 | This is an expression that should designate the end of the text section. | |
3199 | @c (? FIXME ?) | |
c906108c | 3200 | |
56caf160 EZ |
3201 | @item EXTRACT_RETURN_VALUE(@var{type}, @var{regbuf}, @var{valbuf}) |
3202 | @findex EXTRACT_RETURN_VALUE | |
c906108c SS |
3203 | Define this to extract a function's return value of type @var{type} from |
3204 | the raw register state @var{regbuf} and copy that, in virtual format, | |
3205 | into @var{valbuf}. | |
3206 | ||
92ad9cd9 AC |
3207 | This method has been deprecated in favour of @code{gdbarch_return_value} |
3208 | (@pxref{gdbarch_return_value}). | |
3209 | ||
74055713 AC |
3210 | @item DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS(@var{regbuf}) |
3211 | @findex DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS | |
3212 | @anchor{DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS} | |
83aa8bc6 AC |
3213 | When defined, extract from the array @var{regbuf} (containing the raw |
3214 | register state) the @code{CORE_ADDR} at which a function should return | |
3215 | its structure value. | |
ac9a91a7 | 3216 | |
92ad9cd9 | 3217 | @xref{gdbarch_return_value}. |
83aa8bc6 | 3218 | |
74055713 AC |
3219 | @item DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS_P() |
3220 | @findex DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS_P | |
3221 | Predicate for @code{DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS}. | |
c906108c | 3222 | |
0ba6dca9 AC |
3223 | @item DEPRECATED_FP_REGNUM |
3224 | @findex DEPRECATED_FP_REGNUM | |
cce74817 JM |
3225 | If the virtual frame pointer is kept in a register, then define this |
3226 | macro to be the number (greater than or equal to zero) of that register. | |
3227 | ||
0ba6dca9 AC |
3228 | This should only need to be defined if @code{DEPRECATED_TARGET_READ_FP} |
3229 | is not defined. | |
c906108c | 3230 | |
19772a2c AC |
3231 | @item DEPRECATED_FRAMELESS_FUNCTION_INVOCATION(@var{fi}) |
3232 | @findex DEPRECATED_FRAMELESS_FUNCTION_INVOCATION | |
392a587b JM |
3233 | Define this to an expression that returns 1 if the function invocation |
3234 | represented by @var{fi} does not have a stack frame associated with it. | |
3235 | Otherwise return 0. | |
c906108c | 3236 | |
790eb8f5 AC |
3237 | @item frame_align (@var{address}) |
3238 | @anchor{frame_align} | |
3239 | @findex frame_align | |
3240 | Define this to adjust @var{address} so that it meets the alignment | |
3241 | requirements for the start of a new stack frame. A stack frame's | |
3242 | alignment requirements are typically stronger than a target processors | |
f27dd7fd | 3243 | stack alignment requirements (@pxref{DEPRECATED_STACK_ALIGN}). |
790eb8f5 AC |
3244 | |
3245 | This function is used to ensure that, when creating a dummy frame, both | |
3246 | the initial stack pointer and (if needed) the address of the return | |
3247 | value are correctly aligned. | |
3248 | ||
f27dd7fd AC |
3249 | Unlike @code{DEPRECATED_STACK_ALIGN}, this function always adjusts the |
3250 | address in the direction of stack growth. | |
790eb8f5 AC |
3251 | |
3252 | By default, no frame based stack alignment is performed. | |
3253 | ||
8b148df9 AC |
3254 | @item int frame_red_zone_size |
3255 | ||
3256 | The number of bytes, beyond the innermost-stack-address, reserved by the | |
3257 | @sc{abi}. A function is permitted to use this scratch area (instead of | |
3258 | allocating extra stack space). | |
3259 | ||
3260 | When performing an inferior function call, to ensure that it does not | |
3261 | modify this area, @value{GDBN} adjusts the innermost-stack-address by | |
3262 | @var{frame_red_zone_size} bytes before pushing parameters onto the | |
3263 | stack. | |
3264 | ||
3265 | By default, zero bytes are allocated. The value must be aligned | |
3266 | (@pxref{frame_align}). | |
3267 | ||
3268 | The @sc{amd64} (nee x86-64) @sc{abi} documentation refers to the | |
3269 | @emph{red zone} when describing this scratch area. | |
3270 | @cindex red zone | |
3271 | ||
618ce49f AC |
3272 | @item DEPRECATED_FRAME_CHAIN(@var{frame}) |
3273 | @findex DEPRECATED_FRAME_CHAIN | |
c906108c SS |
3274 | Given @var{frame}, return a pointer to the calling frame. |
3275 | ||
618ce49f AC |
3276 | @item DEPRECATED_FRAME_CHAIN_VALID(@var{chain}, @var{thisframe}) |
3277 | @findex DEPRECATED_FRAME_CHAIN_VALID | |
95f90d25 DJ |
3278 | Define this to be an expression that returns zero if the given frame is an |
3279 | outermost frame, with no caller, and nonzero otherwise. Most normal | |
3280 | situations can be handled without defining this macro, including @code{NULL} | |
3281 | chain pointers, dummy frames, and frames whose PC values are inside the | |
3282 | startup file (e.g.@: @file{crt0.o}), inside @code{main}, or inside | |
3283 | @code{_start}. | |
c906108c | 3284 | |
f30ee0bc AC |
3285 | @item DEPRECATED_FRAME_INIT_SAVED_REGS(@var{frame}) |
3286 | @findex DEPRECATED_FRAME_INIT_SAVED_REGS | |
c906108c SS |
3287 | See @file{frame.h}. Determines the address of all registers in the |
3288 | current stack frame storing each in @code{frame->saved_regs}. Space for | |
3289 | @code{frame->saved_regs} shall be allocated by | |
f30ee0bc AC |
3290 | @code{DEPRECATED_FRAME_INIT_SAVED_REGS} using |
3291 | @code{frame_saved_regs_zalloc}. | |
c906108c | 3292 | |
fb8f8949 | 3293 | @code{FRAME_FIND_SAVED_REGS} is deprecated. |
c906108c | 3294 | |
56caf160 EZ |
3295 | @item FRAME_NUM_ARGS (@var{fi}) |
3296 | @findex FRAME_NUM_ARGS | |
392a587b JM |
3297 | For the frame described by @var{fi} return the number of arguments that |
3298 | are being passed. If the number of arguments is not known, return | |
3299 | @code{-1}. | |
c906108c | 3300 | |
8bedc050 AC |
3301 | @item DEPRECATED_FRAME_SAVED_PC(@var{frame}) |
3302 | @findex DEPRECATED_FRAME_SAVED_PC | |
3303 | @anchor{DEPRECATED_FRAME_SAVED_PC} Given @var{frame}, return the pc | |
3304 | saved there. This is the return address. | |
12cc2063 AC |
3305 | |
3306 | This method is deprecated. @xref{unwind_pc}. | |
3307 | ||
3308 | @item CORE_ADDR unwind_pc (struct frame_info *@var{this_frame}) | |
3309 | @findex unwind_pc | |
3310 | @anchor{unwind_pc} Return the instruction address, in @var{this_frame}'s | |
3311 | caller, at which execution will resume after @var{this_frame} returns. | |
3312 | This is commonly refered to as the return address. | |
3313 | ||
3314 | The implementation, which must be frame agnostic (work with any frame), | |
3315 | is typically no more than: | |
3316 | ||
3317 | @smallexample | |
3318 | ULONGEST pc; | |
3319 | frame_unwind_unsigned_register (this_frame, D10V_PC_REGNUM, &pc); | |
3320 | return d10v_make_iaddr (pc); | |
3321 | @end smallexample | |
3322 | ||
3323 | @noindent | |
8bedc050 | 3324 | @xref{DEPRECATED_FRAME_SAVED_PC}, which this method replaces. |
c906108c | 3325 | |
a9e5fdc2 AC |
3326 | @item CORE_ADDR unwind_sp (struct frame_info *@var{this_frame}) |
3327 | @findex unwind_sp | |
3328 | @anchor{unwind_sp} Return the frame's inner most stack address. This is | |
3329 | commonly refered to as the frame's @dfn{stack pointer}. | |
3330 | ||
3331 | The implementation, which must be frame agnostic (work with any frame), | |
3332 | is typically no more than: | |
3333 | ||
3334 | @smallexample | |
3335 | ULONGEST sp; | |
3336 | frame_unwind_unsigned_register (this_frame, D10V_SP_REGNUM, &sp); | |
3337 | return d10v_make_daddr (sp); | |
3338 | @end smallexample | |
3339 | ||
3340 | @noindent | |
3341 | @xref{TARGET_READ_SP}, which this method replaces. | |
3342 | ||
c906108c | 3343 | @item FUNCTION_EPILOGUE_SIZE |
56caf160 | 3344 | @findex FUNCTION_EPILOGUE_SIZE |
c906108c SS |
3345 | For some COFF targets, the @code{x_sym.x_misc.x_fsize} field of the |
3346 | function end symbol is 0. For such targets, you must define | |
3347 | @code{FUNCTION_EPILOGUE_SIZE} to expand into the standard size of a | |
3348 | function's epilogue. | |
3349 | ||
782263ab AC |
3350 | @item DEPRECATED_FUNCTION_START_OFFSET |
3351 | @findex DEPRECATED_FUNCTION_START_OFFSET | |
f7cb2b90 JB |
3352 | An integer, giving the offset in bytes from a function's address (as |
3353 | used in the values of symbols, function pointers, etc.), and the | |
3354 | function's first genuine instruction. | |
3355 | ||
3356 | This is zero on almost all machines: the function's address is usually | |
782263ab AC |
3357 | the address of its first instruction. However, on the VAX, for |
3358 | example, each function starts with two bytes containing a bitmask | |
3359 | indicating which registers to save upon entry to the function. The | |
3360 | VAX @code{call} instructions check this value, and save the | |
3361 | appropriate registers automatically. Thus, since the offset from the | |
3362 | function's address to its first instruction is two bytes, | |
3363 | @code{DEPRECATED_FUNCTION_START_OFFSET} would be 2 on the VAX. | |
f7cb2b90 | 3364 | |
c906108c | 3365 | @item GCC_COMPILED_FLAG_SYMBOL |
56caf160 EZ |
3366 | @itemx GCC2_COMPILED_FLAG_SYMBOL |
3367 | @findex GCC2_COMPILED_FLAG_SYMBOL | |
3368 | @findex GCC_COMPILED_FLAG_SYMBOL | |
3369 | If defined, these are the names of the symbols that @value{GDBN} will | |
3370 | look for to detect that GCC compiled the file. The default symbols | |
3371 | are @code{gcc_compiled.} and @code{gcc2_compiled.}, | |
3372 | respectively. (Currently only defined for the Delta 68.) | |
c906108c | 3373 | |
25822942 | 3374 | @item @value{GDBN}_MULTI_ARCH |
56caf160 | 3375 | @findex @value{GDBN}_MULTI_ARCH |
937f164b | 3376 | If defined and non-zero, enables support for multiple architectures |
25822942 | 3377 | within @value{GDBN}. |
0f71a2f6 | 3378 | |
56caf160 | 3379 | This support can be enabled at two levels. At level one, only |
0f71a2f6 | 3380 | definitions for previously undefined macros are provided; at level two, |
937f164b | 3381 | a multi-arch definition of all architecture dependent macros will be |
0f71a2f6 JM |
3382 | defined. |
3383 | ||
25822942 | 3384 | @item @value{GDBN}_TARGET_IS_HPPA |
56caf160 EZ |
3385 | @findex @value{GDBN}_TARGET_IS_HPPA |
3386 | This determines whether horrible kludge code in @file{dbxread.c} and | |
3387 | @file{partial-stab.h} is used to mangle multiple-symbol-table files from | |
3388 | HPPA's. This should all be ripped out, and a scheme like @file{elfread.c} | |
3389 | used instead. | |
c906108c | 3390 | |
c906108c | 3391 | @item GET_LONGJMP_TARGET |
56caf160 | 3392 | @findex GET_LONGJMP_TARGET |
c906108c SS |
3393 | For most machines, this is a target-dependent parameter. On the |
3394 | DECstation and the Iris, this is a native-dependent parameter, since | |
937f164b | 3395 | the header file @file{setjmp.h} is needed to define it. |
c906108c | 3396 | |
56caf160 EZ |
3397 | This macro determines the target PC address that @code{longjmp} will jump to, |
3398 | assuming that we have just stopped at a @code{longjmp} breakpoint. It takes a | |
3399 | @code{CORE_ADDR *} as argument, and stores the target PC value through this | |
c906108c SS |
3400 | pointer. It examines the current state of the machine as needed. |
3401 | ||
ac2adee5 AC |
3402 | @item DEPRECATED_GET_SAVED_REGISTER |
3403 | @findex DEPRECATED_GET_SAVED_REGISTER | |
c906108c | 3404 | Define this if you need to supply your own definition for the function |
ac2adee5 | 3405 | @code{DEPRECATED_GET_SAVED_REGISTER}. |
c906108c | 3406 | |
268e2188 AC |
3407 | @item DEPRECATED_IBM6000_TARGET |
3408 | @findex DEPRECATED_IBM6000_TARGET | |
3409 | Shows that we are configured for an IBM RS/6000 system. This | |
c906108c | 3410 | conditional should be eliminated (FIXME) and replaced by |
56caf160 | 3411 | feature-specific macros. It was introduced in a haste and we are |
c906108c SS |
3412 | repenting at leisure. |
3413 | ||
9742079a EZ |
3414 | @item I386_USE_GENERIC_WATCHPOINTS |
3415 | An x86-based target can define this to use the generic x86 watchpoint | |
3416 | support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}. | |
3417 | ||
2df3850c | 3418 | @item SYMBOLS_CAN_START_WITH_DOLLAR |
56caf160 | 3419 | @findex SYMBOLS_CAN_START_WITH_DOLLAR |
2df3850c | 3420 | Some systems have routines whose names start with @samp{$}. Giving this |
25822942 | 3421 | macro a non-zero value tells @value{GDBN}'s expression parser to check for such |
2df3850c JM |
3422 | routines when parsing tokens that begin with @samp{$}. |
3423 | ||
3424 | On HP-UX, certain system routines (millicode) have names beginning with | |
3425 | @samp{$} or @samp{$$}. For example, @code{$$dyncall} is a millicode | |
3426 | routine that handles inter-space procedure calls on PA-RISC. | |
3427 | ||
e9582e71 AC |
3428 | @item DEPRECATED_INIT_EXTRA_FRAME_INFO (@var{fromleaf}, @var{frame}) |
3429 | @findex DEPRECATED_INIT_EXTRA_FRAME_INFO | |
c906108c SS |
3430 | If additional information about the frame is required this should be |
3431 | stored in @code{frame->extra_info}. Space for @code{frame->extra_info} | |
372613e3 | 3432 | is allocated using @code{frame_extra_info_zalloc}. |
c906108c | 3433 | |
a5afb99f AC |
3434 | @item DEPRECATED_INIT_FRAME_PC (@var{fromleaf}, @var{prev}) |
3435 | @findex DEPRECATED_INIT_FRAME_PC | |
c906108c SS |
3436 | This is a C statement that sets the pc of the frame pointed to by |
3437 | @var{prev}. [By default...] | |
3438 | ||
56caf160 EZ |
3439 | @item INNER_THAN (@var{lhs}, @var{rhs}) |
3440 | @findex INNER_THAN | |
c906108c SS |
3441 | Returns non-zero if stack address @var{lhs} is inner than (nearer to the |
3442 | stack top) stack address @var{rhs}. Define this as @code{lhs < rhs} if | |
3443 | the target's stack grows downward in memory, or @code{lhs > rsh} if the | |
3444 | stack grows upward. | |
3445 | ||
9e5abb06 CV |
3446 | @item gdbarch_in_function_epilogue_p (@var{gdbarch}, @var{pc}) |
3447 | @findex gdbarch_in_function_epilogue_p | |
3448 | Returns non-zero if the given @var{pc} is in the epilogue of a function. | |
3449 | The epilogue of a function is defined as the part of a function where | |
3450 | the stack frame of the function already has been destroyed up to the | |
3451 | final `return from function call' instruction. | |
3452 | ||
aa2a3f87 AC |
3453 | @item DEPRECATED_SIGTRAMP_START (@var{pc}) |
3454 | @findex DEPRECATED_SIGTRAMP_START | |
3455 | @itemx DEPRECATED_SIGTRAMP_END (@var{pc}) | |
3456 | @findex DEPRECATED_SIGTRAMP_END | |
56caf160 | 3457 | Define these to be the start and end address of the @code{sigtramp} for the |
c906108c SS |
3458 | given @var{pc}. On machines where the address is just a compile time |
3459 | constant, the macro expansion will typically just ignore the supplied | |
3460 | @var{pc}. | |
3461 | ||
56caf160 EZ |
3462 | @item IN_SOLIB_CALL_TRAMPOLINE (@var{pc}, @var{name}) |
3463 | @findex IN_SOLIB_CALL_TRAMPOLINE | |
c906108c SS |
3464 | Define this to evaluate to nonzero if the program is stopped in the |
3465 | trampoline that connects to a shared library. | |
3466 | ||
56caf160 EZ |
3467 | @item IN_SOLIB_RETURN_TRAMPOLINE (@var{pc}, @var{name}) |
3468 | @findex IN_SOLIB_RETURN_TRAMPOLINE | |
c906108c SS |
3469 | Define this to evaluate to nonzero if the program is stopped in the |
3470 | trampoline that returns from a shared library. | |
3471 | ||
56caf160 EZ |
3472 | @item IN_SOLIB_DYNSYM_RESOLVE_CODE (@var{pc}) |
3473 | @findex IN_SOLIB_DYNSYM_RESOLVE_CODE | |
d4f3574e SS |
3474 | Define this to evaluate to nonzero if the program is stopped in the |
3475 | dynamic linker. | |
3476 | ||
56caf160 EZ |
3477 | @item SKIP_SOLIB_RESOLVER (@var{pc}) |
3478 | @findex SKIP_SOLIB_RESOLVER | |
d4f3574e SS |
3479 | Define this to evaluate to the (nonzero) address at which execution |
3480 | should continue to get past the dynamic linker's symbol resolution | |
3481 | function. A zero value indicates that it is not important or necessary | |
3482 | to set a breakpoint to get through the dynamic linker and that single | |
3483 | stepping will suffice. | |
3484 | ||
fc0c74b1 AC |
3485 | @item INTEGER_TO_ADDRESS (@var{type}, @var{buf}) |
3486 | @findex INTEGER_TO_ADDRESS | |
3487 | @cindex converting integers to addresses | |
3488 | Define this when the architecture needs to handle non-pointer to address | |
3489 | conversions specially. Converts that value to an address according to | |
3490 | the current architectures conventions. | |
3491 | ||
3492 | @emph{Pragmatics: When the user copies a well defined expression from | |
3493 | their source code and passes it, as a parameter, to @value{GDBN}'s | |
3494 | @code{print} command, they should get the same value as would have been | |
3495 | computed by the target program. Any deviation from this rule can cause | |
3496 | major confusion and annoyance, and needs to be justified carefully. In | |
3497 | other words, @value{GDBN} doesn't really have the freedom to do these | |
3498 | conversions in clever and useful ways. It has, however, been pointed | |
3499 | out that users aren't complaining about how @value{GDBN} casts integers | |
3500 | to pointers; they are complaining that they can't take an address from a | |
3501 | disassembly listing and give it to @code{x/i}. Adding an architecture | |
3502 | method like @code{INTEGER_TO_ADDRESS} certainly makes it possible for | |
3503 | @value{GDBN} to ``get it right'' in all circumstances.} | |
3504 | ||
3505 | @xref{Target Architecture Definition, , Pointers Are Not Always | |
3506 | Addresses}. | |
3507 | ||
c906108c | 3508 | @item NO_HIF_SUPPORT |
56caf160 | 3509 | @findex NO_HIF_SUPPORT |
c906108c SS |
3510 | (Specific to the a29k.) |
3511 | ||
93e79dbd | 3512 | @item POINTER_TO_ADDRESS (@var{type}, @var{buf}) |
56caf160 | 3513 | @findex POINTER_TO_ADDRESS |
93e79dbd JB |
3514 | Assume that @var{buf} holds a pointer of type @var{type}, in the |
3515 | appropriate format for the current architecture. Return the byte | |
3516 | address the pointer refers to. | |
3517 | @xref{Target Architecture Definition, , Pointers Are Not Always Addresses}. | |
3518 | ||
9fb4dd36 | 3519 | @item REGISTER_CONVERTIBLE (@var{reg}) |
56caf160 | 3520 | @findex REGISTER_CONVERTIBLE |
9fb4dd36 | 3521 | Return non-zero if @var{reg} uses different raw and virtual formats. |
13d01224 AC |
3522 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
3523 | ||
3524 | @item REGISTER_TO_VALUE(@var{regnum}, @var{type}, @var{from}, @var{to}) | |
3525 | @findex REGISTER_TO_VALUE | |
3526 | Convert the raw contents of register @var{regnum} into a value of type | |
3527 | @var{type}. | |
4281a42e | 3528 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
9fb4dd36 | 3529 | |
12c266ea AC |
3530 | @item DEPRECATED_REGISTER_RAW_SIZE (@var{reg}) |
3531 | @findex DEPRECATED_REGISTER_RAW_SIZE | |
b2e75d78 AC |
3532 | Return the raw size of @var{reg}; defaults to the size of the register's |
3533 | virtual type. | |
13d01224 | 3534 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
9fb4dd36 | 3535 | |
617073a9 AC |
3536 | @item register_reggroup_p (@var{gdbarch}, @var{regnum}, @var{reggroup}) |
3537 | @findex register_reggroup_p | |
3538 | @cindex register groups | |
3539 | Return non-zero if register @var{regnum} is a member of the register | |
3540 | group @var{reggroup}. | |
3541 | ||
3542 | By default, registers are grouped as follows: | |
3543 | ||
3544 | @table @code | |
3545 | @item float_reggroup | |
3546 | Any register with a valid name and a floating-point type. | |
3547 | @item vector_reggroup | |
3548 | Any register with a valid name and a vector type. | |
3549 | @item general_reggroup | |
3550 | Any register with a valid name and a type other than vector or | |
3551 | floating-point. @samp{float_reggroup}. | |
3552 | @item save_reggroup | |
3553 | @itemx restore_reggroup | |
3554 | @itemx all_reggroup | |
3555 | Any register with a valid name. | |
3556 | @end table | |
3557 | ||
f30992d4 AC |
3558 | @item DEPRECATED_REGISTER_VIRTUAL_SIZE (@var{reg}) |
3559 | @findex DEPRECATED_REGISTER_VIRTUAL_SIZE | |
b2e75d78 AC |
3560 | Return the virtual size of @var{reg}; defaults to the size of the |
3561 | register's virtual type. | |
13d01224 AC |
3562 | Return the virtual size of @var{reg}. |
3563 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. | |
9fb4dd36 | 3564 | |
2e092625 | 3565 | @item DEPRECATED_REGISTER_VIRTUAL_TYPE (@var{reg}) |
56caf160 | 3566 | @findex REGISTER_VIRTUAL_TYPE |
9fb4dd36 | 3567 | Return the virtual type of @var{reg}. |
13d01224 | 3568 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
9fb4dd36 | 3569 | |
77e7e267 AC |
3570 | @item struct type *register_type (@var{gdbarch}, @var{reg}) |
3571 | @findex register_type | |
3572 | If defined, return the type of register @var{reg}. This function | |
2e092625 | 3573 | superseeds @code{DEPRECATED_REGISTER_VIRTUAL_TYPE}. @xref{Target Architecture |
77e7e267 AC |
3574 | Definition, , Raw and Virtual Register Representations}. |
3575 | ||
9fb4dd36 | 3576 | @item REGISTER_CONVERT_TO_VIRTUAL(@var{reg}, @var{type}, @var{from}, @var{to}) |
56caf160 | 3577 | @findex REGISTER_CONVERT_TO_VIRTUAL |
9fb4dd36 | 3578 | Convert the value of register @var{reg} from its raw form to its virtual |
4281a42e | 3579 | form. |
13d01224 | 3580 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
9fb4dd36 JB |
3581 | |
3582 | @item REGISTER_CONVERT_TO_RAW(@var{type}, @var{reg}, @var{from}, @var{to}) | |
56caf160 | 3583 | @findex REGISTER_CONVERT_TO_RAW |
9fb4dd36 | 3584 | Convert the value of register @var{reg} from its virtual form to its raw |
4281a42e | 3585 | form. |
13d01224 | 3586 | @xref{Target Architecture Definition, , Raw and Virtual Register Representations}. |
9fb4dd36 | 3587 | |
0ab4b752 MK |
3588 | @item const struct regset *regset_from_core_section (struct gdbarch * @var{gdbarch}, const char * @var{sect_name}, size_t @var{sect_size}) |
3589 | @findex regset_from_core_section | |
3590 | Return the appropriate register set for a core file section with name | |
3591 | @var{sect_name} and size @var{sect_size}. | |
3592 | ||
b0ed3589 | 3593 | @item SOFTWARE_SINGLE_STEP_P() |
56caf160 | 3594 | @findex SOFTWARE_SINGLE_STEP_P |
c906108c | 3595 | Define this as 1 if the target does not have a hardware single-step |
56caf160 | 3596 | mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined. |
c906108c | 3597 | |
56caf160 EZ |
3598 | @item SOFTWARE_SINGLE_STEP(@var{signal}, @var{insert_breapoints_p}) |
3599 | @findex SOFTWARE_SINGLE_STEP | |
3600 | A function that inserts or removes (depending on | |
c906108c | 3601 | @var{insert_breapoints_p}) breakpoints at each possible destinations of |
56caf160 | 3602 | the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c} |
c906108c SS |
3603 | for examples. |
3604 | ||
da59e081 | 3605 | @item SOFUN_ADDRESS_MAYBE_MISSING |
56caf160 | 3606 | @findex SOFUN_ADDRESS_MAYBE_MISSING |
da59e081 JM |
3607 | Somebody clever observed that, the more actual addresses you have in the |
3608 | debug information, the more time the linker has to spend relocating | |
3609 | them. So whenever there's some other way the debugger could find the | |
3610 | address it needs, you should omit it from the debug info, to make | |
3611 | linking faster. | |
3612 | ||
3613 | @code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of | |
3614 | hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN} | |
3615 | entries in stabs-format debugging information. @code{N_SO} stabs mark | |
3616 | the beginning and ending addresses of compilation units in the text | |
3617 | segment. @code{N_FUN} stabs mark the starts and ends of functions. | |
3618 | ||
3619 | @code{SOFUN_ADDRESS_MAYBE_MISSING} means two things: | |
da59e081 | 3620 | |
56caf160 | 3621 | @itemize @bullet |
da59e081 JM |
3622 | @item |
3623 | @code{N_FUN} stabs have an address of zero. Instead, you should find the | |
3624 | addresses where the function starts by taking the function name from | |
56caf160 EZ |
3625 | the stab, and then looking that up in the minsyms (the |
3626 | linker/assembler symbol table). In other words, the stab has the | |
3627 | name, and the linker/assembler symbol table is the only place that carries | |
da59e081 JM |
3628 | the address. |
3629 | ||
3630 | @item | |
3631 | @code{N_SO} stabs have an address of zero, too. You just look at the | |
3632 | @code{N_FUN} stabs that appear before and after the @code{N_SO} stab, | |
3633 | and guess the starting and ending addresses of the compilation unit from | |
3634 | them. | |
da59e081 JM |
3635 | @end itemize |
3636 | ||
c906108c | 3637 | @item PC_LOAD_SEGMENT |
56caf160 | 3638 | @findex PC_LOAD_SEGMENT |
c906108c SS |
3639 | If defined, print information about the load segment for the program |
3640 | counter. (Defined only for the RS/6000.) | |
3641 | ||
3642 | @item PC_REGNUM | |
56caf160 | 3643 | @findex PC_REGNUM |
c906108c | 3644 | If the program counter is kept in a register, then define this macro to |
cce74817 JM |
3645 | be the number (greater than or equal to zero) of that register. |
3646 | ||
3647 | This should only need to be defined if @code{TARGET_READ_PC} and | |
3648 | @code{TARGET_WRITE_PC} are not defined. | |
c906108c | 3649 | |
2df3850c | 3650 | @item PARM_BOUNDARY |
56caf160 | 3651 | @findex PARM_BOUNDARY |
2df3850c JM |
3652 | If non-zero, round arguments to a boundary of this many bits before |
3653 | pushing them on the stack. | |
3654 | ||
a38c9fe6 MK |
3655 | @item stabs_argument_has_addr (@var{gdbarch}, @var{type}) |
3656 | @findex stabs_argument_has_addr | |
3657 | @findex DEPRECATED_REG_STRUCT_HAS_ADDR | |
3658 | @anchor{stabs_argument_has_addr} Define this to return nonzero if a | |
3659 | function argument of type @var{type} is passed by reference instead of | |
3660 | value. | |
3661 | ||
ee206350 AG |
3662 | This method replaces @code{DEPRECATED_REG_STRUCT_HAS_ADDR} |
3663 | (@pxref{DEPRECATED_REG_STRUCT_HAS_ADDR}). | |
a38c9fe6 | 3664 | |
c906108c | 3665 | @item PROCESS_LINENUMBER_HOOK |
56caf160 | 3666 | @findex PROCESS_LINENUMBER_HOOK |
c906108c SS |
3667 | A hook defined for XCOFF reading. |
3668 | ||
3669 | @item PROLOGUE_FIRSTLINE_OVERLAP | |
56caf160 | 3670 | @findex PROLOGUE_FIRSTLINE_OVERLAP |
c906108c SS |
3671 | (Only used in unsupported Convex configuration.) |
3672 | ||
3673 | @item PS_REGNUM | |
56caf160 | 3674 | @findex PS_REGNUM |
c906108c SS |
3675 | If defined, this is the number of the processor status register. (This |
3676 | definition is only used in generic code when parsing "$ps".) | |
3677 | ||
749b82f6 AC |
3678 | @item DEPRECATED_POP_FRAME |
3679 | @findex DEPRECATED_POP_FRAME | |
3680 | @findex frame_pop | |
3681 | If defined, used by @code{frame_pop} to remove a stack frame. This | |
3682 | method has been superseeded by generic code. | |
c906108c | 3683 | |
d4b6d575 | 3684 | @item push_dummy_call (@var{gdbarch}, @var{function}, @var{regcache}, @var{pc_addr}, @var{nargs}, @var{args}, @var{sp}, @var{struct_return}, @var{struct_addr}) |
b81774d8 AC |
3685 | @findex push_dummy_call |
3686 | @findex DEPRECATED_PUSH_ARGUMENTS. | |
39fe6e80 AC |
3687 | @anchor{push_dummy_call} Define this to push the dummy frame's call to |
3688 | the inferior function onto the stack. In addition to pushing | |
3689 | @var{nargs}, the code should push @var{struct_addr} (when | |
3690 | @var{struct_return}), and the return address (@var{bp_addr}). | |
c906108c | 3691 | |
86fe4aaa | 3692 | @var{function} is a pointer to a @code{struct value}; on architectures that use |
d4b6d575 RC |
3693 | function descriptors, this contains the function descriptor value. |
3694 | ||
b24da7d0 | 3695 | Returns the updated top-of-stack pointer. |
b81774d8 AC |
3696 | |
3697 | This method replaces @code{DEPRECATED_PUSH_ARGUMENTS}. | |
3698 | ||
7043d8dc AC |
3699 | @item CORE_ADDR 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}) |
3700 | @findex push_dummy_code | |
7043d8dc AC |
3701 | @anchor{push_dummy_code} Given a stack based call dummy, push the |
3702 | instruction sequence (including space for a breakpoint) to which the | |
3703 | called function should return. | |
3704 | ||
3705 | Set @var{bp_addr} to the address at which the breakpoint instruction | |
3706 | should be inserted, @var{real_pc} to the resume address when starting | |
3707 | the call sequence, and return the updated inner-most stack address. | |
3708 | ||
3709 | By default, the stack is grown sufficient to hold a frame-aligned | |
3710 | (@pxref{frame_align}) breakpoint, @var{bp_addr} is set to the address | |
3711 | reserved for that breakpoint, and @var{real_pc} set to @var{funaddr}. | |
3712 | ||
434b87dd | 3713 | This method replaces @code{CALL_DUMMY_LOCATION}, |
28954179 | 3714 | @code{DEPRECATED_REGISTER_SIZE}. |
7043d8dc | 3715 | |
56caf160 EZ |
3716 | @item REGISTER_NAME(@var{i}) |
3717 | @findex REGISTER_NAME | |
3718 | Return the name of register @var{i} as a string. May return @code{NULL} | |
3719 | or @code{NUL} to indicate that register @var{i} is not valid. | |
c906108c | 3720 | |
8e823e25 MK |
3721 | @item DEPRECATED_REG_STRUCT_HAS_ADDR (@var{gcc_p}, @var{type}) |
3722 | @findex DEPRECATED_REG_STRUCT_HAS_ADDR | |
a38c9fe6 MK |
3723 | @anchor{DEPRECATED_REG_STRUCT_HAS_ADDR}Define this to return 1 if the |
3724 | given type will be passed by pointer rather than directly. | |
3725 | ||
3726 | This method has been replaced by @code{stabs_argument_has_addr} | |
3727 | (@pxref{stabs_argument_has_addr}). | |
c906108c | 3728 | |
b24da7d0 AC |
3729 | @item SAVE_DUMMY_FRAME_TOS (@var{sp}) |
3730 | @findex SAVE_DUMMY_FRAME_TOS | |
3731 | @anchor{SAVE_DUMMY_FRAME_TOS} Used in @samp{call_function_by_hand} to | |
3732 | notify the target dependent code of the top-of-stack value that will be | |
3733 | passed to the the inferior code. This is the value of the @code{SP} | |
3734 | after both the dummy frame and space for parameters/results have been | |
3735 | allocated on the stack. @xref{unwind_dummy_id}. | |
43ff13b4 | 3736 | |
c906108c | 3737 | @item SDB_REG_TO_REGNUM |
56caf160 | 3738 | @findex SDB_REG_TO_REGNUM |
25822942 | 3739 | Define this to convert sdb register numbers into @value{GDBN} regnums. If not |
c906108c SS |
3740 | defined, no conversion will be done. |
3741 | ||
963e2bb7 | 3742 | @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 |
3743 | @findex gdbarch_return_value |
3744 | @anchor{gdbarch_return_value} Given a function with a return-value of | |
3745 | type @var{rettype}, return which return-value convention that function | |
3746 | would use. | |
3747 | ||
3748 | @value{GDBN} currently recognizes two function return-value conventions: | |
3749 | @code{RETURN_VALUE_REGISTER_CONVENTION} where the return value is found | |
3750 | in registers; and @code{RETURN_VALUE_STRUCT_CONVENTION} where the return | |
3751 | value is found in memory and the address of that memory location is | |
3752 | passed in as the function's first parameter. | |
3753 | ||
963e2bb7 AC |
3754 | If the register convention is being used, and @var{writebuf} is |
3755 | non-@code{NULL}, also copy the return-value in @var{writebuf} into | |
92ad9cd9 AC |
3756 | @var{regcache}. |
3757 | ||
963e2bb7 | 3758 | If the register convention is being used, and @var{readbuf} is |
92ad9cd9 | 3759 | non-@code{NULL}, also copy the return value from @var{regcache} into |
963e2bb7 | 3760 | @var{readbuf} (@var{regcache} contains a copy of the registers from the |
92ad9cd9 AC |
3761 | just returned function). |
3762 | ||
74055713 | 3763 | @xref{DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS}, for a description of how |
92ad9cd9 AC |
3764 | return-values that use the struct convention are handled. |
3765 | ||
3766 | @emph{Maintainer note: This method replaces separate predicate, extract, | |
3767 | store methods. By having only one method, the logic needed to determine | |
3768 | the return-value convention need only be implemented in one place. If | |
3769 | @value{GDBN} were written in an @sc{oo} language, this method would | |
3770 | instead return an object that knew how to perform the register | |
3771 | return-value extract and store.} | |
3772 | ||
3773 | @emph{Maintainer note: This method does not take a @var{gcc_p} | |
3774 | parameter, and such a parameter should not be added. If an architecture | |
3775 | that requires per-compiler or per-function information be identified, | |
3776 | then the replacement of @var{rettype} with @code{struct value} | |
3777 | @var{function} should be persued.} | |
3778 | ||
3779 | @emph{Maintainer note: The @var{regcache} parameter limits this methods | |
3780 | to the inner most frame. While replacing @var{regcache} with a | |
3781 | @code{struct frame_info} @var{frame} parameter would remove that | |
3782 | limitation there has yet to be a demonstrated need for such a change.} | |
3783 | ||
c2c6d25f | 3784 | @item SKIP_PERMANENT_BREAKPOINT |
56caf160 | 3785 | @findex SKIP_PERMANENT_BREAKPOINT |
25822942 | 3786 | Advance the inferior's PC past a permanent breakpoint. @value{GDBN} normally |
c2c6d25f JM |
3787 | steps over a breakpoint by removing it, stepping one instruction, and |
3788 | re-inserting the breakpoint. However, permanent breakpoints are | |
3789 | hardwired into the inferior, and can't be removed, so this strategy | |
56caf160 | 3790 | doesn't work. Calling @code{SKIP_PERMANENT_BREAKPOINT} adjusts the processor's |
c2c6d25f JM |
3791 | state so that execution will resume just after the breakpoint. This |
3792 | macro does the right thing even when the breakpoint is in the delay slot | |
3793 | of a branch or jump. | |
3794 | ||
56caf160 EZ |
3795 | @item SKIP_PROLOGUE (@var{pc}) |
3796 | @findex SKIP_PROLOGUE | |
b83266a0 SS |
3797 | A C expression that returns the address of the ``real'' code beyond the |
3798 | function entry prologue found at @var{pc}. | |
c906108c | 3799 | |
56caf160 EZ |
3800 | @item SKIP_TRAMPOLINE_CODE (@var{pc}) |
3801 | @findex SKIP_TRAMPOLINE_CODE | |
c906108c SS |
3802 | If the target machine has trampoline code that sits between callers and |
3803 | the functions being called, then define this macro to return a new PC | |
3804 | that is at the start of the real function. | |
3805 | ||
3806 | @item SP_REGNUM | |
56caf160 | 3807 | @findex SP_REGNUM |
cce74817 | 3808 | If the stack-pointer is kept in a register, then define this macro to be |
6c0e89ed AC |
3809 | the number (greater than or equal to zero) of that register, or -1 if |
3810 | there is no such register. | |
c906108c SS |
3811 | |
3812 | @item STAB_REG_TO_REGNUM | |
56caf160 | 3813 | @findex STAB_REG_TO_REGNUM |
c906108c | 3814 | Define this to convert stab register numbers (as gotten from `r' |
25822942 | 3815 | declarations) into @value{GDBN} regnums. If not defined, no conversion will be |
c906108c SS |
3816 | done. |
3817 | ||
f27dd7fd AC |
3818 | @item DEPRECATED_STACK_ALIGN (@var{addr}) |
3819 | @anchor{DEPRECATED_STACK_ALIGN} | |
3820 | @findex DEPRECATED_STACK_ALIGN | |
790eb8f5 AC |
3821 | Define this to increase @var{addr} so that it meets the alignment |
3822 | requirements for the processor's stack. | |
3823 | ||
3824 | Unlike @ref{frame_align}, this function always adjusts @var{addr} | |
3825 | upwards. | |
3826 | ||
3827 | By default, no stack alignment is performed. | |
c906108c | 3828 | |
56caf160 EZ |
3829 | @item STEP_SKIPS_DELAY (@var{addr}) |
3830 | @findex STEP_SKIPS_DELAY | |
c906108c SS |
3831 | Define this to return true if the address is of an instruction with a |
3832 | delay slot. If a breakpoint has been placed in the instruction's delay | |
25822942 | 3833 | slot, @value{GDBN} will single-step over that instruction before resuming |
c906108c SS |
3834 | normally. Currently only defined for the Mips. |
3835 | ||
ebba8386 | 3836 | @item STORE_RETURN_VALUE (@var{type}, @var{regcache}, @var{valbuf}) |
56caf160 | 3837 | @findex STORE_RETURN_VALUE |
ebba8386 AC |
3838 | A C expression that writes the function return value, found in |
3839 | @var{valbuf}, into the @var{regcache}. @var{type} is the type of the | |
3840 | value that is to be returned. | |
c906108c | 3841 | |
92ad9cd9 AC |
3842 | This method has been deprecated in favour of @code{gdbarch_return_value} |
3843 | (@pxref{gdbarch_return_value}). | |
3844 | ||
c906108c | 3845 | @item SYMBOL_RELOADING_DEFAULT |
56caf160 EZ |
3846 | @findex SYMBOL_RELOADING_DEFAULT |
3847 | The default value of the ``symbol-reloading'' variable. (Never defined in | |
c906108c SS |
3848 | current sources.) |
3849 | ||
c906108c | 3850 | @item TARGET_CHAR_BIT |
56caf160 | 3851 | @findex TARGET_CHAR_BIT |
c906108c SS |
3852 | Number of bits in a char; defaults to 8. |
3853 | ||
c3d3ce5b JB |
3854 | @item TARGET_CHAR_SIGNED |
3855 | @findex TARGET_CHAR_SIGNED | |
3856 | Non-zero if @code{char} is normally signed on this architecture; zero if | |
3857 | it should be unsigned. | |
3858 | ||
3859 | The ISO C standard requires the compiler to treat @code{char} as | |
3860 | equivalent to either @code{signed char} or @code{unsigned char}; any | |
3861 | character in the standard execution set is supposed to be positive. | |
3862 | Most compilers treat @code{char} as signed, but @code{char} is unsigned | |
3863 | on the IBM S/390, RS6000, and PowerPC targets. | |
3864 | ||
c906108c | 3865 | @item TARGET_COMPLEX_BIT |
56caf160 | 3866 | @findex TARGET_COMPLEX_BIT |
c906108c SS |
3867 | Number of bits in a complex number; defaults to @code{2 * TARGET_FLOAT_BIT}. |
3868 | ||
ac9a91a7 JM |
3869 | At present this macro is not used. |
3870 | ||
c906108c | 3871 | @item TARGET_DOUBLE_BIT |
56caf160 | 3872 | @findex TARGET_DOUBLE_BIT |
c906108c SS |
3873 | Number of bits in a double float; defaults to @code{8 * TARGET_CHAR_BIT}. |
3874 | ||
3875 | @item TARGET_DOUBLE_COMPLEX_BIT | |
56caf160 | 3876 | @findex TARGET_DOUBLE_COMPLEX_BIT |
c906108c SS |
3877 | Number of bits in a double complex; defaults to @code{2 * TARGET_DOUBLE_BIT}. |
3878 | ||
ac9a91a7 JM |
3879 | At present this macro is not used. |
3880 | ||
c906108c | 3881 | @item TARGET_FLOAT_BIT |
56caf160 | 3882 | @findex TARGET_FLOAT_BIT |
c906108c SS |
3883 | Number of bits in a float; defaults to @code{4 * TARGET_CHAR_BIT}. |
3884 | ||
3885 | @item TARGET_INT_BIT | |
56caf160 | 3886 | @findex TARGET_INT_BIT |
c906108c SS |
3887 | Number of bits in an integer; defaults to @code{4 * TARGET_CHAR_BIT}. |
3888 | ||
3889 | @item TARGET_LONG_BIT | |
56caf160 | 3890 | @findex TARGET_LONG_BIT |
c906108c SS |
3891 | Number of bits in a long integer; defaults to @code{4 * TARGET_CHAR_BIT}. |
3892 | ||
3893 | @item TARGET_LONG_DOUBLE_BIT | |
56caf160 | 3894 | @findex TARGET_LONG_DOUBLE_BIT |
c906108c SS |
3895 | Number of bits in a long double float; |
3896 | defaults to @code{2 * TARGET_DOUBLE_BIT}. | |
3897 | ||
3898 | @item TARGET_LONG_LONG_BIT | |
56caf160 | 3899 | @findex TARGET_LONG_LONG_BIT |
c906108c SS |
3900 | Number of bits in a long long integer; defaults to @code{2 * TARGET_LONG_BIT}. |
3901 | ||
3902 | @item TARGET_PTR_BIT | |
56caf160 | 3903 | @findex TARGET_PTR_BIT |
c906108c SS |
3904 | Number of bits in a pointer; defaults to @code{TARGET_INT_BIT}. |
3905 | ||
3906 | @item TARGET_SHORT_BIT | |
56caf160 | 3907 | @findex TARGET_SHORT_BIT |
c906108c SS |
3908 | Number of bits in a short integer; defaults to @code{2 * TARGET_CHAR_BIT}. |
3909 | ||
3910 | @item TARGET_READ_PC | |
56caf160 EZ |
3911 | @findex TARGET_READ_PC |
3912 | @itemx TARGET_WRITE_PC (@var{val}, @var{pid}) | |
3913 | @findex TARGET_WRITE_PC | |
0717ae8a | 3914 | @anchor{TARGET_WRITE_PC} |
56caf160 EZ |
3915 | @itemx TARGET_READ_SP |
3916 | @findex TARGET_READ_SP | |
56caf160 EZ |
3917 | @itemx TARGET_READ_FP |
3918 | @findex TARGET_READ_FP | |
56caf160 EZ |
3919 | @findex read_pc |
3920 | @findex write_pc | |
3921 | @findex read_sp | |
56caf160 | 3922 | @findex read_fp |
a9e5fdc2 | 3923 | @anchor{TARGET_READ_SP} These change the behavior of @code{read_pc}, |
8d2c00cb | 3924 | @code{write_pc}, and @code{read_sp}. For most targets, these may be |
9c8dbfa9 AC |
3925 | left undefined. @value{GDBN} will call the read and write register |
3926 | functions with the relevant @code{_REGNUM} argument. | |
c906108c SS |
3927 | |
3928 | These macros are useful when a target keeps one of these registers in a | |
3929 | hard to get at place; for example, part in a segment register and part | |
3930 | in an ordinary register. | |
3931 | ||
a9e5fdc2 AC |
3932 | @xref{unwind_sp}, which replaces @code{TARGET_READ_SP}. |
3933 | ||
56caf160 EZ |
3934 | @item TARGET_VIRTUAL_FRAME_POINTER(@var{pc}, @var{regp}, @var{offsetp}) |
3935 | @findex TARGET_VIRTUAL_FRAME_POINTER | |
0ba6dca9 AC |
3936 | Returns a @code{(register, offset)} pair representing the virtual frame |
3937 | pointer in use at the code address @var{pc}. If virtual frame pointers | |
3938 | are not used, a default definition simply returns | |
3939 | @code{DEPRECATED_FP_REGNUM}, with an offset of zero. | |
c906108c | 3940 | |
9742079a EZ |
3941 | @item TARGET_HAS_HARDWARE_WATCHPOINTS |
3942 | If non-zero, the target has support for hardware-assisted | |
3943 | watchpoints. @xref{Algorithms, watchpoints}, for more details and | |
3944 | other related macros. | |
3945 | ||
7ccaa899 EZ |
3946 | @item TARGET_PRINT_INSN (@var{addr}, @var{info}) |
3947 | @findex TARGET_PRINT_INSN | |
3948 | This is the function used by @value{GDBN} to print an assembly | |
3949 | instruction. It prints the instruction at address @var{addr} in | |
3950 | debugged memory and returns the length of the instruction, in bytes. If | |
3951 | a target doesn't define its own printing routine, it defaults to an | |
d7a27068 AC |
3952 | accessor function for the global pointer |
3953 | @code{deprecated_tm_print_insn}. This usually points to a function in | |
3954 | the @code{opcodes} library (@pxref{Support Libraries, ,Opcodes}). | |
3955 | @var{info} is a structure (of type @code{disassemble_info}) defined in | |
3956 | @file{include/dis-asm.h} used to pass information to the instruction | |
3957 | decoding routine. | |
7ccaa899 | 3958 | |
6314f104 AC |
3959 | @item struct frame_id unwind_dummy_id (struct frame_info *@var{frame}) |
3960 | @findex unwind_dummy_id | |
3961 | @anchor{unwind_dummy_id} Given @var{frame} return a @code{struct | |
3962 | frame_id} that uniquely identifies an inferior function call's dummy | |
b24da7d0 AC |
3963 | frame. The value returned must match the dummy frame stack value |
3964 | previously saved using @code{SAVE_DUMMY_FRAME_TOS}. | |
3965 | @xref{SAVE_DUMMY_FRAME_TOS}. | |
6314f104 | 3966 | |
b5622e8d AC |
3967 | @item DEPRECATED_USE_STRUCT_CONVENTION (@var{gcc_p}, @var{type}) |
3968 | @findex DEPRECATED_USE_STRUCT_CONVENTION | |
c906108c SS |
3969 | If defined, this must be an expression that is nonzero if a value of the |
3970 | given @var{type} being returned from a function must have space | |
3971 | allocated for it on the stack. @var{gcc_p} is true if the function | |
3972 | being considered is known to have been compiled by GCC; this is helpful | |
3973 | for systems where GCC is known to use different calling convention than | |
3974 | other compilers. | |
3975 | ||
92ad9cd9 AC |
3976 | This method has been deprecated in favour of @code{gdbarch_return_value} |
3977 | (@pxref{gdbarch_return_value}). | |
3978 | ||
13d01224 AC |
3979 | @item VALUE_TO_REGISTER(@var{type}, @var{regnum}, @var{from}, @var{to}) |
3980 | @findex VALUE_TO_REGISTER | |
3981 | Convert a value of type @var{type} into the raw contents of register | |
3982 | @var{regnum}'s. | |
3983 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. | |
3984 | ||
56caf160 EZ |
3985 | @item VARIABLES_INSIDE_BLOCK (@var{desc}, @var{gcc_p}) |
3986 | @findex VARIABLES_INSIDE_BLOCK | |
c906108c SS |
3987 | For dbx-style debugging information, if the compiler puts variable |
3988 | declarations inside LBRAC/RBRAC blocks, this should be defined to be | |
3989 | nonzero. @var{desc} is the value of @code{n_desc} from the | |
25822942 | 3990 | @code{N_RBRAC} symbol, and @var{gcc_p} is true if @value{GDBN} has noticed the |
c906108c SS |
3991 | presence of either the @code{GCC_COMPILED_SYMBOL} or the |
3992 | @code{GCC2_COMPILED_SYMBOL}. By default, this is 0. | |
3993 | ||
56caf160 EZ |
3994 | @item OS9K_VARIABLES_INSIDE_BLOCK (@var{desc}, @var{gcc_p}) |
3995 | @findex OS9K_VARIABLES_INSIDE_BLOCK | |
c906108c | 3996 | Similarly, for OS/9000. Defaults to 1. |
c906108c SS |
3997 | @end table |
3998 | ||
3999 | Motorola M68K target conditionals. | |
4000 | ||
56caf160 | 4001 | @ftable @code |
c906108c SS |
4002 | @item BPT_VECTOR |
4003 | Define this to be the 4-bit location of the breakpoint trap vector. If | |
4004 | not defined, it will default to @code{0xf}. | |
4005 | ||
4006 | @item REMOTE_BPT_VECTOR | |
4007 | Defaults to @code{1}. | |
a23a7bf1 JB |
4008 | |
4009 | @item NAME_OF_MALLOC | |
4010 | @findex NAME_OF_MALLOC | |
4011 | A string containing the name of the function to call in order to | |
4012 | allocate some memory in the inferior. The default value is "malloc". | |
4013 | ||
56caf160 | 4014 | @end ftable |
c906108c SS |
4015 | |
4016 | @section Adding a New Target | |
4017 | ||
56caf160 | 4018 | @cindex adding a target |
af6c57ea | 4019 | The following files add a target to @value{GDBN}: |
c906108c SS |
4020 | |
4021 | @table @file | |
56caf160 | 4022 | @vindex TDEPFILES |
c906108c SS |
4023 | @item gdb/config/@var{arch}/@var{ttt}.mt |
4024 | Contains a Makefile fragment specific to this target. Specifies what | |
4025 | object files are needed for target @var{ttt}, by defining | |
104c1213 JM |
4026 | @samp{TDEPFILES=@dots{}} and @samp{TDEPLIBS=@dots{}}. Also specifies |
4027 | the header file which describes @var{ttt}, by defining @samp{TM_FILE= | |
4028 | tm-@var{ttt}.h}. | |
4029 | ||
4030 | You can also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, @samp{TM_CDEPS}, | |
4031 | but these are now deprecated, replaced by autoconf, and may go away in | |
25822942 | 4032 | future versions of @value{GDBN}. |
c906108c | 4033 | |
c906108c SS |
4034 | @item gdb/@var{ttt}-tdep.c |
4035 | Contains any miscellaneous code required for this target machine. On | |
4036 | some machines it doesn't exist at all. Sometimes the macros in | |
4037 | @file{tm-@var{ttt}.h} become very complicated, so they are implemented | |
4038 | as functions here instead, and the macro is simply defined to call the | |
4039 | function. This is vastly preferable, since it is easier to understand | |
4040 | and debug. | |
4041 | ||
af6c57ea AC |
4042 | @item gdb/@var{arch}-tdep.c |
4043 | @itemx gdb/@var{arch}-tdep.h | |
4044 | This often exists to describe the basic layout of the target machine's | |
4045 | processor chip (registers, stack, etc.). If used, it is included by | |
4046 | @file{@var{ttt}-tdep.h}. It can be shared among many targets that use | |
4047 | the same processor. | |
4048 | ||
4049 | @item gdb/config/@var{arch}/tm-@var{ttt}.h | |
4050 | (@file{tm.h} is a link to this file, created by @code{configure}). Contains | |
4051 | macro definitions about the target machine's registers, stack frame | |
4052 | format and instructions. | |
4053 | ||
4054 | New targets do not need this file and should not create it. | |
4055 | ||
c906108c SS |
4056 | @item gdb/config/@var{arch}/tm-@var{arch}.h |
4057 | This often exists to describe the basic layout of the target machine's | |
56caf160 | 4058 | processor chip (registers, stack, etc.). If used, it is included by |
c906108c SS |
4059 | @file{tm-@var{ttt}.h}. It can be shared among many targets that use the |
4060 | same processor. | |
4061 | ||
af6c57ea AC |
4062 | New targets do not need this file and should not create it. |
4063 | ||
c906108c SS |
4064 | @end table |
4065 | ||
4066 | If you are adding a new operating system for an existing CPU chip, add a | |
4067 | @file{config/tm-@var{os}.h} file that describes the operating system | |
4068 | facilities that are unusual (extra symbol table info; the breakpoint | |
56caf160 | 4069 | instruction needed; etc.). Then write a @file{@var{arch}/tm-@var{os}.h} |
c906108c SS |
4070 | that just @code{#include}s @file{tm-@var{arch}.h} and |
4071 | @file{config/tm-@var{os}.h}. | |
4072 | ||
4073 | ||
3352e23e AC |
4074 | @section Converting an existing Target Architecture to Multi-arch |
4075 | @cindex converting targets to multi-arch | |
4076 | ||
4077 | This section describes the current accepted best practice for converting | |
4078 | an existing target architecture to the multi-arch framework. | |
4079 | ||
4080 | The process consists of generating, testing, posting and committing a | |
4081 | sequence of patches. Each patch must contain a single change, for | |
4082 | instance: | |
4083 | ||
4084 | @itemize @bullet | |
4085 | ||
4086 | @item | |
4087 | Directly convert a group of functions into macros (the conversion does | |
4088 | not change the behavior of any of the functions). | |
4089 | ||
4090 | @item | |
4091 | Replace a non-multi-arch with a multi-arch mechanism (e.g., | |
4092 | @code{FRAME_INFO}). | |
4093 | ||
4094 | @item | |
4095 | Enable multi-arch level one. | |
4096 | ||
4097 | @item | |
4098 | Delete one or more files. | |
4099 | ||
4100 | @end itemize | |
4101 | ||
4102 | @noindent | |
4103 | There isn't a size limit on a patch, however, a developer is strongly | |
4104 | encouraged to keep the patch size down. | |
4105 | ||
4106 | Since each patch is well defined, and since each change has been tested | |
4107 | and shows no regressions, the patches are considered @emph{fairly} | |
4108 | obvious. Such patches, when submitted by developers listed in the | |
4109 | @file{MAINTAINERS} file, do not need approval. Occasional steps in the | |
4110 | process may be more complicated and less clear. The developer is | |
4111 | expected to use their judgment and is encouraged to seek advice as | |
4112 | needed. | |
4113 | ||
4114 | @subsection Preparation | |
4115 | ||
4116 | The first step is to establish control. Build (with @option{-Werror} | |
4117 | enabled) and test the target so that there is a baseline against which | |
4118 | the debugger can be compared. | |
4119 | ||
4120 | At no stage can the test results regress or @value{GDBN} stop compiling | |
4121 | with @option{-Werror}. | |
4122 | ||
4123 | @subsection Add the multi-arch initialization code | |
4124 | ||
4125 | The objective of this step is to establish the basic multi-arch | |
4126 | framework. It involves | |
4127 | ||
4128 | @itemize @bullet | |
4129 | ||
4130 | @item | |
4131 | The addition of a @code{@var{arch}_gdbarch_init} function@footnote{The | |
4132 | above is from the original example and uses K&R C. @value{GDBN} | |
4133 | has since converted to ISO C but lets ignore that.} that creates | |
4134 | the architecture: | |
4135 | @smallexample | |
4136 | static struct gdbarch * | |
4137 | d10v_gdbarch_init (info, arches) | |
4138 | struct gdbarch_info info; | |
4139 | struct gdbarch_list *arches; | |
4140 | @{ | |
4141 | struct gdbarch *gdbarch; | |
4142 | /* there is only one d10v architecture */ | |
4143 | if (arches != NULL) | |
4144 | return arches->gdbarch; | |
4145 | gdbarch = gdbarch_alloc (&info, NULL); | |
4146 | return gdbarch; | |
4147 | @} | |
4148 | @end smallexample | |
4149 | @noindent | |
4150 | @emph{} | |
4151 | ||
4152 | @item | |
4153 | A per-architecture dump function to print any architecture specific | |
4154 | information: | |
4155 | @smallexample | |
4156 | static void | |
4157 | mips_dump_tdep (struct gdbarch *current_gdbarch, | |
4158 | struct ui_file *file) | |
4159 | @{ | |
4160 | @dots{} code to print architecture specific info @dots{} | |
4161 | @} | |
4162 | @end smallexample | |
4163 | ||
4164 | @item | |
4165 | A change to @code{_initialize_@var{arch}_tdep} to register this new | |
4166 | architecture: | |
4167 | @smallexample | |
4168 | void | |
4169 | _initialize_mips_tdep (void) | |
4170 | @{ | |
4171 | gdbarch_register (bfd_arch_mips, mips_gdbarch_init, | |
4172 | mips_dump_tdep); | |
4173 | @end smallexample | |
4174 | ||
4175 | @item | |
4176 | Add the macro @code{GDB_MULTI_ARCH}, defined as 0 (zero), to the file@* | |
4177 | @file{config/@var{arch}/tm-@var{arch}.h}. | |
4178 | ||
4179 | @end itemize | |
4180 | ||
4181 | @subsection Update multi-arch incompatible mechanisms | |
4182 | ||
4183 | Some mechanisms do not work with multi-arch. They include: | |
4184 | ||
4185 | @table @code | |
3352e23e | 4186 | @item FRAME_FIND_SAVED_REGS |
f30ee0bc | 4187 | Replaced with @code{DEPRECATED_FRAME_INIT_SAVED_REGS} |
3352e23e AC |
4188 | @end table |
4189 | ||
4190 | @noindent | |
4191 | At this stage you could also consider converting the macros into | |
4192 | functions. | |
4193 | ||
4194 | @subsection Prepare for multi-arch level to one | |
4195 | ||
4196 | Temporally set @code{GDB_MULTI_ARCH} to @code{GDB_MULTI_ARCH_PARTIAL} | |
4197 | and then build and start @value{GDBN} (the change should not be | |
4198 | committed). @value{GDBN} may not build, and once built, it may die with | |
4199 | an internal error listing the architecture methods that must be | |
4200 | provided. | |
4201 | ||
4202 | Fix any build problems (patch(es)). | |
4203 | ||
4204 | Convert all the architecture methods listed, which are only macros, into | |
4205 | functions (patch(es)). | |
4206 | ||
4207 | Update @code{@var{arch}_gdbarch_init} to set all the missing | |
4208 | architecture methods and wrap the corresponding macros in @code{#if | |
4209 | !GDB_MULTI_ARCH} (patch(es)). | |
4210 | ||
4211 | @subsection Set multi-arch level one | |
4212 | ||
4213 | Change the value of @code{GDB_MULTI_ARCH} to GDB_MULTI_ARCH_PARTIAL (a | |
4214 | single patch). | |
4215 | ||
4216 | Any problems with throwing ``the switch'' should have been fixed | |
4217 | already. | |
4218 | ||
4219 | @subsection Convert remaining macros | |
4220 | ||
4221 | Suggest converting macros into functions (and setting the corresponding | |
4222 | architecture method) in small batches. | |
4223 | ||
4224 | @subsection Set multi-arch level to two | |
4225 | ||
4226 | This should go smoothly. | |
4227 | ||
4228 | @subsection Delete the TM file | |
4229 | ||
4230 | The @file{tm-@var{arch}.h} can be deleted. @file{@var{arch}.mt} and | |
4231 | @file{configure.in} updated. | |
4232 | ||
4233 | ||
c906108c SS |
4234 | @node Target Vector Definition |
4235 | ||
4236 | @chapter Target Vector Definition | |
56caf160 | 4237 | @cindex target vector |
c906108c | 4238 | |
56caf160 EZ |
4239 | The target vector defines the interface between @value{GDBN}'s |
4240 | abstract handling of target systems, and the nitty-gritty code that | |
4241 | actually exercises control over a process or a serial port. | |
4242 | @value{GDBN} includes some 30-40 different target vectors; however, | |
4243 | each configuration of @value{GDBN} includes only a few of them. | |
c906108c SS |
4244 | |
4245 | @section File Targets | |
4246 | ||
4247 | Both executables and core files have target vectors. | |
4248 | ||
4249 | @section Standard Protocol and Remote Stubs | |
4250 | ||
56caf160 EZ |
4251 | @value{GDBN}'s file @file{remote.c} talks a serial protocol to code |
4252 | that runs in the target system. @value{GDBN} provides several sample | |
4253 | @dfn{stubs} that can be integrated into target programs or operating | |
4254 | systems for this purpose; they are named @file{*-stub.c}. | |
c906108c | 4255 | |
56caf160 EZ |
4256 | The @value{GDBN} user's manual describes how to put such a stub into |
4257 | your target code. What follows is a discussion of integrating the | |
4258 | SPARC stub into a complicated operating system (rather than a simple | |
4259 | program), by Stu Grossman, the author of this stub. | |
c906108c SS |
4260 | |
4261 | The trap handling code in the stub assumes the following upon entry to | |
56caf160 | 4262 | @code{trap_low}: |
c906108c SS |
4263 | |
4264 | @enumerate | |
56caf160 EZ |
4265 | @item |
4266 | %l1 and %l2 contain pc and npc respectively at the time of the trap; | |
c906108c | 4267 | |
56caf160 EZ |
4268 | @item |
4269 | traps are disabled; | |
c906108c | 4270 | |
56caf160 EZ |
4271 | @item |
4272 | you are in the correct trap window. | |
c906108c SS |
4273 | @end enumerate |
4274 | ||
4275 | As long as your trap handler can guarantee those conditions, then there | |
56caf160 | 4276 | is no reason why you shouldn't be able to ``share'' traps with the stub. |
c906108c SS |
4277 | The stub has no requirement that it be jumped to directly from the |
4278 | hardware trap vector. That is why it calls @code{exceptionHandler()}, | |
4279 | which is provided by the external environment. For instance, this could | |
56caf160 | 4280 | set up the hardware traps to actually execute code which calls the stub |
c906108c SS |
4281 | first, and then transfers to its own trap handler. |
4282 | ||
4283 | For the most point, there probably won't be much of an issue with | |
56caf160 | 4284 | ``sharing'' traps, as the traps we use are usually not used by the kernel, |
c906108c SS |
4285 | and often indicate unrecoverable error conditions. Anyway, this is all |
4286 | controlled by a table, and is trivial to modify. The most important | |
4287 | trap for us is for @code{ta 1}. Without that, we can't single step or | |
4288 | do breakpoints. Everything else is unnecessary for the proper operation | |
4289 | of the debugger/stub. | |
4290 | ||
4291 | From reading the stub, it's probably not obvious how breakpoints work. | |
25822942 | 4292 | They are simply done by deposit/examine operations from @value{GDBN}. |
c906108c SS |
4293 | |
4294 | @section ROM Monitor Interface | |
4295 | ||
4296 | @section Custom Protocols | |
4297 | ||
4298 | @section Transport Layer | |
4299 | ||
4300 | @section Builtin Simulator | |
4301 | ||
4302 | ||
4303 | @node Native Debugging | |
4304 | ||
4305 | @chapter Native Debugging | |
56caf160 | 4306 | @cindex native debugging |
c906108c | 4307 | |
25822942 | 4308 | Several files control @value{GDBN}'s configuration for native support: |
c906108c SS |
4309 | |
4310 | @table @file | |
56caf160 | 4311 | @vindex NATDEPFILES |
c906108c | 4312 | @item gdb/config/@var{arch}/@var{xyz}.mh |
7fd60527 | 4313 | Specifies Makefile fragments needed by a @emph{native} configuration on |
c906108c SS |
4314 | machine @var{xyz}. In particular, this lists the required |
4315 | native-dependent object files, by defining @samp{NATDEPFILES=@dots{}}. | |
4316 | Also specifies the header file which describes native support on | |
4317 | @var{xyz}, by defining @samp{NAT_FILE= nm-@var{xyz}.h}. You can also | |
4318 | define @samp{NAT_CFLAGS}, @samp{NAT_ADD_FILES}, @samp{NAT_CLIBS}, | |
4319 | @samp{NAT_CDEPS}, etc.; see @file{Makefile.in}. | |
4320 | ||
7fd60527 AC |
4321 | @emph{Maintainer's note: The @file{.mh} suffix is because this file |
4322 | originally contained @file{Makefile} fragments for hosting @value{GDBN} | |
4323 | on machine @var{xyz}. While the file is no longer used for this | |
937f164b | 4324 | purpose, the @file{.mh} suffix remains. Perhaps someone will |
7fd60527 AC |
4325 | eventually rename these fragments so that they have a @file{.mn} |
4326 | suffix.} | |
4327 | ||
c906108c | 4328 | @item gdb/config/@var{arch}/nm-@var{xyz}.h |
56caf160 | 4329 | (@file{nm.h} is a link to this file, created by @code{configure}). Contains C |
c906108c SS |
4330 | macro definitions describing the native system environment, such as |
4331 | child process control and core file support. | |
4332 | ||
4333 | @item gdb/@var{xyz}-nat.c | |
4334 | Contains any miscellaneous C code required for this native support of | |
4335 | this machine. On some machines it doesn't exist at all. | |
c906108c SS |
4336 | @end table |
4337 | ||
4338 | There are some ``generic'' versions of routines that can be used by | |
4339 | various systems. These can be customized in various ways by macros | |
4340 | defined in your @file{nm-@var{xyz}.h} file. If these routines work for | |
4341 | the @var{xyz} host, you can just include the generic file's name (with | |
4342 | @samp{.o}, not @samp{.c}) in @code{NATDEPFILES}. | |
4343 | ||
4344 | Otherwise, if your machine needs custom support routines, you will need | |
4345 | to write routines that perform the same functions as the generic file. | |
56caf160 | 4346 | Put them into @file{@var{xyz}-nat.c}, and put @file{@var{xyz}-nat.o} |
c906108c SS |
4347 | into @code{NATDEPFILES}. |
4348 | ||
4349 | @table @file | |
c906108c SS |
4350 | @item inftarg.c |
4351 | This contains the @emph{target_ops vector} that supports Unix child | |
4352 | processes on systems which use ptrace and wait to control the child. | |
4353 | ||
4354 | @item procfs.c | |
4355 | This contains the @emph{target_ops vector} that supports Unix child | |
4356 | processes on systems which use /proc to control the child. | |
4357 | ||
4358 | @item fork-child.c | |
56caf160 EZ |
4359 | This does the low-level grunge that uses Unix system calls to do a ``fork |
4360 | and exec'' to start up a child process. | |
c906108c SS |
4361 | |
4362 | @item infptrace.c | |
4363 | This is the low level interface to inferior processes for systems using | |
4364 | the Unix @code{ptrace} call in a vanilla way. | |
c906108c SS |
4365 | @end table |
4366 | ||
4367 | @section Native core file Support | |
56caf160 | 4368 | @cindex native core files |
c906108c SS |
4369 | |
4370 | @table @file | |
56caf160 | 4371 | @findex fetch_core_registers |
c906108c SS |
4372 | @item core-aout.c::fetch_core_registers() |
4373 | Support for reading registers out of a core file. This routine calls | |
4374 | @code{register_addr()}, see below. Now that BFD is used to read core | |
4375 | files, virtually all machines should use @code{core-aout.c}, and should | |
4376 | just provide @code{fetch_core_registers} in @code{@var{xyz}-nat.c} (or | |
4377 | @code{REGISTER_U_ADDR} in @code{nm-@var{xyz}.h}). | |
4378 | ||
4379 | @item core-aout.c::register_addr() | |
4380 | If your @code{nm-@var{xyz}.h} file defines the macro | |
4381 | @code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to | |
25822942 | 4382 | set @code{addr} to the offset within the @samp{user} struct of @value{GDBN} |
c906108c SS |
4383 | register number @code{regno}. @code{blockend} is the offset within the |
4384 | ``upage'' of @code{u.u_ar0}. If @code{REGISTER_U_ADDR} is defined, | |
4385 | @file{core-aout.c} will define the @code{register_addr()} function and | |
4386 | use the macro in it. If you do not define @code{REGISTER_U_ADDR}, but | |
4387 | you are using the standard @code{fetch_core_registers()}, you will need | |
4388 | to define your own version of @code{register_addr()}, put it into your | |
4389 | @code{@var{xyz}-nat.c} file, and be sure @code{@var{xyz}-nat.o} is in | |
4390 | the @code{NATDEPFILES} list. If you have your own | |
4391 | @code{fetch_core_registers()}, you may not need a separate | |
4392 | @code{register_addr()}. Many custom @code{fetch_core_registers()} | |
4393 | implementations simply locate the registers themselves.@refill | |
c906108c SS |
4394 | @end table |
4395 | ||
25822942 | 4396 | When making @value{GDBN} run native on a new operating system, to make it |
c906108c SS |
4397 | possible to debug core files, you will need to either write specific |
4398 | code for parsing your OS's core files, or customize | |
4399 | @file{bfd/trad-core.c}. First, use whatever @code{#include} files your | |
4400 | machine uses to define the struct of registers that is accessible | |
4401 | (possibly in the u-area) in a core file (rather than | |
4402 | @file{machine/reg.h}), and an include file that defines whatever header | |
c1468174 | 4403 | exists on a core file (e.g., the u-area or a @code{struct core}). Then |
56caf160 | 4404 | modify @code{trad_unix_core_file_p} to use these values to set up the |
c906108c SS |
4405 | section information for the data segment, stack segment, any other |
4406 | segments in the core file (perhaps shared library contents or control | |
4407 | information), ``registers'' segment, and if there are two discontiguous | |
c1468174 | 4408 | sets of registers (e.g., integer and float), the ``reg2'' segment. This |
c906108c SS |
4409 | section information basically delimits areas in the core file in a |
4410 | standard way, which the section-reading routines in BFD know how to seek | |
4411 | around in. | |
4412 | ||
25822942 | 4413 | Then back in @value{GDBN}, you need a matching routine called |
56caf160 | 4414 | @code{fetch_core_registers}. If you can use the generic one, it's in |
c906108c SS |
4415 | @file{core-aout.c}; if not, it's in your @file{@var{xyz}-nat.c} file. |
4416 | It will be passed a char pointer to the entire ``registers'' segment, | |
4417 | its length, and a zero; or a char pointer to the entire ``regs2'' | |
4418 | segment, its length, and a 2. The routine should suck out the supplied | |
25822942 | 4419 | register values and install them into @value{GDBN}'s ``registers'' array. |
c906108c SS |
4420 | |
4421 | If your system uses @file{/proc} to control processes, and uses ELF | |
4422 | format core files, then you may be able to use the same routines for | |
4423 | reading the registers out of processes and out of core files. | |
4424 | ||
4425 | @section ptrace | |
4426 | ||
4427 | @section /proc | |
4428 | ||
4429 | @section win32 | |
4430 | ||
4431 | @section shared libraries | |
4432 | ||
4433 | @section Native Conditionals | |
56caf160 | 4434 | @cindex native conditionals |
c906108c | 4435 | |
56caf160 EZ |
4436 | When @value{GDBN} is configured and compiled, various macros are |
4437 | defined or left undefined, to control compilation when the host and | |
4438 | target systems are the same. These macros should be defined (or left | |
4439 | undefined) in @file{nm-@var{system}.h}. | |
c906108c | 4440 | |
1f6d4158 AC |
4441 | @table @code |
4442 | ||
c906108c | 4443 | @item CHILD_PREPARE_TO_STORE |
56caf160 | 4444 | @findex CHILD_PREPARE_TO_STORE |
c906108c SS |
4445 | If the machine stores all registers at once in the child process, then |
4446 | define this to ensure that all values are correct. This usually entails | |
4447 | a read from the child. | |
4448 | ||
4449 | [Note that this is incorrectly defined in @file{xm-@var{system}.h} files | |
4450 | currently.] | |
4451 | ||
4452 | @item FETCH_INFERIOR_REGISTERS | |
56caf160 | 4453 | @findex FETCH_INFERIOR_REGISTERS |
c906108c SS |
4454 | Define this if the native-dependent code will provide its own routines |
4455 | @code{fetch_inferior_registers} and @code{store_inferior_registers} in | |
56caf160 | 4456 | @file{@var{host}-nat.c}. If this symbol is @emph{not} defined, and |
c906108c SS |
4457 | @file{infptrace.c} is included in this configuration, the default |
4458 | routines in @file{infptrace.c} are used for these functions. | |
4459 | ||
c906108c | 4460 | @item FP0_REGNUM |
56caf160 | 4461 | @findex FP0_REGNUM |
c906108c SS |
4462 | This macro is normally defined to be the number of the first floating |
4463 | point register, if the machine has such registers. As such, it would | |
56caf160 | 4464 | appear only in target-specific code. However, @file{/proc} support uses this |
c906108c SS |
4465 | to decide whether floats are in use on this target. |
4466 | ||
4467 | @item GET_LONGJMP_TARGET | |
56caf160 | 4468 | @findex GET_LONGJMP_TARGET |
c906108c SS |
4469 | For most machines, this is a target-dependent parameter. On the |
4470 | DECstation and the Iris, this is a native-dependent parameter, since | |
56caf160 | 4471 | @file{setjmp.h} is needed to define it. |
c906108c | 4472 | |
56caf160 | 4473 | This macro determines the target PC address that @code{longjmp} will jump to, |
c906108c | 4474 | assuming that we have just stopped at a longjmp breakpoint. It takes a |
56caf160 | 4475 | @code{CORE_ADDR *} as argument, and stores the target PC value through this |
c906108c SS |
4476 | pointer. It examines the current state of the machine as needed. |
4477 | ||
9742079a EZ |
4478 | @item I386_USE_GENERIC_WATCHPOINTS |
4479 | An x86-based machine can define this to use the generic x86 watchpoint | |
4480 | support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}. | |
4481 | ||
c906108c | 4482 | @item KERNEL_U_ADDR |
56caf160 | 4483 | @findex KERNEL_U_ADDR |
c906108c | 4484 | Define this to the address of the @code{u} structure (the ``user |
25822942 | 4485 | struct'', also known as the ``u-page'') in kernel virtual memory. @value{GDBN} |
c906108c SS |
4486 | needs to know this so that it can subtract this address from absolute |
4487 | addresses in the upage, that are obtained via ptrace or from core files. | |
4488 | On systems that don't need this value, set it to zero. | |
4489 | ||
c906108c | 4490 | @item KERNEL_U_ADDR_HPUX |
56caf160 | 4491 | @findex KERNEL_U_ADDR_HPUX |
25822942 | 4492 | Define this to cause @value{GDBN} to determine the address of @code{u} at |
c906108c SS |
4493 | runtime, by using HP-style @code{nlist} on the kernel's image in the |
4494 | root directory. | |
4495 | ||
4496 | @item ONE_PROCESS_WRITETEXT | |
56caf160 | 4497 | @findex ONE_PROCESS_WRITETEXT |
c906108c SS |
4498 | Define this to be able to, when a breakpoint insertion fails, warn the |
4499 | user that another process may be running with the same executable. | |
4500 | ||
4501 | @item PROC_NAME_FMT | |
56caf160 | 4502 | @findex PROC_NAME_FMT |
c906108c SS |
4503 | Defines the format for the name of a @file{/proc} device. Should be |
4504 | defined in @file{nm.h} @emph{only} in order to override the default | |
4505 | definition in @file{procfs.c}. | |
4506 | ||
c906108c | 4507 | @item PTRACE_ARG3_TYPE |
56caf160 | 4508 | @findex PTRACE_ARG3_TYPE |
c906108c SS |
4509 | The type of the third argument to the @code{ptrace} system call, if it |
4510 | exists and is different from @code{int}. | |
4511 | ||
4512 | @item REGISTER_U_ADDR | |
56caf160 | 4513 | @findex REGISTER_U_ADDR |
c906108c SS |
4514 | Defines the offset of the registers in the ``u area''. |
4515 | ||
4516 | @item SHELL_COMMAND_CONCAT | |
56caf160 | 4517 | @findex SHELL_COMMAND_CONCAT |
c906108c SS |
4518 | If defined, is a string to prefix on the shell command used to start the |
4519 | inferior. | |
4520 | ||
4521 | @item SHELL_FILE | |
56caf160 | 4522 | @findex SHELL_FILE |
c906108c SS |
4523 | If defined, this is the name of the shell to use to run the inferior. |
4524 | Defaults to @code{"/bin/sh"}. | |
4525 | ||
990f9fe3 | 4526 | @item SOLIB_ADD (@var{filename}, @var{from_tty}, @var{targ}, @var{readsyms}) |
56caf160 | 4527 | @findex SOLIB_ADD |
c906108c | 4528 | Define this to expand into an expression that will cause the symbols in |
990f9fe3 FF |
4529 | @var{filename} to be added to @value{GDBN}'s symbol table. If |
4530 | @var{readsyms} is zero symbols are not read but any necessary low level | |
4531 | processing for @var{filename} is still done. | |
c906108c SS |
4532 | |
4533 | @item SOLIB_CREATE_INFERIOR_HOOK | |
56caf160 | 4534 | @findex SOLIB_CREATE_INFERIOR_HOOK |
c906108c SS |
4535 | Define this to expand into any shared-library-relocation code that you |
4536 | want to be run just after the child process has been forked. | |
4537 | ||
4538 | @item START_INFERIOR_TRAPS_EXPECTED | |
56caf160 EZ |
4539 | @findex START_INFERIOR_TRAPS_EXPECTED |
4540 | When starting an inferior, @value{GDBN} normally expects to trap | |
4541 | twice; once when | |
c906108c SS |
4542 | the shell execs, and once when the program itself execs. If the actual |
4543 | number of traps is something other than 2, then define this macro to | |
4544 | expand into the number expected. | |
4545 | ||
c906108c | 4546 | @item USE_PROC_FS |
56caf160 | 4547 | @findex USE_PROC_FS |
c906108c | 4548 | This determines whether small routines in @file{*-tdep.c}, which |
56caf160 EZ |
4549 | translate register values between @value{GDBN}'s internal |
4550 | representation and the @file{/proc} representation, are compiled. | |
c906108c SS |
4551 | |
4552 | @item U_REGS_OFFSET | |
56caf160 | 4553 | @findex U_REGS_OFFSET |
c906108c SS |
4554 | This is the offset of the registers in the upage. It need only be |
4555 | defined if the generic ptrace register access routines in | |
4556 | @file{infptrace.c} are being used (that is, @file{infptrace.c} is | |
4557 | configured in, and @code{FETCH_INFERIOR_REGISTERS} is not defined). If | |
4558 | the default value from @file{infptrace.c} is good enough, leave it | |
4559 | undefined. | |
4560 | ||
4561 | The default value means that u.u_ar0 @emph{points to} the location of | |
4562 | the registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means | |
56caf160 | 4563 | that @code{u.u_ar0} @emph{is} the location of the registers. |
c906108c SS |
4564 | |
4565 | @item CLEAR_SOLIB | |
56caf160 EZ |
4566 | @findex CLEAR_SOLIB |
4567 | See @file{objfiles.c}. | |
c906108c SS |
4568 | |
4569 | @item DEBUG_PTRACE | |
56caf160 EZ |
4570 | @findex DEBUG_PTRACE |
4571 | Define this to debug @code{ptrace} calls. | |
c906108c SS |
4572 | @end table |
4573 | ||
4574 | ||
4575 | @node Support Libraries | |
4576 | ||
4577 | @chapter Support Libraries | |
4578 | ||
4579 | @section BFD | |
56caf160 | 4580 | @cindex BFD library |
c906108c | 4581 | |
25822942 | 4582 | BFD provides support for @value{GDBN} in several ways: |
c906108c SS |
4583 | |
4584 | @table @emph | |
c906108c SS |
4585 | @item identifying executable and core files |
4586 | BFD will identify a variety of file types, including a.out, coff, and | |
4587 | several variants thereof, as well as several kinds of core files. | |
4588 | ||
4589 | @item access to sections of files | |
4590 | BFD parses the file headers to determine the names, virtual addresses, | |
4591 | sizes, and file locations of all the various named sections in files | |
56caf160 EZ |
4592 | (such as the text section or the data section). @value{GDBN} simply |
4593 | calls BFD to read or write section @var{x} at byte offset @var{y} for | |
4594 | length @var{z}. | |
c906108c SS |
4595 | |
4596 | @item specialized core file support | |
4597 | BFD provides routines to determine the failing command name stored in a | |
4598 | core file, the signal with which the program failed, and whether a core | |
56caf160 | 4599 | file matches (i.e.@: could be a core dump of) a particular executable |
c906108c SS |
4600 | file. |
4601 | ||
4602 | @item locating the symbol information | |
25822942 DB |
4603 | @value{GDBN} uses an internal interface of BFD to determine where to find the |
4604 | symbol information in an executable file or symbol-file. @value{GDBN} itself | |
c906108c | 4605 | handles the reading of symbols, since BFD does not ``understand'' debug |
25822942 | 4606 | symbols, but @value{GDBN} uses BFD's cached information to find the symbols, |
c906108c | 4607 | string table, etc. |
c906108c SS |
4608 | @end table |
4609 | ||
4610 | @section opcodes | |
56caf160 | 4611 | @cindex opcodes library |
c906108c | 4612 | |
25822942 | 4613 | The opcodes library provides @value{GDBN}'s disassembler. (It's a separate |
c906108c SS |
4614 | library because it's also used in binutils, for @file{objdump}). |
4615 | ||
4616 | @section readline | |
4617 | ||
4618 | @section mmalloc | |
4619 | ||
4620 | @section libiberty | |
1eb288ea EZ |
4621 | @cindex @code{libiberty} library |
4622 | ||
4623 | The @code{libiberty} library provides a set of functions and features | |
4624 | that integrate and improve on functionality found in modern operating | |
4625 | systems. Broadly speaking, such features can be divided into three | |
4626 | groups: supplemental functions (functions that may be missing in some | |
4627 | environments and operating systems), replacement functions (providing | |
4628 | a uniform and easier to use interface for commonly used standard | |
4629 | functions), and extensions (which provide additional functionality | |
4630 | beyond standard functions). | |
4631 | ||
4632 | @value{GDBN} uses various features provided by the @code{libiberty} | |
4633 | library, for instance the C@t{++} demangler, the @acronym{IEEE} | |
4634 | floating format support functions, the input options parser | |
4635 | @samp{getopt}, the @samp{obstack} extension, and other functions. | |
4636 | ||
4637 | @subsection @code{obstacks} in @value{GDBN} | |
4638 | @cindex @code{obstacks} | |
4639 | ||
4640 | The obstack mechanism provides a convenient way to allocate and free | |
4641 | chunks of memory. Each obstack is a pool of memory that is managed | |
4642 | like a stack. Objects (of any nature, size and alignment) are | |
4643 | allocated and freed in a @acronym{LIFO} fashion on an obstack (see | |
4644 | @code{libiberty}'s documenatation for a more detailed explanation of | |
4645 | @code{obstacks}). | |
4646 | ||
4647 | The most noticeable use of the @code{obstacks} in @value{GDBN} is in | |
4648 | object files. There is an obstack associated with each internal | |
4649 | representation of an object file. Lots of things get allocated on | |
4650 | these @code{obstacks}: dictionary entries, blocks, blockvectors, | |
4651 | symbols, minimal symbols, types, vectors of fundamental types, class | |
4652 | fields of types, object files section lists, object files section | |
4653 | offets lists, line tables, symbol tables, partial symbol tables, | |
4654 | string tables, symbol table private data, macros tables, debug | |
4655 | information sections and entries, import and export lists (som), | |
4656 | unwind information (hppa), dwarf2 location expressions data. Plus | |
4657 | various strings such as directory names strings, debug format strings, | |
4658 | names of types. | |
4659 | ||
4660 | An essential and convenient property of all data on @code{obstacks} is | |
4661 | that memory for it gets allocated (with @code{obstack_alloc}) at | |
4662 | various times during a debugging sesssion, but it is released all at | |
4663 | once using the @code{obstack_free} function. The @code{obstack_free} | |
4664 | function takes a pointer to where in the stack it must start the | |
4665 | deletion from (much like the cleanup chains have a pointer to where to | |
4666 | start the cleanups). Because of the stack like structure of the | |
4667 | @code{obstacks}, this allows to free only a top portion of the | |
4668 | obstack. There are a few instances in @value{GDBN} where such thing | |
4669 | happens. Calls to @code{obstack_free} are done after some local data | |
4670 | is allocated to the obstack. Only the local data is deleted from the | |
4671 | obstack. Of course this assumes that nothing between the | |
4672 | @code{obstack_alloc} and the @code{obstack_free} allocates anything | |
4673 | else on the same obstack. For this reason it is best and safest to | |
4674 | use temporary @code{obstacks}. | |
4675 | ||
4676 | Releasing the whole obstack is also not safe per se. It is safe only | |
4677 | under the condition that we know the @code{obstacks} memory is no | |
4678 | longer needed. In @value{GDBN} we get rid of the @code{obstacks} only | |
4679 | when we get rid of the whole objfile(s), for instance upon reading a | |
4680 | new symbol file. | |
c906108c SS |
4681 | |
4682 | @section gnu-regex | |
56caf160 | 4683 | @cindex regular expressions library |
c906108c SS |
4684 | |
4685 | Regex conditionals. | |
4686 | ||
4687 | @table @code | |
c906108c SS |
4688 | @item C_ALLOCA |
4689 | ||
4690 | @item NFAILURES | |
4691 | ||
4692 | @item RE_NREGS | |
4693 | ||
4694 | @item SIGN_EXTEND_CHAR | |
4695 | ||
4696 | @item SWITCH_ENUM_BUG | |
4697 | ||
4698 | @item SYNTAX_TABLE | |
4699 | ||
4700 | @item Sword | |
4701 | ||
4702 | @item sparc | |
c906108c SS |
4703 | @end table |
4704 | ||
4705 | @section include | |
4706 | ||
4707 | @node Coding | |
4708 | ||
4709 | @chapter Coding | |
4710 | ||
4711 | This chapter covers topics that are lower-level than the major | |
25822942 | 4712 | algorithms of @value{GDBN}. |
c906108c SS |
4713 | |
4714 | @section Cleanups | |
56caf160 | 4715 | @cindex cleanups |
c906108c SS |
4716 | |
4717 | Cleanups are a structured way to deal with things that need to be done | |
cc1cb004 | 4718 | later. |
c906108c | 4719 | |
cc1cb004 AC |
4720 | When your code does something (e.g., @code{xmalloc} some memory, or |
4721 | @code{open} a file) that needs to be undone later (e.g., @code{xfree} | |
4722 | the memory or @code{close} the file), it can make a cleanup. The | |
4723 | cleanup will be done at some future point: when the command is finished | |
4724 | and control returns to the top level; when an error occurs and the stack | |
4725 | is unwound; or when your code decides it's time to explicitly perform | |
4726 | cleanups. Alternatively you can elect to discard the cleanups you | |
4727 | created. | |
c906108c SS |
4728 | |
4729 | Syntax: | |
4730 | ||
4731 | @table @code | |
c906108c SS |
4732 | @item struct cleanup *@var{old_chain}; |
4733 | Declare a variable which will hold a cleanup chain handle. | |
4734 | ||
56caf160 | 4735 | @findex make_cleanup |
c906108c SS |
4736 | @item @var{old_chain} = make_cleanup (@var{function}, @var{arg}); |
4737 | Make a cleanup which will cause @var{function} to be called with | |
4738 | @var{arg} (a @code{char *}) later. The result, @var{old_chain}, is a | |
cc1cb004 AC |
4739 | handle that can later be passed to @code{do_cleanups} or |
4740 | @code{discard_cleanups}. Unless you are going to call | |
4741 | @code{do_cleanups} or @code{discard_cleanups}, you can ignore the result | |
4742 | from @code{make_cleanup}. | |
c906108c | 4743 | |
56caf160 | 4744 | @findex do_cleanups |
c906108c | 4745 | @item do_cleanups (@var{old_chain}); |
cc1cb004 AC |
4746 | Do all cleanups added to the chain since the corresponding |
4747 | @code{make_cleanup} call was made. | |
4748 | ||
4749 | @findex discard_cleanups | |
4750 | @item discard_cleanups (@var{old_chain}); | |
4751 | Same as @code{do_cleanups} except that it just removes the cleanups from | |
4752 | the chain and does not call the specified functions. | |
4753 | @end table | |
4754 | ||
4755 | Cleanups are implemented as a chain. The handle returned by | |
4756 | @code{make_cleanups} includes the cleanup passed to the call and any | |
4757 | later cleanups appended to the chain (but not yet discarded or | |
4758 | performed). E.g.: | |
56caf160 | 4759 | |
474c8240 | 4760 | @smallexample |
c906108c | 4761 | make_cleanup (a, 0); |
cc1cb004 AC |
4762 | @{ |
4763 | struct cleanup *old = make_cleanup (b, 0); | |
4764 | make_cleanup (c, 0) | |
4765 | ... | |
4766 | do_cleanups (old); | |
4767 | @} | |
474c8240 | 4768 | @end smallexample |
56caf160 | 4769 | |
c906108c | 4770 | @noindent |
cc1cb004 AC |
4771 | will call @code{c()} and @code{b()} but will not call @code{a()}. The |
4772 | cleanup that calls @code{a()} will remain in the cleanup chain, and will | |
4773 | be done later unless otherwise discarded.@refill | |
4774 | ||
4775 | Your function should explicitly do or discard the cleanups it creates. | |
4776 | Failing to do this leads to non-deterministic behavior since the caller | |
4777 | will arbitrarily do or discard your functions cleanups. This need leads | |
4778 | to two common cleanup styles. | |
4779 | ||
4780 | The first style is try/finally. Before it exits, your code-block calls | |
4781 | @code{do_cleanups} with the old cleanup chain and thus ensures that your | |
4782 | code-block's cleanups are always performed. For instance, the following | |
4783 | code-segment avoids a memory leak problem (even when @code{error} is | |
4784 | called and a forced stack unwind occurs) by ensuring that the | |
4785 | @code{xfree} will always be called: | |
c906108c | 4786 | |
474c8240 | 4787 | @smallexample |
cc1cb004 AC |
4788 | struct cleanup *old = make_cleanup (null_cleanup, 0); |
4789 | data = xmalloc (sizeof blah); | |
4790 | make_cleanup (xfree, data); | |
4791 | ... blah blah ... | |
4792 | do_cleanups (old); | |
474c8240 | 4793 | @end smallexample |
cc1cb004 AC |
4794 | |
4795 | The second style is try/except. Before it exits, your code-block calls | |
4796 | @code{discard_cleanups} with the old cleanup chain and thus ensures that | |
4797 | any created cleanups are not performed. For instance, the following | |
4798 | code segment, ensures that the file will be closed but only if there is | |
4799 | an error: | |
4800 | ||
474c8240 | 4801 | @smallexample |
cc1cb004 AC |
4802 | FILE *file = fopen ("afile", "r"); |
4803 | struct cleanup *old = make_cleanup (close_file, file); | |
4804 | ... blah blah ... | |
4805 | discard_cleanups (old); | |
4806 | return file; | |
474c8240 | 4807 | @end smallexample |
c906108c | 4808 | |
c1468174 | 4809 | Some functions, e.g., @code{fputs_filtered()} or @code{error()}, specify |
c906108c SS |
4810 | that they ``should not be called when cleanups are not in place''. This |
4811 | means that any actions you need to reverse in the case of an error or | |
4812 | interruption must be on the cleanup chain before you call these | |
4813 | functions, since they might never return to your code (they | |
4814 | @samp{longjmp} instead). | |
4815 | ||
ba8c9337 AC |
4816 | @section Per-architecture module data |
4817 | @cindex per-architecture module data | |
4818 | @cindex multi-arch data | |
4819 | @cindex data-pointer, per-architecture/per-module | |
4820 | ||
fc989b7a AC |
4821 | The multi-arch framework includes a mechanism for adding module |
4822 | specific per-architecture data-pointers to the @code{struct gdbarch} | |
4823 | architecture object. | |
4824 | ||
4825 | A module registers one or more per-architecture data-pointers using: | |
4826 | ||
4827 | @deftypefun struct gdbarch_data *gdbarch_data_register_pre_init (gdbarch_data_pre_init_ftype *@var{pre_init}) | |
4828 | @var{pre_init} is used to, on-demand, allocate an initial value for a | |
4829 | per-architecture data-pointer using the architecture's obstack (passed | |
4830 | in as a parameter). Since @var{pre_init} can be called during | |
4831 | architecture creation, it is not parameterized with the architecture. | |
4832 | and must not call modules that use per-architecture data. | |
4833 | @end deftypefun | |
ba8c9337 | 4834 | |
fc989b7a AC |
4835 | @deftypefun struct gdbarch_data *gdbarch_data_register_post_init (gdbarch_data_post_init_ftype *@var{post_init}) |
4836 | @var{post_init} is used to obtain an initial value for a | |
4837 | per-architecture data-pointer @emph{after}. Since @var{post_init} is | |
4838 | always called after architecture creation, it both receives the fully | |
4839 | initialized architecture and is free to call modules that use | |
4840 | per-architecture data (care needs to be taken to ensure that those | |
4841 | other modules do not try to call back to this module as that will | |
4842 | create in cycles in the initialization call graph). | |
4843 | @end deftypefun | |
ba8c9337 | 4844 | |
fc989b7a AC |
4845 | These functions return a @code{struct gdbarch_data} that is used to |
4846 | identify the per-architecture data-pointer added for that module. | |
ba8c9337 | 4847 | |
fc989b7a | 4848 | The per-architecture data-pointer is accessed using the function: |
ba8c9337 | 4849 | |
fc989b7a AC |
4850 | @deftypefun void *gdbarch_data (struct gdbarch *@var{gdbarch}, struct gdbarch_data *@var{data_handle}) |
4851 | Given the architecture @var{arch} and module data handle | |
4852 | @var{data_handle} (returned by @code{gdbarch_data_register_pre_init} | |
4853 | or @code{gdbarch_data_register_post_init}), this function returns the | |
4854 | current value of the per-architecture data-pointer. If the data | |
4855 | pointer is @code{NULL}, it is first initialized by calling the | |
4856 | corresponding @var{pre_init} or @var{post_init} method. | |
ba8c9337 AC |
4857 | @end deftypefun |
4858 | ||
fc989b7a | 4859 | The examples below assume the following definitions: |
ba8c9337 AC |
4860 | |
4861 | @smallexample | |
e7f16015 | 4862 | struct nozel @{ int total; @}; |
ba8c9337 | 4863 | static struct gdbarch_data *nozel_handle; |
ba8c9337 AC |
4864 | @end smallexample |
4865 | ||
fc989b7a AC |
4866 | A module can extend the architecture vector, adding additional |
4867 | per-architecture data, using the @var{pre_init} method. The module's | |
4868 | per-architecture data is then initialized during architecture | |
4869 | creation. | |
ba8c9337 | 4870 | |
fc989b7a AC |
4871 | In the below, the module's per-architecture @emph{nozel} is added. An |
4872 | architecture can specify its nozel by calling @code{set_gdbarch_nozel} | |
4873 | from @code{gdbarch_init}. | |
ba8c9337 AC |
4874 | |
4875 | @smallexample | |
fc989b7a AC |
4876 | static void * |
4877 | nozel_pre_init (struct obstack *obstack) | |
ba8c9337 | 4878 | @{ |
fc989b7a AC |
4879 | struct nozel *data = OBSTACK_ZALLOC (obstack, struct nozel); |
4880 | return data; | |
4881 | @} | |
ba8c9337 AC |
4882 | @end smallexample |
4883 | ||
ba8c9337 | 4884 | @smallexample |
fc989b7a AC |
4885 | extern void |
4886 | set_gdbarch_nozel (struct gdbarch *gdbarch, int total) | |
ba8c9337 | 4887 | @{ |
ba8c9337 | 4888 | struct nozel *data = gdbarch_data (gdbarch, nozel_handle); |
fc989b7a | 4889 | data->total = nozel; |
ba8c9337 AC |
4890 | @} |
4891 | @end smallexample | |
4892 | ||
fc989b7a AC |
4893 | A module can on-demand create architecture dependant data structures |
4894 | using @code{post_init}. | |
ba8c9337 | 4895 | |
fc989b7a AC |
4896 | In the below, the nozel's total is computed on-demand by |
4897 | @code{nozel_post_init} using information obtained from the | |
4898 | architecture. | |
ba8c9337 AC |
4899 | |
4900 | @smallexample | |
fc989b7a AC |
4901 | static void * |
4902 | nozel_post_init (struct gdbarch *gdbarch) | |
ba8c9337 | 4903 | @{ |
fc989b7a AC |
4904 | struct nozel *data = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct nozel); |
4905 | nozel->total = gdbarch@dots{} (gdbarch); | |
4906 | return data; | |
ba8c9337 AC |
4907 | @} |
4908 | @end smallexample | |
4909 | ||
4910 | @smallexample | |
fc989b7a AC |
4911 | extern int |
4912 | nozel_total (struct gdbarch *gdbarch) | |
ba8c9337 | 4913 | @{ |
fc989b7a AC |
4914 | struct nozel *data = gdbarch_data (gdbarch, nozel_handle); |
4915 | return data->total; | |
ba8c9337 AC |
4916 | @} |
4917 | @end smallexample | |
4918 | ||
c906108c | 4919 | @section Wrapping Output Lines |
56caf160 | 4920 | @cindex line wrap in output |
c906108c | 4921 | |
56caf160 | 4922 | @findex wrap_here |
c906108c SS |
4923 | Output that goes through @code{printf_filtered} or @code{fputs_filtered} |
4924 | or @code{fputs_demangled} needs only to have calls to @code{wrap_here} | |
4925 | added in places that would be good breaking points. The utility | |
4926 | routines will take care of actually wrapping if the line width is | |
4927 | exceeded. | |
4928 | ||
4929 | The argument to @code{wrap_here} is an indentation string which is | |
4930 | printed @emph{only} if the line breaks there. This argument is saved | |
4931 | away and used later. It must remain valid until the next call to | |
4932 | @code{wrap_here} or until a newline has been printed through the | |
4933 | @code{*_filtered} functions. Don't pass in a local variable and then | |
4934 | return! | |
4935 | ||
56caf160 | 4936 | It is usually best to call @code{wrap_here} after printing a comma or |
c906108c SS |
4937 | space. If you call it before printing a space, make sure that your |
4938 | indentation properly accounts for the leading space that will print if | |
4939 | the line wraps there. | |
4940 | ||
4941 | Any function or set of functions that produce filtered output must | |
4942 | finish by printing a newline, to flush the wrap buffer, before switching | |
56caf160 | 4943 | to unfiltered (@code{printf}) output. Symbol reading routines that |
c906108c SS |
4944 | print warnings are a good example. |
4945 | ||
25822942 | 4946 | @section @value{GDBN} Coding Standards |
56caf160 | 4947 | @cindex coding standards |
c906108c | 4948 | |
25822942 | 4949 | @value{GDBN} follows the GNU coding standards, as described in |
c906108c | 4950 | @file{etc/standards.texi}. This file is also available for anonymous |
af6c57ea AC |
4951 | FTP from GNU archive sites. @value{GDBN} takes a strict interpretation |
4952 | of the standard; in general, when the GNU standard recommends a practice | |
4953 | but does not require it, @value{GDBN} requires it. | |
c906108c | 4954 | |
56caf160 EZ |
4955 | @value{GDBN} follows an additional set of coding standards specific to |
4956 | @value{GDBN}, as described in the following sections. | |
c906108c | 4957 | |
af6c57ea | 4958 | |
b9aa90c9 | 4959 | @subsection ISO C |
af6c57ea | 4960 | |
b9aa90c9 AC |
4961 | @value{GDBN} assumes an ISO/IEC 9899:1990 (a.k.a.@: ISO C90) compliant |
4962 | compiler. | |
af6c57ea | 4963 | |
b9aa90c9 | 4964 | @value{GDBN} does not assume an ISO C or POSIX compliant C library. |
af6c57ea AC |
4965 | |
4966 | ||
4967 | @subsection Memory Management | |
4968 | ||
4969 | @value{GDBN} does not use the functions @code{malloc}, @code{realloc}, | |
4970 | @code{calloc}, @code{free} and @code{asprintf}. | |
4971 | ||
4972 | @value{GDBN} uses the functions @code{xmalloc}, @code{xrealloc} and | |
4973 | @code{xcalloc} when allocating memory. Unlike @code{malloc} et.al.@: | |
4974 | these functions do not return when the memory pool is empty. Instead, | |
4975 | they unwind the stack using cleanups. These functions return | |
4976 | @code{NULL} when requested to allocate a chunk of memory of size zero. | |
4977 | ||
4978 | @emph{Pragmatics: By using these functions, the need to check every | |
4979 | memory allocation is removed. These functions provide portable | |
4980 | behavior.} | |
4981 | ||
4982 | @value{GDBN} does not use the function @code{free}. | |
4983 | ||
4984 | @value{GDBN} uses the function @code{xfree} to return memory to the | |
4985 | memory pool. Consistent with ISO-C, this function ignores a request to | |
4986 | free a @code{NULL} pointer. | |
4987 | ||
4988 | @emph{Pragmatics: On some systems @code{free} fails when passed a | |
4989 | @code{NULL} pointer.} | |
4990 | ||
4991 | @value{GDBN} can use the non-portable function @code{alloca} for the | |
4992 | allocation of small temporary values (such as strings). | |
4993 | ||
4994 | @emph{Pragmatics: This function is very non-portable. Some systems | |
4995 | restrict the memory being allocated to no more than a few kilobytes.} | |
4996 | ||
4997 | @value{GDBN} uses the string function @code{xstrdup} and the print | |
b435e160 | 4998 | function @code{xstrprintf}. |
af6c57ea AC |
4999 | |
5000 | @emph{Pragmatics: @code{asprintf} and @code{strdup} can fail. Print | |
5001 | functions such as @code{sprintf} are very prone to buffer overflow | |
5002 | errors.} | |
5003 | ||
5004 | ||
5005 | @subsection Compiler Warnings | |
56caf160 | 5006 | @cindex compiler warnings |
af6c57ea AC |
5007 | |
5008 | With few exceptions, developers should include the configuration option | |
5009 | @samp{--enable-gdb-build-warnings=,-Werror} when building @value{GDBN}. | |
5010 | The exceptions are listed in the file @file{gdb/MAINTAINERS}. | |
5011 | ||
5012 | This option causes @value{GDBN} (when built using GCC) to be compiled | |
5013 | with a carefully selected list of compiler warning flags. Any warnings | |
5014 | from those flags being treated as errors. | |
5015 | ||
5016 | The current list of warning flags includes: | |
5017 | ||
5018 | @table @samp | |
5019 | @item -Wimplicit | |
5020 | Since @value{GDBN} coding standard requires all functions to be declared | |
5021 | using a prototype, the flag has the side effect of ensuring that | |
5022 | prototyped functions are always visible with out resorting to | |
5023 | @samp{-Wstrict-prototypes}. | |
5024 | ||
5025 | @item -Wreturn-type | |
5026 | Such code often appears to work except on instruction set architectures | |
5027 | that use register windows. | |
5028 | ||
5029 | @item -Wcomment | |
5030 | ||
5031 | @item -Wtrigraphs | |
5032 | ||
5033 | @item -Wformat | |
153721e6 | 5034 | @itemx -Wformat-nonliteral |
af6c57ea | 5035 | Since @value{GDBN} uses the @code{format printf} attribute on all |
153721e6 | 5036 | @code{printf} like functions these check not just @code{printf} calls |
af6c57ea AC |
5037 | but also calls to functions such as @code{fprintf_unfiltered}. |
5038 | ||
5039 | @item -Wparentheses | |
5040 | This warning includes uses of the assignment operator within an | |
5041 | @code{if} statement. | |
5042 | ||
5043 | @item -Wpointer-arith | |
5044 | ||
5045 | @item -Wuninitialized | |
0f0cffd2 AC |
5046 | |
5047 | @item -Wunused-label | |
5048 | This warning has the additional benefit of detecting the absence of the | |
5049 | @code{case} reserved word in a switch statement: | |
5050 | @smallexample | |
5051 | enum @{ FD_SCHEDULED, NOTHING_SCHEDULED @} sched; | |
5052 | @dots{} | |
5053 | switch (sched) | |
5054 | @{ | |
5055 | case FD_SCHEDULED: | |
5056 | @dots{}; | |
5057 | break; | |
5058 | NOTHING_SCHEDULED: | |
5059 | @dots{}; | |
5060 | break; | |
5061 | @} | |
5062 | @end smallexample | |
c9830293 AC |
5063 | |
5064 | @item -Wunused-function | |
7be93b9e JB |
5065 | |
5066 | @item -Wno-pointer-sign | |
5067 | In version 4.0, GCC began warning about pointer argument passing or | |
5068 | assignment even when the source and destination differed only in | |
5069 | signedness. However, most @value{GDBN} code doesn't distinguish | |
5070 | carefully between @code{char} and @code{unsigned char}. In early 2006 | |
5071 | the @value{GDBN} developers decided correcting these warnings wasn't | |
5072 | worth the time it would take. | |
5073 | ||
af6c57ea AC |
5074 | @end table |
5075 | ||
5076 | @emph{Pragmatics: Due to the way that @value{GDBN} is implemented most | |
5077 | functions have unused parameters. Consequently the warning | |
5078 | @samp{-Wunused-parameter} is precluded from the list. The macro | |
5079 | @code{ATTRIBUTE_UNUSED} is not used as it leads to false negatives --- | |
5080 | it is not an error to have @code{ATTRIBUTE_UNUSED} on a parameter that | |
5081 | is being used. The options @samp{-Wall} and @samp{-Wunused} are also | |
5082 | precluded because they both include @samp{-Wunused-parameter}.} | |
5083 | ||
5084 | @emph{Pragmatics: @value{GDBN} has not simply accepted the warnings | |
5085 | enabled by @samp{-Wall -Werror -W...}. Instead it is selecting warnings | |
5086 | when and where their benefits can be demonstrated.} | |
c906108c SS |
5087 | |
5088 | @subsection Formatting | |
5089 | ||
56caf160 | 5090 | @cindex source code formatting |
c906108c SS |
5091 | The standard GNU recommendations for formatting must be followed |
5092 | strictly. | |
5093 | ||
af6c57ea AC |
5094 | A function declaration should not have its name in column zero. A |
5095 | function definition should have its name in column zero. | |
5096 | ||
474c8240 | 5097 | @smallexample |
af6c57ea AC |
5098 | /* Declaration */ |
5099 | static void foo (void); | |
5100 | /* Definition */ | |
5101 | void | |
5102 | foo (void) | |
5103 | @{ | |
5104 | @} | |
474c8240 | 5105 | @end smallexample |
af6c57ea AC |
5106 | |
5107 | @emph{Pragmatics: This simplifies scripting. Function definitions can | |
5108 | be found using @samp{^function-name}.} | |
c906108c | 5109 | |
af6c57ea AC |
5110 | There must be a space between a function or macro name and the opening |
5111 | parenthesis of its argument list (except for macro definitions, as | |
5112 | required by C). There must not be a space after an open paren/bracket | |
5113 | or before a close paren/bracket. | |
c906108c SS |
5114 | |
5115 | While additional whitespace is generally helpful for reading, do not use | |
5116 | more than one blank line to separate blocks, and avoid adding whitespace | |
af6c57ea AC |
5117 | after the end of a program line (as of 1/99, some 600 lines had |
5118 | whitespace after the semicolon). Excess whitespace causes difficulties | |
5119 | for @code{diff} and @code{patch} utilities. | |
5120 | ||
5121 | Pointers are declared using the traditional K&R C style: | |
5122 | ||
474c8240 | 5123 | @smallexample |
af6c57ea | 5124 | void *foo; |
474c8240 | 5125 | @end smallexample |
af6c57ea AC |
5126 | |
5127 | @noindent | |
5128 | and not: | |
5129 | ||
474c8240 | 5130 | @smallexample |
af6c57ea AC |
5131 | void * foo; |
5132 | void* foo; | |
474c8240 | 5133 | @end smallexample |
c906108c SS |
5134 | |
5135 | @subsection Comments | |
5136 | ||
56caf160 | 5137 | @cindex comment formatting |
c906108c SS |
5138 | The standard GNU requirements on comments must be followed strictly. |
5139 | ||
af6c57ea AC |
5140 | Block comments must appear in the following form, with no @code{/*}- or |
5141 | @code{*/}-only lines, and no leading @code{*}: | |
c906108c | 5142 | |
474c8240 | 5143 | @smallexample |
c906108c SS |
5144 | /* Wait for control to return from inferior to debugger. If inferior |
5145 | gets a signal, we may decide to start it up again instead of | |
5146 | returning. That is why there is a loop in this function. When | |
5147 | this function actually returns it means the inferior should be left | |
25822942 | 5148 | stopped and @value{GDBN} should read more commands. */ |
474c8240 | 5149 | @end smallexample |
c906108c SS |
5150 | |
5151 | (Note that this format is encouraged by Emacs; tabbing for a multi-line | |
56caf160 | 5152 | comment works correctly, and @kbd{M-q} fills the block consistently.) |
c906108c SS |
5153 | |
5154 | Put a blank line between the block comments preceding function or | |
5155 | variable definitions, and the definition itself. | |
5156 | ||
5157 | In general, put function-body comments on lines by themselves, rather | |
5158 | than trying to fit them into the 20 characters left at the end of a | |
5159 | line, since either the comment or the code will inevitably get longer | |
5160 | than will fit, and then somebody will have to move it anyhow. | |
5161 | ||
5162 | @subsection C Usage | |
5163 | ||
56caf160 | 5164 | @cindex C data types |
c906108c SS |
5165 | Code must not depend on the sizes of C data types, the format of the |
5166 | host's floating point numbers, the alignment of anything, or the order | |
5167 | of evaluation of expressions. | |
5168 | ||
56caf160 | 5169 | @cindex function usage |
c906108c | 5170 | Use functions freely. There are only a handful of compute-bound areas |
56caf160 EZ |
5171 | in @value{GDBN} that might be affected by the overhead of a function |
5172 | call, mainly in symbol reading. Most of @value{GDBN}'s performance is | |
5173 | limited by the target interface (whether serial line or system call). | |
c906108c SS |
5174 | |
5175 | However, use functions with moderation. A thousand one-line functions | |
5176 | are just as hard to understand as a single thousand-line function. | |
5177 | ||
af6c57ea | 5178 | @emph{Macros are bad, M'kay.} |
9e678452 CF |
5179 | (But if you have to use a macro, make sure that the macro arguments are |
5180 | protected with parentheses.) | |
af6c57ea AC |
5181 | |
5182 | @cindex types | |
c906108c | 5183 | |
af6c57ea AC |
5184 | Declarations like @samp{struct foo *} should be used in preference to |
5185 | declarations like @samp{typedef struct foo @{ @dots{} @} *foo_ptr}. | |
5186 | ||
5187 | ||
5188 | @subsection Function Prototypes | |
56caf160 | 5189 | @cindex function prototypes |
af6c57ea AC |
5190 | |
5191 | Prototypes must be used when both @emph{declaring} and @emph{defining} | |
5192 | a function. Prototypes for @value{GDBN} functions must include both the | |
5193 | argument type and name, with the name matching that used in the actual | |
5194 | function definition. | |
c906108c | 5195 | |
53a5351d JM |
5196 | All external functions should have a declaration in a header file that |
5197 | callers include, except for @code{_initialize_*} functions, which must | |
5198 | be external so that @file{init.c} construction works, but shouldn't be | |
5199 | visible to random source files. | |
c906108c | 5200 | |
af6c57ea AC |
5201 | Where a source file needs a forward declaration of a static function, |
5202 | that declaration must appear in a block near the top of the source file. | |
5203 | ||
5204 | ||
5205 | @subsection Internal Error Recovery | |
5206 | ||
5207 | During its execution, @value{GDBN} can encounter two types of errors. | |
5208 | User errors and internal errors. User errors include not only a user | |
5209 | entering an incorrect command but also problems arising from corrupt | |
5210 | object files and system errors when interacting with the target. | |
937f164b FF |
5211 | Internal errors include situations where @value{GDBN} has detected, at |
5212 | run time, a corrupt or erroneous situation. | |
af6c57ea AC |
5213 | |
5214 | When reporting an internal error, @value{GDBN} uses | |
5215 | @code{internal_error} and @code{gdb_assert}. | |
5216 | ||
5217 | @value{GDBN} must not call @code{abort} or @code{assert}. | |
5218 | ||
5219 | @emph{Pragmatics: There is no @code{internal_warning} function. Either | |
5220 | the code detected a user error, recovered from it and issued a | |
5221 | @code{warning} or the code failed to correctly recover from the user | |
5222 | error and issued an @code{internal_error}.} | |
5223 | ||
5224 | @subsection File Names | |
5225 | ||
5226 | Any file used when building the core of @value{GDBN} must be in lower | |
5227 | case. Any file used when building the core of @value{GDBN} must be 8.3 | |
5228 | unique. These requirements apply to both source and generated files. | |
5229 | ||
5230 | @emph{Pragmatics: The core of @value{GDBN} must be buildable on many | |
5231 | platforms including DJGPP and MacOS/HFS. Every time an unfriendly file | |
5232 | is introduced to the build process both @file{Makefile.in} and | |
5233 | @file{configure.in} need to be modified accordingly. Compare the | |
5234 | convoluted conversion process needed to transform @file{COPYING} into | |
5235 | @file{copying.c} with the conversion needed to transform | |
5236 | @file{version.in} into @file{version.c}.} | |
5237 | ||
5238 | Any file non 8.3 compliant file (that is not used when building the core | |
5239 | of @value{GDBN}) must be added to @file{gdb/config/djgpp/fnchange.lst}. | |
5240 | ||
5241 | @emph{Pragmatics: This is clearly a compromise.} | |
5242 | ||
5243 | When @value{GDBN} has a local version of a system header file (ex | |
5244 | @file{string.h}) the file name based on the POSIX header prefixed with | |
b4177fca DJ |
5245 | @file{gdb_} (@file{gdb_string.h}). These headers should be relatively |
5246 | independent: they should use only macros defined by @file{configure}, | |
5247 | the compiler, or the host; they should include only system headers; they | |
5248 | should refer only to system types. They may be shared between multiple | |
5249 | programs, e.g.@: @value{GDBN} and @sc{gdbserver}. | |
af6c57ea AC |
5250 | |
5251 | For other files @samp{-} is used as the separator. | |
5252 | ||
5253 | ||
5254 | @subsection Include Files | |
5255 | ||
e2b28d04 | 5256 | A @file{.c} file should include @file{defs.h} first. |
af6c57ea | 5257 | |
e2b28d04 AC |
5258 | A @file{.c} file should directly include the @code{.h} file of every |
5259 | declaration and/or definition it directly refers to. It cannot rely on | |
5260 | indirect inclusion. | |
af6c57ea | 5261 | |
e2b28d04 AC |
5262 | A @file{.h} file should directly include the @code{.h} file of every |
5263 | declaration and/or definition it directly refers to. It cannot rely on | |
5264 | indirect inclusion. Exception: The file @file{defs.h} does not need to | |
5265 | be directly included. | |
af6c57ea | 5266 | |
e2b28d04 | 5267 | An external declaration should only appear in one include file. |
af6c57ea | 5268 | |
e2b28d04 AC |
5269 | An external declaration should never appear in a @code{.c} file. |
5270 | Exception: a declaration for the @code{_initialize} function that | |
5271 | pacifies @option{-Wmissing-declaration}. | |
5272 | ||
5273 | A @code{typedef} definition should only appear in one include file. | |
5274 | ||
5275 | An opaque @code{struct} declaration can appear in multiple @file{.h} | |
5276 | files. Where possible, a @file{.h} file should use an opaque | |
5277 | @code{struct} declaration instead of an include. | |
5278 | ||
5279 | All @file{.h} files should be wrapped in: | |
af6c57ea | 5280 | |
474c8240 | 5281 | @smallexample |
af6c57ea AC |
5282 | #ifndef INCLUDE_FILE_NAME_H |
5283 | #define INCLUDE_FILE_NAME_H | |
5284 | header body | |
5285 | #endif | |
474c8240 | 5286 | @end smallexample |
af6c57ea | 5287 | |
c906108c | 5288 | |
dab11f21 | 5289 | @subsection Clean Design and Portable Implementation |
c906108c | 5290 | |
56caf160 | 5291 | @cindex design |
c906108c | 5292 | In addition to getting the syntax right, there's the little question of |
25822942 | 5293 | semantics. Some things are done in certain ways in @value{GDBN} because long |
c906108c SS |
5294 | experience has shown that the more obvious ways caused various kinds of |
5295 | trouble. | |
5296 | ||
56caf160 | 5297 | @cindex assumptions about targets |
c906108c SS |
5298 | You can't assume the byte order of anything that comes from a target |
5299 | (including @var{value}s, object files, and instructions). Such things | |
56caf160 EZ |
5300 | must be byte-swapped using @code{SWAP_TARGET_AND_HOST} in |
5301 | @value{GDBN}, or one of the swap routines defined in @file{bfd.h}, | |
5302 | such as @code{bfd_get_32}. | |
c906108c SS |
5303 | |
5304 | You can't assume that you know what interface is being used to talk to | |
5305 | the target system. All references to the target must go through the | |
5306 | current @code{target_ops} vector. | |
5307 | ||
5308 | You can't assume that the host and target machines are the same machine | |
5309 | (except in the ``native'' support modules). In particular, you can't | |
5310 | assume that the target machine's header files will be available on the | |
5311 | host machine. Target code must bring along its own header files -- | |
5312 | written from scratch or explicitly donated by their owner, to avoid | |
5313 | copyright problems. | |
5314 | ||
56caf160 | 5315 | @cindex portability |
c906108c SS |
5316 | Insertion of new @code{#ifdef}'s will be frowned upon. It's much better |
5317 | to write the code portably than to conditionalize it for various | |
5318 | systems. | |
5319 | ||
56caf160 | 5320 | @cindex system dependencies |
c906108c SS |
5321 | New @code{#ifdef}'s which test for specific compilers or manufacturers |
5322 | or operating systems are unacceptable. All @code{#ifdef}'s should test | |
5323 | for features. The information about which configurations contain which | |
5324 | features should be segregated into the configuration files. Experience | |
5325 | has proven far too often that a feature unique to one particular system | |
5326 | often creeps into other systems; and that a conditional based on some | |
5327 | predefined macro for your current system will become worthless over | |
5328 | time, as new versions of your system come out that behave differently | |
5329 | with regard to this feature. | |
5330 | ||
5331 | Adding code that handles specific architectures, operating systems, | |
af6c57ea | 5332 | target interfaces, or hosts, is not acceptable in generic code. |
c906108c | 5333 | |
dab11f21 EZ |
5334 | @cindex portable file name handling |
5335 | @cindex file names, portability | |
5336 | One particularly notorious area where system dependencies tend to | |
5337 | creep in is handling of file names. The mainline @value{GDBN} code | |
5338 | assumes Posix semantics of file names: absolute file names begin with | |
5339 | a forward slash @file{/}, slashes are used to separate leading | |
5340 | directories, case-sensitive file names. These assumptions are not | |
5341 | necessarily true on non-Posix systems such as MS-Windows. To avoid | |
5342 | system-dependent code where you need to take apart or construct a file | |
5343 | name, use the following portable macros: | |
5344 | ||
5345 | @table @code | |
5346 | @findex HAVE_DOS_BASED_FILE_SYSTEM | |
5347 | @item HAVE_DOS_BASED_FILE_SYSTEM | |
5348 | This preprocessing symbol is defined to a non-zero value on hosts | |
5349 | whose filesystems belong to the MS-DOS/MS-Windows family. Use this | |
5350 | symbol to write conditional code which should only be compiled for | |
5351 | such hosts. | |
5352 | ||
5353 | @findex IS_DIR_SEPARATOR | |
4be31470 | 5354 | @item IS_DIR_SEPARATOR (@var{c}) |
dab11f21 EZ |
5355 | Evaluates to a non-zero value if @var{c} is a directory separator |
5356 | character. On Unix and GNU/Linux systems, only a slash @file{/} is | |
5357 | such a character, but on Windows, both @file{/} and @file{\} will | |
5358 | pass. | |
5359 | ||
5360 | @findex IS_ABSOLUTE_PATH | |
5361 | @item IS_ABSOLUTE_PATH (@var{file}) | |
5362 | Evaluates to a non-zero value if @var{file} is an absolute file name. | |
5363 | For Unix and GNU/Linux hosts, a name which begins with a slash | |
5364 | @file{/} is absolute. On DOS and Windows, @file{d:/foo} and | |
5365 | @file{x:\bar} are also absolute file names. | |
5366 | ||
5367 | @findex FILENAME_CMP | |
5368 | @item FILENAME_CMP (@var{f1}, @var{f2}) | |
5369 | Calls a function which compares file names @var{f1} and @var{f2} as | |
5370 | appropriate for the underlying host filesystem. For Posix systems, | |
5371 | this simply calls @code{strcmp}; on case-insensitive filesystems it | |
5372 | will call @code{strcasecmp} instead. | |
5373 | ||
5374 | @findex DIRNAME_SEPARATOR | |
5375 | @item DIRNAME_SEPARATOR | |
5376 | Evaluates to a character which separates directories in | |
5377 | @code{PATH}-style lists, typically held in environment variables. | |
5378 | This character is @samp{:} on Unix, @samp{;} on DOS and Windows. | |
5379 | ||
5380 | @findex SLASH_STRING | |
5381 | @item SLASH_STRING | |
5382 | This evaluates to a constant string you should use to produce an | |
5383 | absolute filename from leading directories and the file's basename. | |
5384 | @code{SLASH_STRING} is @code{"/"} on most systems, but might be | |
5385 | @code{"\\"} for some Windows-based ports. | |
5386 | @end table | |
5387 | ||
5388 | In addition to using these macros, be sure to use portable library | |
5389 | functions whenever possible. For example, to extract a directory or a | |
5390 | basename part from a file name, use the @code{dirname} and | |
5391 | @code{basename} library functions (available in @code{libiberty} for | |
5392 | platforms which don't provide them), instead of searching for a slash | |
5393 | with @code{strrchr}. | |
5394 | ||
25822942 DB |
5395 | Another way to generalize @value{GDBN} along a particular interface is with an |
5396 | attribute struct. For example, @value{GDBN} has been generalized to handle | |
56caf160 EZ |
5397 | multiple kinds of remote interfaces---not by @code{#ifdef}s everywhere, but |
5398 | by defining the @code{target_ops} structure and having a current target (as | |
c906108c SS |
5399 | well as a stack of targets below it, for memory references). Whenever |
5400 | something needs to be done that depends on which remote interface we are | |
56caf160 EZ |
5401 | using, a flag in the current target_ops structure is tested (e.g., |
5402 | @code{target_has_stack}), or a function is called through a pointer in the | |
c906108c | 5403 | current target_ops structure. In this way, when a new remote interface |
56caf160 | 5404 | is added, only one module needs to be touched---the one that actually |
c906108c SS |
5405 | implements the new remote interface. Other examples of |
5406 | attribute-structs are BFD access to multiple kinds of object file | |
25822942 | 5407 | formats, or @value{GDBN}'s access to multiple source languages. |
c906108c | 5408 | |
56caf160 EZ |
5409 | Please avoid duplicating code. For example, in @value{GDBN} 3.x all |
5410 | the code interfacing between @code{ptrace} and the rest of | |
5411 | @value{GDBN} was duplicated in @file{*-dep.c}, and so changing | |
5412 | something was very painful. In @value{GDBN} 4.x, these have all been | |
5413 | consolidated into @file{infptrace.c}. @file{infptrace.c} can deal | |
5414 | with variations between systems the same way any system-independent | |
5415 | file would (hooks, @code{#if defined}, etc.), and machines which are | |
5416 | radically different don't need to use @file{infptrace.c} at all. | |
c906108c | 5417 | |
af6c57ea AC |
5418 | All debugging code must be controllable using the @samp{set debug |
5419 | @var{module}} command. Do not use @code{printf} to print trace | |
5420 | messages. Use @code{fprintf_unfiltered(gdb_stdlog, ...}. Do not use | |
5421 | @code{#ifdef DEBUG}. | |
5422 | ||
c906108c | 5423 | |
8487521e | 5424 | @node Porting GDB |
c906108c | 5425 | |
25822942 | 5426 | @chapter Porting @value{GDBN} |
56caf160 | 5427 | @cindex porting to new machines |
c906108c | 5428 | |
56caf160 EZ |
5429 | Most of the work in making @value{GDBN} compile on a new machine is in |
5430 | specifying the configuration of the machine. This is done in a | |
5431 | dizzying variety of header files and configuration scripts, which we | |
5432 | hope to make more sensible soon. Let's say your new host is called an | |
5433 | @var{xyz} (e.g., @samp{sun4}), and its full three-part configuration | |
5434 | name is @code{@var{arch}-@var{xvend}-@var{xos}} (e.g., | |
5435 | @samp{sparc-sun-sunos4}). In particular: | |
c906108c | 5436 | |
56caf160 EZ |
5437 | @itemize @bullet |
5438 | @item | |
c906108c SS |
5439 | In the top level directory, edit @file{config.sub} and add @var{arch}, |
5440 | @var{xvend}, and @var{xos} to the lists of supported architectures, | |
5441 | vendors, and operating systems near the bottom of the file. Also, add | |
5442 | @var{xyz} as an alias that maps to | |
5443 | @code{@var{arch}-@var{xvend}-@var{xos}}. You can test your changes by | |
5444 | running | |
5445 | ||
474c8240 | 5446 | @smallexample |
c906108c | 5447 | ./config.sub @var{xyz} |
474c8240 | 5448 | @end smallexample |
56caf160 | 5449 | |
c906108c SS |
5450 | @noindent |
5451 | and | |
56caf160 | 5452 | |
474c8240 | 5453 | @smallexample |
c906108c | 5454 | ./config.sub @code{@var{arch}-@var{xvend}-@var{xos}} |
474c8240 | 5455 | @end smallexample |
56caf160 | 5456 | |
c906108c SS |
5457 | @noindent |
5458 | which should both respond with @code{@var{arch}-@var{xvend}-@var{xos}} | |
5459 | and no error messages. | |
5460 | ||
56caf160 | 5461 | @noindent |
c906108c SS |
5462 | You need to port BFD, if that hasn't been done already. Porting BFD is |
5463 | beyond the scope of this manual. | |
5464 | ||
56caf160 | 5465 | @item |
25822942 | 5466 | To configure @value{GDBN} itself, edit @file{gdb/configure.host} to recognize |
c906108c SS |
5467 | your system and set @code{gdb_host} to @var{xyz}, and (unless your |
5468 | desired target is already available) also edit @file{gdb/configure.tgt}, | |
5469 | setting @code{gdb_target} to something appropriate (for instance, | |
5470 | @var{xyz}). | |
5471 | ||
7fd60527 AC |
5472 | @emph{Maintainer's note: Work in progress. The file |
5473 | @file{gdb/configure.host} originally needed to be modified when either a | |
5474 | new native target or a new host machine was being added to @value{GDBN}. | |
5475 | Recent changes have removed this requirement. The file now only needs | |
5476 | to be modified when adding a new native configuration. This will likely | |
5477 | changed again in the future.} | |
5478 | ||
56caf160 | 5479 | @item |
25822942 | 5480 | Finally, you'll need to specify and define @value{GDBN}'s host-, native-, and |
c906108c SS |
5481 | target-dependent @file{.h} and @file{.c} files used for your |
5482 | configuration. | |
56caf160 | 5483 | @end itemize |
c906108c | 5484 | |
d52fe014 AC |
5485 | @node Versions and Branches |
5486 | @chapter Versions and Branches | |
8973da3a | 5487 | |
d52fe014 | 5488 | @section Versions |
8973da3a | 5489 | |
d52fe014 AC |
5490 | @value{GDBN}'s version is determined by the file |
5491 | @file{gdb/version.in} and takes one of the following forms: | |
fb0ff88f | 5492 | |
d52fe014 AC |
5493 | @table @asis |
5494 | @item @var{major}.@var{minor} | |
5495 | @itemx @var{major}.@var{minor}.@var{patchlevel} | |
53531fc1 AC |
5496 | an official release (e.g., 6.2 or 6.2.1) |
5497 | @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD} | |
5498 | a snapshot taken at @var{YYYY}-@var{MM}-@var{DD}-gmt (e.g., | |
5499 | 6.1.50.20020302, 6.1.90.20020304, or 6.1.0.20020308) | |
5500 | @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}-cvs | |
5501 | a @sc{cvs} check out drawn on @var{YYYY}-@var{MM}-@var{DD} (e.g., | |
5502 | 6.1.50.20020302-cvs, 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs) | |
5503 | @item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD} (@var{vendor}) | |
d52fe014 | 5504 | a vendor specific release of @value{GDBN}, that while based on@* |
53531fc1 AC |
5505 | @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}, |
5506 | may include additional changes | |
d52fe014 | 5507 | @end table |
fb0ff88f | 5508 | |
d52fe014 AC |
5509 | @value{GDBN}'s mainline uses the @var{major} and @var{minor} version |
5510 | numbers from the most recent release branch, with a @var{patchlevel} | |
53531fc1 AC |
5511 | of 50. At the time each new release branch is created, the mainline's |
5512 | @var{major} and @var{minor} version numbers are updated. | |
fb0ff88f | 5513 | |
53531fc1 AC |
5514 | @value{GDBN}'s release branch is similar. When the branch is cut, the |
5515 | @var{patchlevel} is changed from 50 to 90. As draft releases are | |
5516 | drawn from the branch, the @var{patchlevel} is incremented. Once the | |
5517 | first release (@var{major}.@var{minor}) has been made, the | |
5518 | @var{patchlevel} is set to 0 and updates have an incremented | |
5519 | @var{patchlevel}. | |
5520 | ||
5521 | For snapshots, and @sc{cvs} check outs, it is also possible to | |
5522 | identify the @sc{cvs} origin: | |
5523 | ||
5524 | @table @asis | |
5525 | @item @var{major}.@var{minor}.50.@var{YYYY}@var{MM}@var{DD} | |
5526 | drawn from the @sc{head} of mainline @sc{cvs} (e.g., 6.1.50.20020302) | |
5527 | @item @var{major}.@var{minor}.90.@var{YYYY}@var{MM}@var{DD} | |
5528 | @itemx @var{major}.@var{minor}.91.@var{YYYY}@var{MM}@var{DD} @dots{} | |
5529 | drawn from a release branch prior to the release (e.g., | |
5530 | 6.1.90.20020304) | |
5531 | @item @var{major}.@var{minor}.0.@var{YYYY}@var{MM}@var{DD} | |
5532 | @itemx @var{major}.@var{minor}.1.@var{YYYY}@var{MM}@var{DD} @dots{} | |
5533 | drawn from a release branch after the release (e.g., 6.2.0.20020308) | |
5534 | @end table | |
fb0ff88f | 5535 | |
d52fe014 AC |
5536 | If the previous @value{GDBN} version is 6.1 and the current version is |
5537 | 6.2, then, substituting 6 for @var{major} and 1 or 2 for @var{minor}, | |
5538 | here's an illustration of a typical sequence: | |
fb0ff88f | 5539 | |
d52fe014 AC |
5540 | @smallexample |
5541 | <HEAD> | |
5542 | | | |
53531fc1 | 5543 | 6.1.50.20020302-cvs |
d52fe014 | 5544 | | |
53531fc1 | 5545 | +--------------------------. |
d52fe014 | 5546 | | <gdb_6_2-branch> |
d52fe014 | 5547 | | | |
53531fc1 AC |
5548 | 6.2.50.20020303-cvs 6.1.90 (draft #1) |
5549 | | | | |
5550 | 6.2.50.20020304-cvs 6.1.90.20020304-cvs | |
5551 | | | | |
5552 | 6.2.50.20020305-cvs 6.1.91 (draft #2) | |
d52fe014 | 5553 | | | |
53531fc1 AC |
5554 | 6.2.50.20020306-cvs 6.1.91.20020306-cvs |
5555 | | | | |
5556 | 6.2.50.20020307-cvs 6.2 (release) | |
5557 | | | | |
5558 | 6.2.50.20020308-cvs 6.2.0.20020308-cvs | |
5559 | | | | |
5560 | 6.2.50.20020309-cvs 6.2.1 (update) | |
5561 | | | | |
5562 | 6.2.50.20020310-cvs <branch closed> | |
d52fe014 | 5563 | | |
53531fc1 | 5564 | 6.2.50.20020311-cvs |
d52fe014 | 5565 | | |
53531fc1 | 5566 | +--------------------------. |
d52fe014 | 5567 | | <gdb_6_3-branch> |
53531fc1 AC |
5568 | | | |
5569 | 6.3.50.20020312-cvs 6.2.90 (draft #1) | |
5570 | | | | |
d52fe014 | 5571 | @end smallexample |
fb0ff88f | 5572 | |
d52fe014 AC |
5573 | @section Release Branches |
5574 | @cindex Release Branches | |
fb0ff88f | 5575 | |
d52fe014 AC |
5576 | @value{GDBN} draws a release series (6.2, 6.2.1, @dots{}) from a |
5577 | single release branch, and identifies that branch using the @sc{cvs} | |
5578 | branch tags: | |
fb0ff88f | 5579 | |
d52fe014 AC |
5580 | @smallexample |
5581 | gdb_@var{major}_@var{minor}-@var{YYYY}@var{MM}@var{DD}-branchpoint | |
5582 | gdb_@var{major}_@var{minor}-branch | |
5583 | gdb_@var{major}_@var{minor}-@var{YYYY}@var{MM}@var{DD}-release | |
5584 | @end smallexample | |
5585 | ||
5586 | @emph{Pragmatics: To help identify the date at which a branch or | |
5587 | release is made, both the branchpoint and release tags include the | |
5588 | date that they are cut (@var{YYYY}@var{MM}@var{DD}) in the tag. The | |
5589 | branch tag, denoting the head of the branch, does not need this.} | |
5590 | ||
5591 | @section Vendor Branches | |
5592 | @cindex vendor branches | |
fb0ff88f AC |
5593 | |
5594 | To avoid version conflicts, vendors are expected to modify the file | |
5595 | @file{gdb/version.in} to include a vendor unique alphabetic identifier | |
5596 | (an official @value{GDBN} release never uses alphabetic characters in | |
d52fe014 AC |
5597 | its version identifer). E.g., @samp{6.2widgit2}, or @samp{6.2 (Widgit |
5598 | Inc Patch 2)}. | |
5599 | ||
5600 | @section Experimental Branches | |
5601 | @cindex experimental branches | |
5602 | ||
5603 | @subsection Guidelines | |
5604 | ||
5605 | @value{GDBN} permits the creation of branches, cut from the @sc{cvs} | |
5606 | repository, for experimental development. Branches make it possible | |
5607 | for developers to share preliminary work, and maintainers to examine | |
5608 | significant new developments. | |
fb0ff88f | 5609 | |
d52fe014 | 5610 | The following are a set of guidelines for creating such branches: |
fb0ff88f | 5611 | |
d52fe014 AC |
5612 | @table @emph |
5613 | ||
5614 | @item a branch has an owner | |
5615 | The owner can set further policy for a branch, but may not change the | |
5616 | ground rules. In particular, they can set a policy for commits (be it | |
5617 | adding more reviewers or deciding who can commit). | |
5618 | ||
5619 | @item all commits are posted | |
5620 | All changes committed to a branch shall also be posted to | |
5621 | @email{gdb-patches@@sources.redhat.com, the @value{GDBN} patches | |
5622 | mailing list}. While commentary on such changes are encouraged, people | |
5623 | should remember that the changes only apply to a branch. | |
5624 | ||
5625 | @item all commits are covered by an assignment | |
5626 | This ensures that all changes belong to the Free Software Foundation, | |
5627 | and avoids the possibility that the branch may become contaminated. | |
5628 | ||
5629 | @item a branch is focused | |
5630 | A focused branch has a single objective or goal, and does not contain | |
5631 | unnecessary or irrelevant changes. Cleanups, where identified, being | |
5632 | be pushed into the mainline as soon as possible. | |
5633 | ||
5634 | @item a branch tracks mainline | |
5635 | This keeps the level of divergence under control. It also keeps the | |
5636 | pressure on developers to push cleanups and other stuff into the | |
5637 | mainline. | |
5638 | ||
5639 | @item a branch shall contain the entire @value{GDBN} module | |
5640 | The @value{GDBN} module @code{gdb} should be specified when creating a | |
5641 | branch (branches of individual files should be avoided). @xref{Tags}. | |
5642 | ||
5643 | @item a branch shall be branded using @file{version.in} | |
5644 | The file @file{gdb/version.in} shall be modified so that it identifies | |
5645 | the branch @var{owner} and branch @var{name}, e.g., | |
53531fc1 | 5646 | @samp{6.2.50.20030303_owner_name} or @samp{6.2 (Owner Name)}. |
d52fe014 AC |
5647 | |
5648 | @end table | |
fb0ff88f | 5649 | |
d52fe014 AC |
5650 | @subsection Tags |
5651 | @anchor{Tags} | |
fb0ff88f | 5652 | |
d52fe014 AC |
5653 | To simplify the identification of @value{GDBN} branches, the following |
5654 | branch tagging convention is strongly recommended: | |
fb0ff88f | 5655 | |
d52fe014 | 5656 | @table @code |
fb0ff88f | 5657 | |
d52fe014 AC |
5658 | @item @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint |
5659 | @itemx @var{owner}_@var{name}-@var{YYYYMMDD}-branch | |
5660 | The branch point and corresponding branch tag. @var{YYYYMMDD} is the | |
5661 | date that the branch was created. A branch is created using the | |
5662 | sequence: @anchor{experimental branch tags} | |
474c8240 | 5663 | @smallexample |
d52fe014 AC |
5664 | cvs rtag @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint gdb |
5665 | cvs rtag -b -r @var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint \ | |
5666 | @var{owner}_@var{name}-@var{YYYYMMDD}-branch gdb | |
474c8240 | 5667 | @end smallexample |
fb0ff88f | 5668 | |
d52fe014 AC |
5669 | @item @var{owner}_@var{name}-@var{yyyymmdd}-mergepoint |
5670 | The tagged point, on the mainline, that was used when merging the branch | |
5671 | on @var{yyyymmdd}. To merge in all changes since the branch was cut, | |
5672 | use a command sequence like: | |
474c8240 | 5673 | @smallexample |
d52fe014 AC |
5674 | cvs rtag @var{owner}_@var{name}-@var{yyyymmdd}-mergepoint gdb |
5675 | cvs update \ | |
5676 | -j@var{owner}_@var{name}-@var{YYYYMMDD}-branchpoint | |
5677 | -j@var{owner}_@var{name}-@var{yyyymmdd}-mergepoint | |
474c8240 | 5678 | @end smallexample |
d52fe014 AC |
5679 | @noindent |
5680 | Similar sequences can be used to just merge in changes since the last | |
5681 | merge. | |
5682 | ||
5683 | @end table | |
fb0ff88f | 5684 | |
d52fe014 AC |
5685 | @noindent |
5686 | For further information on @sc{cvs}, see | |
5687 | @uref{http://www.gnu.org/software/cvs/, Concurrent Versions System}. | |
5688 | ||
55f6ca0f JB |
5689 | @node Start of New Year Procedure |
5690 | @chapter Start of New Year Procedure | |
5691 | @cindex new year procedure | |
5692 | ||
5693 | At the start of each new year, the following actions should be performed: | |
5694 | ||
5695 | @itemize @bullet | |
5696 | @item | |
5697 | Rotate the ChangeLog file | |
5698 | ||
5699 | The current @file{ChangeLog} file should be renamed into | |
5700 | @file{ChangeLog-YYYY} where YYYY is the year that has just passed. | |
5701 | A new @file{ChangeLog} file should be created, and its contents should | |
5702 | contain a reference to the previous ChangeLog. The following should | |
5703 | also be preserved at the end of the new ChangeLog, in order to provide | |
5704 | the appropriate settings when editing this file with Emacs: | |
5705 | @smallexample | |
5706 | Local Variables: | |
5707 | mode: change-log | |
5708 | left-margin: 8 | |
5709 | fill-column: 74 | |
5710 | version-control: never | |
5711 | End: | |
5712 | @end smallexample | |
5713 | ||
5714 | @item | |
5715 | Update the copyright year in the startup message | |
5716 | ||
5717 | Update the copyright year in file @file{top.c}, function | |
5718 | @code{print_gdb_version}. | |
5719 | @end itemize | |
5720 | ||
d52fe014 | 5721 | @node Releasing GDB |
fb0ff88f | 5722 | |
d52fe014 AC |
5723 | @chapter Releasing @value{GDBN} |
5724 | @cindex making a new release of gdb | |
fb0ff88f | 5725 | |
9bb0a4d8 AC |
5726 | @section Branch Commit Policy |
5727 | ||
5728 | The branch commit policy is pretty slack. @value{GDBN} releases 5.0, | |
5729 | 5.1 and 5.2 all used the below: | |
5730 | ||
5731 | @itemize @bullet | |
5732 | @item | |
5733 | The @file{gdb/MAINTAINERS} file still holds. | |
5734 | @item | |
5735 | Don't fix something on the branch unless/until it is also fixed in the | |
5736 | trunk. If this isn't possible, mentioning it in the @file{gdb/PROBLEMS} | |
4be31470 | 5737 | file is better than committing a hack. |
9bb0a4d8 AC |
5738 | @item |
5739 | When considering a patch for the branch, suggested criteria include: | |
5740 | Does it fix a build? Does it fix the sequence @kbd{break main; run} | |
5741 | when debugging a static binary? | |
5742 | @item | |
5743 | The further a change is from the core of @value{GDBN}, the less likely | |
5744 | the change will worry anyone (e.g., target specific code). | |
5745 | @item | |
5746 | Only post a proposal to change the core of @value{GDBN} after you've | |
5747 | sent individual bribes to all the people listed in the | |
5748 | @file{MAINTAINERS} file @t{;-)} | |
5749 | @end itemize | |
5750 | ||
5751 | @emph{Pragmatics: Provided updates are restricted to non-core | |
5752 | functionality there is little chance that a broken change will be fatal. | |
5753 | This means that changes such as adding a new architectures or (within | |
5754 | reason) support for a new host are considered acceptable.} | |
5755 | ||
5756 | ||
cbb09e6a | 5757 | @section Obsoleting code |
8973da3a | 5758 | |
8642bc8f | 5759 | Before anything else, poke the other developers (and around the source |
4be31470 EZ |
5760 | code) to see if there is anything that can be removed from @value{GDBN} |
5761 | (an old target, an unused file). | |
8973da3a | 5762 | |
8642bc8f | 5763 | Obsolete code is identified by adding an @code{OBSOLETE} prefix to every |
cbb09e6a AC |
5764 | line. Doing this means that it is easy to identify something that has |
5765 | been obsoleted when greping through the sources. | |
8973da3a | 5766 | |
cbb09e6a AC |
5767 | The process is done in stages --- this is mainly to ensure that the |
5768 | wider @value{GDBN} community has a reasonable opportunity to respond. | |
5769 | Remember, everything on the Internet takes a week. | |
8973da3a | 5770 | |
cbb09e6a | 5771 | @enumerate |
8973da3a | 5772 | @item |
cbb09e6a AC |
5773 | Post the proposal on @email{gdb@@sources.redhat.com, the GDB mailing |
5774 | list} Creating a bug report to track the task's state, is also highly | |
5775 | recommended. | |
8973da3a | 5776 | @item |
cbb09e6a | 5777 | Wait a week or so. |
8973da3a | 5778 | @item |
cbb09e6a AC |
5779 | Post the proposal on @email{gdb-announce@@sources.redhat.com, the GDB |
5780 | Announcement mailing list}. | |
8973da3a | 5781 | @item |
cbb09e6a | 5782 | Wait a week or so. |
8973da3a | 5783 | @item |
cbb09e6a AC |
5784 | Go through and edit all relevant files and lines so that they are |
5785 | prefixed with the word @code{OBSOLETE}. | |
5786 | @item | |
5787 | Wait until the next GDB version, containing this obsolete code, has been | |
5788 | released. | |
5789 | @item | |
5790 | Remove the obsolete code. | |
5791 | @end enumerate | |
5792 | ||
5793 | @noindent | |
5794 | @emph{Maintainer note: While removing old code is regrettable it is | |
5795 | hopefully better for @value{GDBN}'s long term development. Firstly it | |
5796 | helps the developers by removing code that is either no longer relevant | |
5797 | or simply wrong. Secondly since it removes any history associated with | |
5798 | the file (effectively clearing the slate) the developer has a much freer | |
5799 | hand when it comes to fixing broken files.} | |
8973da3a | 5800 | |
8973da3a | 5801 | |
9ae8b82c AC |
5802 | |
5803 | @section Before the Branch | |
8973da3a | 5804 | |
8642bc8f AC |
5805 | The most important objective at this stage is to find and fix simple |
5806 | changes that become a pain to track once the branch is created. For | |
5807 | instance, configuration problems that stop @value{GDBN} from even | |
5808 | building. If you can't get the problem fixed, document it in the | |
5809 | @file{gdb/PROBLEMS} file. | |
8973da3a | 5810 | |
9ae8b82c | 5811 | @subheading Prompt for @file{gdb/NEWS} |
8973da3a | 5812 | |
9ae8b82c AC |
5813 | People always forget. Send a post reminding them but also if you know |
5814 | something interesting happened add it yourself. The @code{schedule} | |
5815 | script will mention this in its e-mail. | |
8973da3a | 5816 | |
9ae8b82c | 5817 | @subheading Review @file{gdb/README} |
8973da3a | 5818 | |
9ae8b82c AC |
5819 | Grab one of the nightly snapshots and then walk through the |
5820 | @file{gdb/README} looking for anything that can be improved. The | |
5821 | @code{schedule} script will mention this in its e-mail. | |
8642bc8f AC |
5822 | |
5823 | @subheading Refresh any imported files. | |
8973da3a | 5824 | |
8642bc8f | 5825 | A number of files are taken from external repositories. They include: |
8973da3a | 5826 | |
8642bc8f AC |
5827 | @itemize @bullet |
5828 | @item | |
5829 | @file{texinfo/texinfo.tex} | |
5830 | @item | |
9ae8b82c AC |
5831 | @file{config.guess} et.@: al.@: (see the top-level @file{MAINTAINERS} |
5832 | file) | |
5833 | @item | |
5834 | @file{etc/standards.texi}, @file{etc/make-stds.texi} | |
8642bc8f AC |
5835 | @end itemize |
5836 | ||
9ae8b82c | 5837 | @subheading Check the ARI |
8642bc8f | 5838 | |
9ae8b82c AC |
5839 | @uref{http://sources.redhat.com/gdb/ari,,A.R.I.} is an @code{awk} script |
5840 | (Awk Regression Index ;-) that checks for a number of errors and coding | |
5841 | conventions. The checks include things like using @code{malloc} instead | |
5842 | of @code{xmalloc} and file naming problems. There shouldn't be any | |
5843 | regressions. | |
8642bc8f | 5844 | |
9ae8b82c | 5845 | @subsection Review the bug data base |
8642bc8f | 5846 | |
9ae8b82c | 5847 | Close anything obviously fixed. |
8642bc8f | 5848 | |
9ae8b82c | 5849 | @subsection Check all cross targets build |
8642bc8f | 5850 | |
9ae8b82c | 5851 | The targets are listed in @file{gdb/MAINTAINERS}. |
8642bc8f | 5852 | |
8642bc8f | 5853 | |
30107679 | 5854 | @section Cut the Branch |
8642bc8f | 5855 | |
30107679 | 5856 | @subheading Create the branch |
8642bc8f | 5857 | |
474c8240 | 5858 | @smallexample |
30107679 AC |
5859 | $ u=5.1 |
5860 | $ v=5.2 | |
5861 | $ V=`echo $v | sed 's/\./_/g'` | |
5862 | $ D=`date -u +%Y-%m-%d` | |
5863 | $ echo $u $V $D | |
5864 | 5.1 5_2 2002-03-03 | |
5865 | $ echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \ | |
5866 | -D $D-gmt gdb_$V-$D-branchpoint insight+dejagnu | |
5867 | cvs -f -d :ext:sources.redhat.com:/cvs/src rtag | |
5868 | -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight+dejagnu | |
5869 | $ ^echo ^^ | |
5870 | ... | |
5871 | $ echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \ | |
5872 | -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight+dejagnu | |
5873 | cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \ | |
5874 | -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight+dejagnu | |
5875 | $ ^echo ^^ | |
5876 | ... | |
8642bc8f | 5877 | $ |
474c8240 | 5878 | @end smallexample |
8642bc8f AC |
5879 | |
5880 | @itemize @bullet | |
5881 | @item | |
30107679 AC |
5882 | by using @kbd{-D YYYY-MM-DD-gmt} the branch is forced to an exact |
5883 | date/time. | |
5884 | @item | |
5885 | the trunk is first taged so that the branch point can easily be found | |
5886 | @item | |
5887 | Insight (which includes GDB) and dejagnu are all tagged at the same time | |
8642bc8f | 5888 | @item |
30107679 | 5889 | @file{version.in} gets bumped to avoid version number conflicts |
8642bc8f | 5890 | @item |
30107679 AC |
5891 | the reading of @file{.cvsrc} is disabled using @file{-f} |
5892 | @end itemize | |
5893 | ||
5894 | @subheading Update @file{version.in} | |
5895 | ||
5896 | @smallexample | |
5897 | $ u=5.1 | |
5898 | $ v=5.2 | |
5899 | $ V=`echo $v | sed 's/\./_/g'` | |
5900 | $ echo $u $v$V | |
5901 | 5.1 5_2 | |
5902 | $ cd /tmp | |
5903 | $ echo cvs -f -d :ext:sources.redhat.com:/cvs/src co \ | |
5904 | -r gdb_$V-branch src/gdb/version.in | |
5905 | cvs -f -d :ext:sources.redhat.com:/cvs/src co | |
5906 | -r gdb_5_2-branch src/gdb/version.in | |
5907 | $ ^echo ^^ | |
5908 | U src/gdb/version.in | |
5909 | $ cd src/gdb | |
5910 | $ echo $u.90-0000-00-00-cvs > version.in | |
5911 | $ cat version.in | |
5912 | 5.1.90-0000-00-00-cvs | |
5913 | $ cvs -f commit version.in | |
5914 | @end smallexample | |
5915 | ||
5916 | @itemize @bullet | |
5917 | @item | |
5918 | @file{0000-00-00} is used as a date to pump prime the version.in update | |
5919 | mechanism | |
5920 | @item | |
5921 | @file{.90} and the previous branch version are used as fairly arbitrary | |
5922 | initial branch version number | |
8642bc8f AC |
5923 | @end itemize |
5924 | ||
8642bc8f AC |
5925 | |
5926 | @subheading Update the web and news pages | |
5927 | ||
30107679 AC |
5928 | Something? |
5929 | ||
8642bc8f AC |
5930 | @subheading Tweak cron to track the new branch |
5931 | ||
30107679 AC |
5932 | The file @file{gdbadmin/cron/crontab} contains gdbadmin's cron table. |
5933 | This file needs to be updated so that: | |
5934 | ||
5935 | @itemize @bullet | |
5936 | @item | |
5937 | a daily timestamp is added to the file @file{version.in} | |
5938 | @item | |
5939 | the new branch is included in the snapshot process | |
5940 | @end itemize | |
5941 | ||
5942 | @noindent | |
5943 | See the file @file{gdbadmin/cron/README} for how to install the updated | |
5944 | cron table. | |
5945 | ||
5946 | The file @file{gdbadmin/ss/README} should also be reviewed to reflect | |
5947 | any changes. That file is copied to both the branch/ and current/ | |
5948 | snapshot directories. | |
5949 | ||
5950 | ||
5951 | @subheading Update the NEWS and README files | |
5952 | ||
5953 | The @file{NEWS} file needs to be updated so that on the branch it refers | |
5954 | to @emph{changes in the current release} while on the trunk it also | |
5955 | refers to @emph{changes since the current release}. | |
5956 | ||
5957 | The @file{README} file needs to be updated so that it refers to the | |
5958 | current release. | |
5959 | ||
5960 | @subheading Post the branch info | |
5961 | ||
5962 | Send an announcement to the mailing lists: | |
5963 | ||
5964 | @itemize @bullet | |
5965 | @item | |
5966 | @email{gdb-announce@@sources.redhat.com, GDB Announcement mailing list} | |
5967 | @item | |
5968 | @email{gdb@@sources.redhat.com, GDB Discsussion mailing list} and | |
5969 | @email{gdb-testers@@sources.redhat.com, GDB Discsussion mailing list} | |
16737d73 | 5970 | @end itemize |
30107679 AC |
5971 | |
5972 | @emph{Pragmatics: The branch creation is sent to the announce list to | |
5973 | ensure that people people not subscribed to the higher volume discussion | |
5974 | list are alerted.} | |
5975 | ||
5976 | The announcement should include: | |
5977 | ||
5978 | @itemize @bullet | |
5979 | @item | |
5980 | the branch tag | |
5981 | @item | |
5982 | how to check out the branch using CVS | |
5983 | @item | |
5984 | the date/number of weeks until the release | |
5985 | @item | |
5986 | the branch commit policy | |
5987 | still holds. | |
16737d73 | 5988 | @end itemize |
30107679 | 5989 | |
8642bc8f AC |
5990 | @section Stabilize the branch |
5991 | ||
5992 | Something goes here. | |
5993 | ||
5994 | @section Create a Release | |
5995 | ||
0816590b AC |
5996 | The process of creating and then making available a release is broken |
5997 | down into a number of stages. The first part addresses the technical | |
5998 | process of creating a releasable tar ball. The later stages address the | |
5999 | process of releasing that tar ball. | |
8973da3a | 6000 | |
0816590b AC |
6001 | When making a release candidate just the first section is needed. |
6002 | ||
6003 | @subsection Create a release candidate | |
6004 | ||
6005 | The objective at this stage is to create a set of tar balls that can be | |
6006 | made available as a formal release (or as a less formal release | |
6007 | candidate). | |
6008 | ||
6009 | @subsubheading Freeze the branch | |
6010 | ||
6011 | Send out an e-mail notifying everyone that the branch is frozen to | |
6012 | @email{gdb-patches@@sources.redhat.com}. | |
6013 | ||
6014 | @subsubheading Establish a few defaults. | |
8973da3a | 6015 | |
474c8240 | 6016 | @smallexample |
0816590b AC |
6017 | $ b=gdb_5_2-branch |
6018 | $ v=5.2 | |
8642bc8f AC |
6019 | $ t=/sourceware/snapshot-tmp/gdbadmin-tmp |
6020 | $ echo $t/$b/$v | |
0816590b | 6021 | /sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2 |
8642bc8f AC |
6022 | $ mkdir -p $t/$b/$v |
6023 | $ cd $t/$b/$v | |
6024 | $ pwd | |
0816590b | 6025 | /sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2 |
8973da3a AC |
6026 | $ which autoconf |
6027 | /home/gdbadmin/bin/autoconf | |
8642bc8f | 6028 | $ |
474c8240 | 6029 | @end smallexample |
8973da3a | 6030 | |
0816590b AC |
6031 | @noindent |
6032 | Notes: | |
8973da3a | 6033 | |
0816590b AC |
6034 | @itemize @bullet |
6035 | @item | |
6036 | Check the @code{autoconf} version carefully. You want to be using the | |
4a2b4636 JB |
6037 | version taken from the @file{binutils} snapshot directory, which can be |
6038 | found at @uref{ftp://sources.redhat.com/pub/binutils/}. It is very | |
0816590b AC |
6039 | unlikely that a system installed version of @code{autoconf} (e.g., |
6040 | @file{/usr/bin/autoconf}) is correct. | |
6041 | @end itemize | |
6042 | ||
6043 | @subsubheading Check out the relevant modules: | |
8973da3a | 6044 | |
474c8240 | 6045 | @smallexample |
8642bc8f AC |
6046 | $ for m in gdb insight dejagnu |
6047 | do | |
8973da3a AC |
6048 | ( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m ) |
6049 | done | |
8642bc8f | 6050 | $ |
474c8240 | 6051 | @end smallexample |
8973da3a | 6052 | |
0816590b AC |
6053 | @noindent |
6054 | Note: | |
8642bc8f | 6055 | |
0816590b AC |
6056 | @itemize @bullet |
6057 | @item | |
6058 | The reading of @file{.cvsrc} is disabled (@file{-f}) so that there isn't | |
6059 | any confusion between what is written here and what your local | |
6060 | @code{cvs} really does. | |
6061 | @end itemize | |
6062 | ||
6063 | @subsubheading Update relevant files. | |
8973da3a | 6064 | |
0816590b AC |
6065 | @table @file |
6066 | ||
6067 | @item gdb/NEWS | |
8642bc8f AC |
6068 | |
6069 | Major releases get their comments added as part of the mainline. Minor | |
6070 | releases should probably mention any significant bugs that were fixed. | |
6071 | ||
0816590b | 6072 | Don't forget to include the @file{ChangeLog} entry. |
8973da3a | 6073 | |
474c8240 | 6074 | @smallexample |
8642bc8f AC |
6075 | $ emacs gdb/src/gdb/NEWS |
6076 | ... | |
6077 | c-x 4 a | |
6078 | ... | |
6079 | c-x c-s c-x c-c | |
6080 | $ cp gdb/src/gdb/NEWS insight/src/gdb/NEWS | |
6081 | $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog | |
474c8240 | 6082 | @end smallexample |
8973da3a | 6083 | |
0816590b AC |
6084 | @item gdb/README |
6085 | ||
6086 | You'll need to update: | |
8973da3a | 6087 | |
0816590b AC |
6088 | @itemize @bullet |
6089 | @item | |
6090 | the version | |
6091 | @item | |
6092 | the update date | |
6093 | @item | |
6094 | who did it | |
6095 | @end itemize | |
8973da3a | 6096 | |
474c8240 | 6097 | @smallexample |
8642bc8f AC |
6098 | $ emacs gdb/src/gdb/README |
6099 | ... | |
8973da3a | 6100 | c-x 4 a |
8642bc8f | 6101 | ... |
8973da3a | 6102 | c-x c-s c-x c-c |
8642bc8f AC |
6103 | $ cp gdb/src/gdb/README insight/src/gdb/README |
6104 | $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog | |
474c8240 | 6105 | @end smallexample |
8973da3a | 6106 | |
0816590b AC |
6107 | @emph{Maintainer note: Hopefully the @file{README} file was reviewed |
6108 | before the initial branch was cut so just a simple substitute is needed | |
6109 | to get it updated.} | |
8973da3a | 6110 | |
8642bc8f AC |
6111 | @emph{Maintainer note: Other projects generate @file{README} and |
6112 | @file{INSTALL} from the core documentation. This might be worth | |
6113 | pursuing.} | |
8973da3a | 6114 | |
0816590b | 6115 | @item gdb/version.in |
8973da3a | 6116 | |
474c8240 | 6117 | @smallexample |
8642bc8f | 6118 | $ echo $v > gdb/src/gdb/version.in |
0816590b AC |
6119 | $ cat gdb/src/gdb/version.in |
6120 | 5.2 | |
8642bc8f | 6121 | $ emacs gdb/src/gdb/version.in |
8973da3a AC |
6122 | ... |
6123 | c-x 4 a | |
0816590b | 6124 | ... Bump to version ... |
8973da3a | 6125 | c-x c-s c-x c-c |
8642bc8f AC |
6126 | $ cp gdb/src/gdb/version.in insight/src/gdb/version.in |
6127 | $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog | |
474c8240 | 6128 | @end smallexample |
8973da3a | 6129 | |
0816590b | 6130 | @item dejagnu/src/dejagnu/configure.in |
8642bc8f AC |
6131 | |
6132 | Dejagnu is more complicated. The version number is a parameter to | |
0816590b | 6133 | @code{AM_INIT_AUTOMAKE}. Tweak it to read something like gdb-5.1.91. |
8642bc8f | 6134 | |
0816590b | 6135 | Don't forget to re-generate @file{configure}. |
8642bc8f | 6136 | |
0816590b | 6137 | Don't forget to include a @file{ChangeLog} entry. |
8642bc8f | 6138 | |
0816590b AC |
6139 | @smallexample |
6140 | $ emacs dejagnu/src/dejagnu/configure.in | |
6141 | ... | |
6142 | c-x 4 a | |
6143 | ... | |
6144 | c-x c-s c-x c-c | |
6145 | $ ( cd dejagnu/src/dejagnu && autoconf ) | |
6146 | @end smallexample | |
8642bc8f | 6147 | |
0816590b AC |
6148 | @end table |
6149 | ||
6150 | @subsubheading Do the dirty work | |
6151 | ||
6152 | This is identical to the process used to create the daily snapshot. | |
8973da3a | 6153 | |
4ce8657e MC |
6154 | @smallexample |
6155 | $ for m in gdb insight | |
6156 | do | |
6157 | ( cd $m/src && gmake -f src-release $m.tar ) | |
6158 | done | |
6159 | $ ( m=dejagnu; cd $m/src && gmake -f src-release $m.tar.bz2 ) | |
6160 | @end smallexample | |
6161 | ||
6162 | If the top level source directory does not have @file{src-release} | |
6163 | (@value{GDBN} version 5.3.1 or earlier), try these commands instead: | |
6164 | ||
474c8240 | 6165 | @smallexample |
0816590b | 6166 | $ for m in gdb insight |
8642bc8f | 6167 | do |
0816590b | 6168 | ( cd $m/src && gmake -f Makefile.in $m.tar ) |
8973da3a | 6169 | done |
0816590b | 6170 | $ ( m=dejagnu; cd $m/src && gmake -f Makefile.in $m.tar.bz2 ) |
474c8240 | 6171 | @end smallexample |
8973da3a | 6172 | |
0816590b | 6173 | @subsubheading Check the source files |
8642bc8f | 6174 | |
0816590b | 6175 | You're looking for files that have mysteriously disappeared. |
8642bc8f AC |
6176 | @kbd{distclean} has the habit of deleting files it shouldn't. Watch out |
6177 | for the @file{version.in} update @kbd{cronjob}. | |
8973da3a | 6178 | |
474c8240 | 6179 | @smallexample |
8642bc8f AC |
6180 | $ ( cd gdb/src && cvs -f -q -n update ) |
6181 | M djunpack.bat | |
0816590b | 6182 | ? gdb-5.1.91.tar |
8642bc8f | 6183 | ? proto-toplev |
0816590b | 6184 | @dots{} lots of generated files @dots{} |
8642bc8f AC |
6185 | M gdb/ChangeLog |
6186 | M gdb/NEWS | |
6187 | M gdb/README | |
6188 | M gdb/version.in | |
0816590b | 6189 | @dots{} lots of generated files @dots{} |
8642bc8f | 6190 | $ |
474c8240 | 6191 | @end smallexample |
8973da3a | 6192 | |
0816590b | 6193 | @noindent |
8642bc8f AC |
6194 | @emph{Don't worry about the @file{gdb.info-??} or |
6195 | @file{gdb/p-exp.tab.c}. They were generated (and yes @file{gdb.info-1} | |
6196 | was also generated only something strange with CVS means that they | |
6197 | didn't get supressed). Fixing it would be nice though.} | |
8973da3a | 6198 | |
0816590b | 6199 | @subsubheading Create compressed versions of the release |
8973da3a | 6200 | |
474c8240 | 6201 | @smallexample |
0816590b AC |
6202 | $ cp */src/*.tar . |
6203 | $ cp */src/*.bz2 . | |
6204 | $ ls -F | |
6205 | dejagnu/ dejagnu-gdb-5.2.tar.bz2 gdb/ gdb-5.2.tar insight/ insight-5.2.tar | |
6206 | $ for m in gdb insight | |
6207 | do | |
6208 | bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2 | |
6209 | gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz | |
6210 | done | |
6211 | $ | |
474c8240 | 6212 | @end smallexample |
8973da3a | 6213 | |
0816590b AC |
6214 | @noindent |
6215 | Note: | |
6216 | ||
6217 | @itemize @bullet | |
6218 | @item | |
6219 | A pipe such as @kbd{bunzip2 < xxx.bz2 | gzip -9 > xxx.gz} is not since, | |
6220 | in that mode, @code{gzip} does not know the name of the file and, hence, | |
6221 | can not include it in the compressed file. This is also why the release | |
6222 | process runs @code{tar} and @code{bzip2} as separate passes. | |
6223 | @end itemize | |
6224 | ||
6225 | @subsection Sanity check the tar ball | |
8973da3a | 6226 | |
0816590b | 6227 | Pick a popular machine (Solaris/PPC?) and try the build on that. |
8973da3a | 6228 | |
0816590b AC |
6229 | @smallexample |
6230 | $ bunzip2 < gdb-5.2.tar.bz2 | tar xpf - | |
6231 | $ cd gdb-5.2 | |
6232 | $ ./configure | |
6233 | $ make | |
6234 | @dots{} | |
6235 | $ ./gdb/gdb ./gdb/gdb | |
6236 | GNU gdb 5.2 | |
6237 | @dots{} | |
6238 | (gdb) b main | |
6239 | Breakpoint 1 at 0x80732bc: file main.c, line 734. | |
6240 | (gdb) run | |
6241 | Starting program: /tmp/gdb-5.2/gdb/gdb | |
6242 | ||
6243 | Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734 | |
6244 | 734 catch_errors (captured_main, &args, "", RETURN_MASK_ALL); | |
6245 | (gdb) print args | |
6246 | $1 = @{argc = 136426532, argv = 0x821b7f0@} | |
6247 | (gdb) | |
6248 | @end smallexample | |
8973da3a | 6249 | |
0816590b | 6250 | @subsection Make a release candidate available |
8973da3a | 6251 | |
0816590b | 6252 | If this is a release candidate then the only remaining steps are: |
8642bc8f | 6253 | |
0816590b AC |
6254 | @enumerate |
6255 | @item | |
6256 | Commit @file{version.in} and @file{ChangeLog} | |
6257 | @item | |
6258 | Tweak @file{version.in} (and @file{ChangeLog} to read | |
6259 | @var{L}.@var{M}.@var{N}-0000-00-00-cvs so that the version update | |
6260 | process can restart. | |
6261 | @item | |
6262 | Make the release candidate available in | |
6263 | @uref{ftp://sources.redhat.com/pub/gdb/snapshots/branch} | |
6264 | @item | |
6265 | Notify the relevant mailing lists ( @email{gdb@@sources.redhat.com} and | |
6266 | @email{gdb-testers@@sources.redhat.com} that the candidate is available. | |
6267 | @end enumerate | |
8642bc8f | 6268 | |
0816590b | 6269 | @subsection Make a formal release available |
8642bc8f | 6270 | |
0816590b | 6271 | (And you thought all that was required was to post an e-mail.) |
8642bc8f | 6272 | |
0816590b | 6273 | @subsubheading Install on sware |
8642bc8f | 6274 | |
0816590b | 6275 | Copy the new files to both the release and the old release directory: |
8642bc8f | 6276 | |
474c8240 | 6277 | @smallexample |
0816590b | 6278 | $ cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/ |
8642bc8f | 6279 | $ cp *.bz2 *.gz ~ftp/pub/gdb/releases |
474c8240 | 6280 | @end smallexample |
8642bc8f | 6281 | |
0816590b AC |
6282 | @noindent |
6283 | Clean up the releases directory so that only the most recent releases | |
6284 | are available (e.g. keep 5.2 and 5.2.1 but remove 5.1): | |
6285 | ||
6286 | @smallexample | |
6287 | $ cd ~ftp/pub/gdb/releases | |
6288 | $ rm @dots{} | |
6289 | @end smallexample | |
6290 | ||
6291 | @noindent | |
6292 | Update the file @file{README} and @file{.message} in the releases | |
6293 | directory: | |
6294 | ||
6295 | @smallexample | |
6296 | $ vi README | |
6297 | @dots{} | |
6298 | $ rm -f .message | |
6299 | $ ln README .message | |
6300 | @end smallexample | |
8642bc8f | 6301 | |
0816590b | 6302 | @subsubheading Update the web pages. |
8973da3a | 6303 | |
0816590b AC |
6304 | @table @file |
6305 | ||
6306 | @item htdocs/download/ANNOUNCEMENT | |
6307 | This file, which is posted as the official announcement, includes: | |
8973da3a AC |
6308 | @itemize @bullet |
6309 | @item | |
0816590b | 6310 | General announcement |
8642bc8f | 6311 | @item |
0816590b AC |
6312 | News. If making an @var{M}.@var{N}.1 release, retain the news from |
6313 | earlier @var{M}.@var{N} release. | |
8973da3a | 6314 | @item |
0816590b AC |
6315 | Errata |
6316 | @end itemize | |
6317 | ||
6318 | @item htdocs/index.html | |
6319 | @itemx htdocs/news/index.html | |
6320 | @itemx htdocs/download/index.html | |
6321 | These files include: | |
6322 | @itemize @bullet | |
8642bc8f | 6323 | @item |
0816590b | 6324 | announcement of the most recent release |
8642bc8f | 6325 | @item |
0816590b | 6326 | news entry (remember to update both the top level and the news directory). |
8973da3a | 6327 | @end itemize |
0816590b | 6328 | These pages also need to be regenerate using @code{index.sh}. |
8973da3a | 6329 | |
0816590b | 6330 | @item download/onlinedocs/ |
8642bc8f AC |
6331 | You need to find the magic command that is used to generate the online |
6332 | docs from the @file{.tar.bz2}. The best way is to look in the output | |
0816590b | 6333 | from one of the nightly @code{cron} jobs and then just edit accordingly. |
8642bc8f AC |
6334 | Something like: |
6335 | ||
474c8240 | 6336 | @smallexample |
8642bc8f | 6337 | $ ~/ss/update-web-docs \ |
0816590b | 6338 | ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \ |
8642bc8f | 6339 | $PWD/www \ |
0816590b | 6340 | /www/sourceware/htdocs/gdb/download/onlinedocs \ |
8642bc8f | 6341 | gdb |
474c8240 | 6342 | @end smallexample |
8642bc8f | 6343 | |
0816590b AC |
6344 | @item download/ari/ |
6345 | Just like the online documentation. Something like: | |
8642bc8f | 6346 | |
0816590b AC |
6347 | @smallexample |
6348 | $ /bin/sh ~/ss/update-web-ari \ | |
6349 | ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \ | |
6350 | $PWD/www \ | |
6351 | /www/sourceware/htdocs/gdb/download/ari \ | |
6352 | gdb | |
6353 | @end smallexample | |
6354 | ||
6355 | @end table | |
6356 | ||
6357 | @subsubheading Shadow the pages onto gnu | |
6358 | ||
6359 | Something goes here. | |
6360 | ||
6361 | ||
6362 | @subsubheading Install the @value{GDBN} tar ball on GNU | |
6363 | ||
6364 | At the time of writing, the GNU machine was @kbd{gnudist.gnu.org} in | |
6365 | @file{~ftp/gnu/gdb}. | |
6366 | ||
6367 | @subsubheading Make the @file{ANNOUNCEMENT} | |
6368 | ||
6369 | Post the @file{ANNOUNCEMENT} file you created above to: | |
8642bc8f AC |
6370 | |
6371 | @itemize @bullet | |
6372 | @item | |
6373 | @email{gdb-announce@@sources.redhat.com, GDB Announcement mailing list} | |
6374 | @item | |
0816590b AC |
6375 | @email{info-gnu@@gnu.org, General GNU Announcement list} (but delay it a |
6376 | day or so to let things get out) | |
6377 | @item | |
6378 | @email{bug-gdb@@gnu.org, GDB Bug Report mailing list} | |
8642bc8f AC |
6379 | @end itemize |
6380 | ||
0816590b | 6381 | @subsection Cleanup |
8642bc8f | 6382 | |
0816590b | 6383 | The release is out but you're still not finished. |
8642bc8f | 6384 | |
0816590b | 6385 | @subsubheading Commit outstanding changes |
8642bc8f | 6386 | |
0816590b | 6387 | In particular you'll need to commit any changes to: |
8642bc8f AC |
6388 | |
6389 | @itemize @bullet | |
6390 | @item | |
6391 | @file{gdb/ChangeLog} | |
6392 | @item | |
6393 | @file{gdb/version.in} | |
6394 | @item | |
6395 | @file{gdb/NEWS} | |
6396 | @item | |
6397 | @file{gdb/README} | |
6398 | @end itemize | |
6399 | ||
0816590b | 6400 | @subsubheading Tag the release |
8642bc8f AC |
6401 | |
6402 | Something like: | |
6403 | ||
474c8240 | 6404 | @smallexample |
8642bc8f AC |
6405 | $ d=`date -u +%Y-%m-%d` |
6406 | $ echo $d | |
6407 | 2002-01-24 | |
6408 | $ ( cd insight/src/gdb && cvs -f -q update ) | |
0816590b | 6409 | $ ( cd insight/src && cvs -f -q tag gdb_5_2-$d-release ) |
474c8240 | 6410 | @end smallexample |
8642bc8f | 6411 | |
0816590b AC |
6412 | Insight is used since that contains more of the release than |
6413 | @value{GDBN} (@code{dejagnu} doesn't get tagged but I think we can live | |
6414 | with that). | |
6415 | ||
6416 | @subsubheading Mention the release on the trunk | |
8642bc8f | 6417 | |
0816590b AC |
6418 | Just put something in the @file{ChangeLog} so that the trunk also |
6419 | indicates when the release was made. | |
6420 | ||
6421 | @subsubheading Restart @file{gdb/version.in} | |
8642bc8f AC |
6422 | |
6423 | If @file{gdb/version.in} does not contain an ISO date such as | |
6424 | @kbd{2002-01-24} then the daily @code{cronjob} won't update it. Having | |
6425 | committed all the release changes it can be set to | |
0816590b | 6426 | @file{5.2.0_0000-00-00-cvs} which will restart things (yes the @kbd{_} |
8642bc8f AC |
6427 | is important - it affects the snapshot process). |
6428 | ||
6429 | Don't forget the @file{ChangeLog}. | |
6430 | ||
0816590b | 6431 | @subsubheading Merge into trunk |
8973da3a | 6432 | |
8642bc8f AC |
6433 | The files committed to the branch may also need changes merged into the |
6434 | trunk. | |
8973da3a | 6435 | |
0816590b AC |
6436 | @subsubheading Revise the release schedule |
6437 | ||
6438 | Post a revised release schedule to @email{gdb@@sources.redhat.com, GDB | |
6439 | Discussion List} with an updated announcement. The schedule can be | |
6440 | generated by running: | |
6441 | ||
6442 | @smallexample | |
6443 | $ ~/ss/schedule `date +%s` schedule | |
6444 | @end smallexample | |
6445 | ||
6446 | @noindent | |
6447 | The first parameter is approximate date/time in seconds (from the epoch) | |
6448 | of the most recent release. | |
6449 | ||
6450 | Also update the schedule @code{cronjob}. | |
6451 | ||
8642bc8f | 6452 | @section Post release |
8973da3a | 6453 | |
8642bc8f | 6454 | Remove any @code{OBSOLETE} code. |
8973da3a | 6455 | |
085dd6e6 JM |
6456 | @node Testsuite |
6457 | ||
6458 | @chapter Testsuite | |
56caf160 | 6459 | @cindex test suite |
085dd6e6 | 6460 | |
56caf160 EZ |
6461 | The testsuite is an important component of the @value{GDBN} package. |
6462 | While it is always worthwhile to encourage user testing, in practice | |
6463 | this is rarely sufficient; users typically use only a small subset of | |
6464 | the available commands, and it has proven all too common for a change | |
6465 | to cause a significant regression that went unnoticed for some time. | |
085dd6e6 | 6466 | |
56caf160 EZ |
6467 | The @value{GDBN} testsuite uses the DejaGNU testing framework. |
6468 | DejaGNU is built using @code{Tcl} and @code{expect}. The tests | |
6469 | themselves are calls to various @code{Tcl} procs; the framework runs all the | |
6470 | procs and summarizes the passes and fails. | |
085dd6e6 JM |
6471 | |
6472 | @section Using the Testsuite | |
6473 | ||
56caf160 | 6474 | @cindex running the test suite |
25822942 | 6475 | To run the testsuite, simply go to the @value{GDBN} object directory (or to the |
085dd6e6 JM |
6476 | testsuite's objdir) and type @code{make check}. This just sets up some |
6477 | environment variables and invokes DejaGNU's @code{runtest} script. While | |
6478 | the testsuite is running, you'll get mentions of which test file is in use, | |
6479 | and a mention of any unexpected passes or fails. When the testsuite is | |
6480 | finished, you'll get a summary that looks like this: | |
56caf160 | 6481 | |
474c8240 | 6482 | @smallexample |
085dd6e6 JM |
6483 | === gdb Summary === |
6484 | ||
6485 | # of expected passes 6016 | |
6486 | # of unexpected failures 58 | |
6487 | # of unexpected successes 5 | |
6488 | # of expected failures 183 | |
6489 | # of unresolved testcases 3 | |
6490 | # of untested testcases 5 | |
474c8240 | 6491 | @end smallexample |
56caf160 | 6492 | |
a9f158ec JB |
6493 | To run a specific test script, type: |
6494 | @example | |
6495 | make check RUNTESTFLAGS='@var{tests}' | |
6496 | @end example | |
6497 | where @var{tests} is a list of test script file names, separated by | |
6498 | spaces. | |
6499 | ||
085dd6e6 JM |
6500 | The ideal test run consists of expected passes only; however, reality |
6501 | conspires to keep us from this ideal. Unexpected failures indicate | |
56caf160 EZ |
6502 | real problems, whether in @value{GDBN} or in the testsuite. Expected |
6503 | failures are still failures, but ones which have been decided are too | |
6504 | hard to deal with at the time; for instance, a test case might work | |
6505 | everywhere except on AIX, and there is no prospect of the AIX case | |
6506 | being fixed in the near future. Expected failures should not be added | |
6507 | lightly, since you may be masking serious bugs in @value{GDBN}. | |
6508 | Unexpected successes are expected fails that are passing for some | |
6509 | reason, while unresolved and untested cases often indicate some minor | |
6510 | catastrophe, such as the compiler being unable to deal with a test | |
6511 | program. | |
6512 | ||
6513 | When making any significant change to @value{GDBN}, you should run the | |
6514 | testsuite before and after the change, to confirm that there are no | |
6515 | regressions. Note that truly complete testing would require that you | |
6516 | run the testsuite with all supported configurations and a variety of | |
6517 | compilers; however this is more than really necessary. In many cases | |
6518 | testing with a single configuration is sufficient. Other useful | |
6519 | options are to test one big-endian (Sparc) and one little-endian (x86) | |
6520 | host, a cross config with a builtin simulator (powerpc-eabi, | |
6521 | mips-elf), or a 64-bit host (Alpha). | |
6522 | ||
6523 | If you add new functionality to @value{GDBN}, please consider adding | |
6524 | tests for it as well; this way future @value{GDBN} hackers can detect | |
6525 | and fix their changes that break the functionality you added. | |
6526 | Similarly, if you fix a bug that was not previously reported as a test | |
6527 | failure, please add a test case for it. Some cases are extremely | |
6528 | difficult to test, such as code that handles host OS failures or bugs | |
6529 | in particular versions of compilers, and it's OK not to try to write | |
6530 | tests for all of those. | |
085dd6e6 | 6531 | |
e7dc800a MC |
6532 | DejaGNU supports separate build, host, and target machines. However, |
6533 | some @value{GDBN} test scripts do not work if the build machine and | |
6534 | the host machine are not the same. In such an environment, these scripts | |
6535 | will give a result of ``UNRESOLVED'', like this: | |
6536 | ||
6537 | @smallexample | |
6538 | UNRESOLVED: gdb.base/example.exp: This test script does not work on a remote host. | |
6539 | @end smallexample | |
6540 | ||
085dd6e6 JM |
6541 | @section Testsuite Organization |
6542 | ||
56caf160 | 6543 | @cindex test suite organization |
085dd6e6 JM |
6544 | The testsuite is entirely contained in @file{gdb/testsuite}. While the |
6545 | testsuite includes some makefiles and configury, these are very minimal, | |
6546 | and used for little besides cleaning up, since the tests themselves | |
25822942 | 6547 | handle the compilation of the programs that @value{GDBN} will run. The file |
085dd6e6 | 6548 | @file{testsuite/lib/gdb.exp} contains common utility procs useful for |
25822942 | 6549 | all @value{GDBN} tests, while the directory @file{testsuite/config} contains |
085dd6e6 JM |
6550 | configuration-specific files, typically used for special-purpose |
6551 | definitions of procs like @code{gdb_load} and @code{gdb_start}. | |
6552 | ||
6553 | The tests themselves are to be found in @file{testsuite/gdb.*} and | |
6554 | subdirectories of those. The names of the test files must always end | |
6555 | with @file{.exp}. DejaGNU collects the test files by wildcarding | |
6556 | in the test directories, so both subdirectories and individual files | |
6557 | get chosen and run in alphabetical order. | |
6558 | ||
6559 | The following table lists the main types of subdirectories and what they | |
6560 | are for. Since DejaGNU finds test files no matter where they are | |
6561 | located, and since each test file sets up its own compilation and | |
6562 | execution environment, this organization is simply for convenience and | |
6563 | intelligibility. | |
6564 | ||
56caf160 | 6565 | @table @file |
085dd6e6 | 6566 | @item gdb.base |
085dd6e6 | 6567 | This is the base testsuite. The tests in it should apply to all |
25822942 | 6568 | configurations of @value{GDBN} (but generic native-only tests may live here). |
085dd6e6 | 6569 | The test programs should be in the subset of C that is valid K&R, |
49efadf5 | 6570 | ANSI/ISO, and C@t{++} (@code{#ifdef}s are allowed if necessary, for instance |
085dd6e6 JM |
6571 | for prototypes). |
6572 | ||
6573 | @item gdb.@var{lang} | |
56caf160 | 6574 | Language-specific tests for any language @var{lang} besides C. Examples are |
af6cf26d | 6575 | @file{gdb.cp} and @file{gdb.java}. |
085dd6e6 JM |
6576 | |
6577 | @item gdb.@var{platform} | |
085dd6e6 JM |
6578 | Non-portable tests. The tests are specific to a specific configuration |
6579 | (host or target), such as HP-UX or eCos. Example is @file{gdb.hp}, for | |
6580 | HP-UX. | |
6581 | ||
6582 | @item gdb.@var{compiler} | |
085dd6e6 JM |
6583 | Tests specific to a particular compiler. As of this writing (June |
6584 | 1999), there aren't currently any groups of tests in this category that | |
6585 | couldn't just as sensibly be made platform-specific, but one could | |
56caf160 EZ |
6586 | imagine a @file{gdb.gcc}, for tests of @value{GDBN}'s handling of GCC |
6587 | extensions. | |
085dd6e6 JM |
6588 | |
6589 | @item gdb.@var{subsystem} | |
25822942 | 6590 | Tests that exercise a specific @value{GDBN} subsystem in more depth. For |
085dd6e6 JM |
6591 | instance, @file{gdb.disasm} exercises various disassemblers, while |
6592 | @file{gdb.stabs} tests pathways through the stabs symbol reader. | |
085dd6e6 JM |
6593 | @end table |
6594 | ||
6595 | @section Writing Tests | |
56caf160 | 6596 | @cindex writing tests |
085dd6e6 | 6597 | |
25822942 | 6598 | In many areas, the @value{GDBN} tests are already quite comprehensive; you |
085dd6e6 JM |
6599 | should be able to copy existing tests to handle new cases. |
6600 | ||
6601 | You should try to use @code{gdb_test} whenever possible, since it | |
6602 | includes cases to handle all the unexpected errors that might happen. | |
6603 | However, it doesn't cost anything to add new test procedures; for | |
6604 | instance, @file{gdb.base/exprs.exp} defines a @code{test_expr} that | |
6605 | calls @code{gdb_test} multiple times. | |
6606 | ||
6607 | Only use @code{send_gdb} and @code{gdb_expect} when absolutely | |
25822942 | 6608 | necessary, such as when @value{GDBN} has several valid responses to a command. |
085dd6e6 JM |
6609 | |
6610 | The source language programs do @emph{not} need to be in a consistent | |
25822942 | 6611 | style. Since @value{GDBN} is used to debug programs written in many different |
085dd6e6 | 6612 | styles, it's worth having a mix of styles in the testsuite; for |
25822942 | 6613 | instance, some @value{GDBN} bugs involving the display of source lines would |
085dd6e6 JM |
6614 | never manifest themselves if the programs used GNU coding style |
6615 | uniformly. | |
6616 | ||
c906108c SS |
6617 | @node Hints |
6618 | ||
6619 | @chapter Hints | |
6620 | ||
6621 | Check the @file{README} file, it often has useful information that does not | |
6622 | appear anywhere else in the directory. | |
6623 | ||
6624 | @menu | |
25822942 | 6625 | * Getting Started:: Getting started working on @value{GDBN} |
33e16fad | 6626 | * Debugging GDB:: Debugging @value{GDBN} with itself |
c906108c SS |
6627 | @end menu |
6628 | ||
6629 | @node Getting Started,,, Hints | |
6630 | ||
6631 | @section Getting Started | |
6632 | ||
25822942 | 6633 | @value{GDBN} is a large and complicated program, and if you first starting to |
c906108c SS |
6634 | work on it, it can be hard to know where to start. Fortunately, if you |
6635 | know how to go about it, there are ways to figure out what is going on. | |
6636 | ||
25822942 DB |
6637 | This manual, the @value{GDBN} Internals manual, has information which applies |
6638 | generally to many parts of @value{GDBN}. | |
c906108c SS |
6639 | |
6640 | Information about particular functions or data structures are located in | |
6641 | comments with those functions or data structures. If you run across a | |
6642 | function or a global variable which does not have a comment correctly | |
25822942 | 6643 | explaining what is does, this can be thought of as a bug in @value{GDBN}; feel |
c906108c SS |
6644 | free to submit a bug report, with a suggested comment if you can figure |
6645 | out what the comment should say. If you find a comment which is | |
6646 | actually wrong, be especially sure to report that. | |
6647 | ||
6648 | Comments explaining the function of macros defined in host, target, or | |
6649 | native dependent files can be in several places. Sometimes they are | |
6650 | repeated every place the macro is defined. Sometimes they are where the | |
6651 | macro is used. Sometimes there is a header file which supplies a | |
6652 | default definition of the macro, and the comment is there. This manual | |
6653 | also documents all the available macros. | |
6654 | @c (@pxref{Host Conditionals}, @pxref{Target | |
6655 | @c Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete | |
6656 | @c Conditionals}) | |
6657 | ||
56caf160 EZ |
6658 | Start with the header files. Once you have some idea of how |
6659 | @value{GDBN}'s internal symbol tables are stored (see @file{symtab.h}, | |
6660 | @file{gdbtypes.h}), you will find it much easier to understand the | |
6661 | code which uses and creates those symbol tables. | |
c906108c SS |
6662 | |
6663 | You may wish to process the information you are getting somehow, to | |
6664 | enhance your understanding of it. Summarize it, translate it to another | |
25822942 | 6665 | language, add some (perhaps trivial or non-useful) feature to @value{GDBN}, use |
c906108c SS |
6666 | the code to predict what a test case would do and write the test case |
6667 | and verify your prediction, etc. If you are reading code and your eyes | |
6668 | are starting to glaze over, this is a sign you need to use a more active | |
6669 | approach. | |
6670 | ||
25822942 | 6671 | Once you have a part of @value{GDBN} to start with, you can find more |
c906108c SS |
6672 | specifically the part you are looking for by stepping through each |
6673 | function with the @code{next} command. Do not use @code{step} or you | |
6674 | will quickly get distracted; when the function you are stepping through | |
6675 | calls another function try only to get a big-picture understanding | |
6676 | (perhaps using the comment at the beginning of the function being | |
6677 | called) of what it does. This way you can identify which of the | |
6678 | functions being called by the function you are stepping through is the | |
6679 | one which you are interested in. You may need to examine the data | |
6680 | structures generated at each stage, with reference to the comments in | |
6681 | the header files explaining what the data structures are supposed to | |
6682 | look like. | |
6683 | ||
6684 | Of course, this same technique can be used if you are just reading the | |
6685 | code, rather than actually stepping through it. The same general | |
6686 | principle applies---when the code you are looking at calls something | |
6687 | else, just try to understand generally what the code being called does, | |
6688 | rather than worrying about all its details. | |
6689 | ||
56caf160 EZ |
6690 | @cindex command implementation |
6691 | A good place to start when tracking down some particular area is with | |
6692 | a command which invokes that feature. Suppose you want to know how | |
6693 | single-stepping works. As a @value{GDBN} user, you know that the | |
6694 | @code{step} command invokes single-stepping. The command is invoked | |
6695 | via command tables (see @file{command.h}); by convention the function | |
6696 | which actually performs the command is formed by taking the name of | |
6697 | the command and adding @samp{_command}, or in the case of an | |
6698 | @code{info} subcommand, @samp{_info}. For example, the @code{step} | |
6699 | command invokes the @code{step_command} function and the @code{info | |
6700 | display} command invokes @code{display_info}. When this convention is | |
6701 | not followed, you might have to use @code{grep} or @kbd{M-x | |
6702 | tags-search} in emacs, or run @value{GDBN} on itself and set a | |
6703 | breakpoint in @code{execute_command}. | |
6704 | ||
6705 | @cindex @code{bug-gdb} mailing list | |
c906108c SS |
6706 | If all of the above fail, it may be appropriate to ask for information |
6707 | on @code{bug-gdb}. But @emph{never} post a generic question like ``I was | |
6708 | wondering if anyone could give me some tips about understanding | |
25822942 | 6709 | @value{GDBN}''---if we had some magic secret we would put it in this manual. |
c906108c SS |
6710 | Suggestions for improving the manual are always welcome, of course. |
6711 | ||
33e16fad | 6712 | @node Debugging GDB,,,Hints |
c906108c | 6713 | |
25822942 | 6714 | @section Debugging @value{GDBN} with itself |
56caf160 | 6715 | @cindex debugging @value{GDBN} |
c906108c | 6716 | |
25822942 | 6717 | If @value{GDBN} is limping on your machine, this is the preferred way to get it |
c906108c SS |
6718 | fully functional. Be warned that in some ancient Unix systems, like |
6719 | Ultrix 4.2, a program can't be running in one process while it is being | |
56caf160 | 6720 | debugged in another. Rather than typing the command @kbd{@w{./gdb |
c906108c | 6721 | ./gdb}}, which works on Suns and such, you can copy @file{gdb} to |
56caf160 | 6722 | @file{gdb2} and then type @kbd{@w{./gdb ./gdb2}}. |
c906108c | 6723 | |
25822942 | 6724 | When you run @value{GDBN} in the @value{GDBN} source directory, it will read a |
c906108c SS |
6725 | @file{.gdbinit} file that sets up some simple things to make debugging |
6726 | gdb easier. The @code{info} command, when executed without a subcommand | |
25822942 | 6727 | in a @value{GDBN} being debugged by gdb, will pop you back up to the top level |
c906108c SS |
6728 | gdb. See @file{.gdbinit} for details. |
6729 | ||
6730 | If you use emacs, you will probably want to do a @code{make TAGS} after | |
6731 | you configure your distribution; this will put the machine dependent | |
6732 | routines for your local machine where they will be accessed first by | |
6733 | @kbd{M-.} | |
6734 | ||
25822942 | 6735 | Also, make sure that you've either compiled @value{GDBN} with your local cc, or |
c906108c SS |
6736 | have run @code{fixincludes} if you are compiling with gcc. |
6737 | ||
6738 | @section Submitting Patches | |
6739 | ||
56caf160 | 6740 | @cindex submitting patches |
c906108c | 6741 | Thanks for thinking of offering your changes back to the community of |
25822942 | 6742 | @value{GDBN} users. In general we like to get well designed enhancements. |
c906108c SS |
6743 | Thanks also for checking in advance about the best way to transfer the |
6744 | changes. | |
6745 | ||
25822942 DB |
6746 | The @value{GDBN} maintainers will only install ``cleanly designed'' patches. |
6747 | This manual summarizes what we believe to be clean design for @value{GDBN}. | |
c906108c SS |
6748 | |
6749 | If the maintainers don't have time to put the patch in when it arrives, | |
6750 | or if there is any question about a patch, it goes into a large queue | |
6751 | with everyone else's patches and bug reports. | |
6752 | ||
56caf160 | 6753 | @cindex legal papers for code contributions |
c906108c SS |
6754 | The legal issue is that to incorporate substantial changes requires a |
6755 | copyright assignment from you and/or your employer, granting ownership | |
6756 | of the changes to the Free Software Foundation. You can get the | |
9e0b60a8 JM |
6757 | standard documents for doing this by sending mail to @code{gnu@@gnu.org} |
6758 | and asking for it. We recommend that people write in "All programs | |
6759 | owned by the Free Software Foundation" as "NAME OF PROGRAM", so that | |
56caf160 EZ |
6760 | changes in many programs (not just @value{GDBN}, but GAS, Emacs, GCC, |
6761 | etc) can be | |
9e0b60a8 | 6762 | contributed with only one piece of legalese pushed through the |
be9c6c35 | 6763 | bureaucracy and filed with the FSF. We can't start merging changes until |
9e0b60a8 JM |
6764 | this paperwork is received by the FSF (their rules, which we follow |
6765 | since we maintain it for them). | |
c906108c SS |
6766 | |
6767 | Technically, the easiest way to receive changes is to receive each | |
56caf160 EZ |
6768 | feature as a small context diff or unidiff, suitable for @code{patch}. |
6769 | Each message sent to me should include the changes to C code and | |
6770 | header files for a single feature, plus @file{ChangeLog} entries for | |
6771 | each directory where files were modified, and diffs for any changes | |
6772 | needed to the manuals (@file{gdb/doc/gdb.texinfo} or | |
6773 | @file{gdb/doc/gdbint.texinfo}). If there are a lot of changes for a | |
6774 | single feature, they can be split down into multiple messages. | |
9e0b60a8 JM |
6775 | |
6776 | In this way, if we read and like the feature, we can add it to the | |
c906108c | 6777 | sources with a single patch command, do some testing, and check it in. |
56caf160 EZ |
6778 | If you leave out the @file{ChangeLog}, we have to write one. If you leave |
6779 | out the doc, we have to puzzle out what needs documenting. Etc., etc. | |
c906108c | 6780 | |
9e0b60a8 JM |
6781 | The reason to send each change in a separate message is that we will not |
6782 | install some of the changes. They'll be returned to you with questions | |
6783 | or comments. If we're doing our job correctly, the message back to you | |
c906108c | 6784 | will say what you have to fix in order to make the change acceptable. |
9e0b60a8 JM |
6785 | The reason to have separate messages for separate features is so that |
6786 | the acceptable changes can be installed while one or more changes are | |
6787 | being reworked. If multiple features are sent in a single message, we | |
6788 | tend to not put in the effort to sort out the acceptable changes from | |
6789 | the unacceptable, so none of the features get installed until all are | |
6790 | acceptable. | |
6791 | ||
6792 | If this sounds painful or authoritarian, well, it is. But we get a lot | |
6793 | of bug reports and a lot of patches, and many of them don't get | |
6794 | installed because we don't have the time to finish the job that the bug | |
c906108c SS |
6795 | reporter or the contributor could have done. Patches that arrive |
6796 | complete, working, and well designed, tend to get installed on the day | |
9e0b60a8 JM |
6797 | they arrive. The others go into a queue and get installed as time |
6798 | permits, which, since the maintainers have many demands to meet, may not | |
6799 | be for quite some time. | |
c906108c | 6800 | |
56caf160 | 6801 | Please send patches directly to |
47b95330 | 6802 | @email{gdb-patches@@sources.redhat.com, the @value{GDBN} maintainers}. |
c906108c SS |
6803 | |
6804 | @section Obsolete Conditionals | |
56caf160 | 6805 | @cindex obsolete code |
c906108c | 6806 | |
25822942 | 6807 | Fragments of old code in @value{GDBN} sometimes reference or set the following |
c906108c SS |
6808 | configuration macros. They should not be used by new code, and old uses |
6809 | should be removed as those parts of the debugger are otherwise touched. | |
6810 | ||
6811 | @table @code | |
c906108c SS |
6812 | @item STACK_END_ADDR |
6813 | This macro used to define where the end of the stack appeared, for use | |
6814 | in interpreting core file formats that don't record this address in the | |
25822942 DB |
6815 | core file itself. This information is now configured in BFD, and @value{GDBN} |
6816 | gets the info portably from there. The values in @value{GDBN}'s configuration | |
c906108c | 6817 | files should be moved into BFD configuration files (if needed there), |
25822942 | 6818 | and deleted from all of @value{GDBN}'s config files. |
c906108c SS |
6819 | |
6820 | Any @file{@var{foo}-xdep.c} file that references STACK_END_ADDR | |
6821 | is so old that it has never been converted to use BFD. Now that's old! | |
6822 | ||
c906108c SS |
6823 | @end table |
6824 | ||
bcd7e15f | 6825 | @include observer.texi |
2154891a | 6826 | @raisesections |
aab4e0ec | 6827 | @include fdl.texi |
2154891a | 6828 | @lowersections |
aab4e0ec | 6829 | |
56caf160 EZ |
6830 | @node Index |
6831 | @unnumbered Index | |
6832 | ||
6833 | @printindex cp | |
6834 | ||
c906108c | 6835 | @bye |