Commit | Line | Data |
---|---|---|
9742079a | 1 | \input texinfo @c -*- texinfo -*- |
c906108c | 2 | @setfilename gdbint.info |
25822942 | 3 | @include gdb-cfg.texi |
e9c75b65 EZ |
4 | @dircategory Programming & development tools. |
5 | @direntry | |
c906108c SS |
6 | START-INFO-DIR-ENTRY |
7 | * Gdb-Internals: (gdbint). The GNU debugger's internals. | |
8 | END-INFO-DIR-ENTRY | |
e9c75b65 | 9 | @end direntry |
c906108c SS |
10 | |
11 | @ifinfo | |
25822942 | 12 | This file documents the internals of the GNU debugger @value{GDBN}. |
e9c75b65 EZ |
13 | Copyright 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001 |
14 | Free Software Foundation, Inc. | |
c906108c SS |
15 | Contributed by Cygnus Solutions. Written by John Gilmore. |
16 | Second Edition by Stan Shebs. | |
17 | ||
e9c75b65 EZ |
18 | Permission is granted to copy, distribute and/or modify this document |
19 | under the terms of the GNU Free Documentation License, Version 1.1 or | |
20 | any later version published by the Free Software Foundation; with the | |
21 | Invariant Sections being ``Algorithms'' and ``Porting GDB'', with the | |
22 | Front-Cover texts being ``A GNU Manual,'' and with the Back-Cover | |
23 | Texts as in (a) below. | |
c906108c | 24 | |
e9c75b65 EZ |
25 | (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify |
26 | this GNU Manual, like GNU software. Copies published by the Free | |
27 | Software Foundation raise funds for GNU development.'' | |
c906108c SS |
28 | @end ifinfo |
29 | ||
30 | @setchapternewpage off | |
25822942 | 31 | @settitle @value{GDBN} Internals |
c906108c | 32 | |
56caf160 EZ |
33 | @syncodeindex fn cp |
34 | @syncodeindex vr cp | |
35 | ||
c906108c | 36 | @titlepage |
25822942 | 37 | @title @value{GDBN} Internals |
c906108c SS |
38 | @subtitle{A guide to the internals of the GNU debugger} |
39 | @author John Gilmore | |
40 | @author Cygnus Solutions | |
41 | @author Second Edition: | |
42 | @author Stan Shebs | |
43 | @author Cygnus Solutions | |
44 | @page | |
45 | @tex | |
46 | \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$ | |
47 | \xdef\manvers{\$Revision$} % For use in headers, footers too | |
48 | {\parskip=0pt | |
49 | \hfill Cygnus Solutions\par | |
50 | \hfill \manvers\par | |
51 | \hfill \TeX{}info \texinfoversion\par | |
52 | } | |
53 | @end tex | |
54 | ||
55 | @vskip 0pt plus 1filll | |
e9c75b65 EZ |
56 | Copyright @copyright{} 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001 |
57 | Free Software Foundation, Inc. | |
c906108c | 58 | |
e9c75b65 EZ |
59 | Permission is granted to copy, distribute and/or modify this document |
60 | under the terms of the GNU Free Documentation License, Version 1.1 or | |
61 | any later version published by the Free Software Foundation; with the | |
62 | Invariant Sections being ``Algorithms'' and ``Porting GDB'', with the | |
63 | Front-Cover texts being ``A GNU Manual,'' and with the Back-Cover | |
64 | Texts as in (a) below. | |
c906108c | 65 | |
e9c75b65 EZ |
66 | (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify |
67 | this GNU Manual, like GNU software. Copies published by the Free | |
68 | Software Foundation raise funds for GNU development.'' | |
c906108c SS |
69 | @end titlepage |
70 | ||
449f3b6c AC |
71 | @c TeX can handle the contents at the start but makeinfo 3.12 can not |
72 | @iftex | |
73 | @contents | |
74 | @end iftex | |
75 | ||
c906108c SS |
76 | @node Top |
77 | @c Perhaps this should be the title of the document (but only for info, | |
78 | @c not for TeX). Existing GNU manuals seem inconsistent on this point. | |
79 | @top Scope of this Document | |
80 | ||
25822942 DB |
81 | This document documents the internals of the GNU debugger, @value{GDBN}. It |
82 | includes description of @value{GDBN}'s key algorithms and operations, as well | |
83 | as the mechanisms that adapt @value{GDBN} to specific hosts and targets. | |
c906108c SS |
84 | |
85 | @menu | |
86 | * Requirements:: | |
87 | * Overall Structure:: | |
88 | * Algorithms:: | |
89 | * User Interface:: | |
90 | * Symbol Handling:: | |
91 | * Language Support:: | |
92 | * Host Definition:: | |
93 | * Target Architecture Definition:: | |
94 | * Target Vector Definition:: | |
95 | * Native Debugging:: | |
96 | * Support Libraries:: | |
97 | * Coding:: | |
98 | * Porting GDB:: | |
085dd6e6 | 99 | * Testsuite:: |
c906108c | 100 | * Hints:: |
56caf160 | 101 | * Index:: |
c906108c SS |
102 | @end menu |
103 | ||
104 | @node Requirements | |
105 | ||
106 | @chapter Requirements | |
56caf160 | 107 | @cindex requirements for @value{GDBN} |
c906108c SS |
108 | |
109 | Before diving into the internals, you should understand the formal | |
56caf160 EZ |
110 | requirements and other expectations for @value{GDBN}. Although some |
111 | of these may seem obvious, there have been proposals for @value{GDBN} | |
112 | that have run counter to these requirements. | |
c906108c | 113 | |
56caf160 EZ |
114 | First of all, @value{GDBN} is a debugger. It's not designed to be a |
115 | front panel for embedded systems. It's not a text editor. It's not a | |
116 | shell. It's not a programming environment. | |
c906108c | 117 | |
56caf160 EZ |
118 | @value{GDBN} is an interactive tool. Although a batch mode is |
119 | available, @value{GDBN}'s primary role is to interact with a human | |
120 | programmer. | |
c906108c | 121 | |
56caf160 EZ |
122 | @value{GDBN} should be responsive to the user. A programmer hot on |
123 | the trail of a nasty bug, and operating under a looming deadline, is | |
124 | going to be very impatient of everything, including the response time | |
125 | to debugger commands. | |
c906108c | 126 | |
56caf160 EZ |
127 | @value{GDBN} should be relatively permissive, such as for expressions. |
128 | While the compiler should be picky (or have the option to be made | |
be9c6c35 | 129 | picky), since source code lives for a long time usually, the |
56caf160 EZ |
130 | programmer doing debugging shouldn't be spending time figuring out to |
131 | mollify the debugger. | |
c906108c | 132 | |
56caf160 EZ |
133 | @value{GDBN} will be called upon to deal with really large programs. |
134 | Executable sizes of 50 to 100 megabytes occur regularly, and we've | |
135 | heard reports of programs approaching 1 gigabyte in size. | |
c906108c | 136 | |
56caf160 EZ |
137 | @value{GDBN} should be able to run everywhere. No other debugger is |
138 | available for even half as many configurations as @value{GDBN} | |
139 | supports. | |
c906108c SS |
140 | |
141 | ||
142 | @node Overall Structure | |
143 | ||
144 | @chapter Overall Structure | |
145 | ||
56caf160 EZ |
146 | @value{GDBN} consists of three major subsystems: user interface, |
147 | symbol handling (the @dfn{symbol side}), and target system handling (the | |
148 | @dfn{target side}). | |
c906108c | 149 | |
2e685b93 | 150 | The user interface consists of several actual interfaces, plus |
c906108c SS |
151 | supporting code. |
152 | ||
153 | The symbol side consists of object file readers, debugging info | |
154 | interpreters, symbol table management, source language expression | |
155 | parsing, type and value printing. | |
156 | ||
157 | The target side consists of execution control, stack frame analysis, and | |
158 | physical target manipulation. | |
159 | ||
160 | The target side/symbol side division is not formal, and there are a | |
161 | number of exceptions. For instance, core file support involves symbolic | |
162 | elements (the basic core file reader is in BFD) and target elements (it | |
163 | supplies the contents of memory and the values of registers). Instead, | |
164 | this division is useful for understanding how the minor subsystems | |
165 | should fit together. | |
166 | ||
167 | @section The Symbol Side | |
168 | ||
56caf160 EZ |
169 | The symbolic side of @value{GDBN} can be thought of as ``everything |
170 | you can do in @value{GDBN} without having a live program running''. | |
171 | For instance, you can look at the types of variables, and evaluate | |
172 | many kinds of expressions. | |
c906108c SS |
173 | |
174 | @section The Target Side | |
175 | ||
56caf160 EZ |
176 | The target side of @value{GDBN} is the ``bits and bytes manipulator''. |
177 | Although it may make reference to symbolic info here and there, most | |
178 | of the target side will run with only a stripped executable | |
179 | available---or even no executable at all, in remote debugging cases. | |
c906108c SS |
180 | |
181 | Operations such as disassembly, stack frame crawls, and register | |
182 | display, are able to work with no symbolic info at all. In some cases, | |
25822942 | 183 | such as disassembly, @value{GDBN} will use symbolic info to present addresses |
c906108c SS |
184 | relative to symbols rather than as raw numbers, but it will work either |
185 | way. | |
186 | ||
187 | @section Configurations | |
188 | ||
56caf160 EZ |
189 | @cindex host |
190 | @cindex target | |
25822942 | 191 | @dfn{Host} refers to attributes of the system where @value{GDBN} runs. |
c906108c SS |
192 | @dfn{Target} refers to the system where the program being debugged |
193 | executes. In most cases they are the same machine, in which case a | |
194 | third type of @dfn{Native} attributes come into play. | |
195 | ||
196 | Defines and include files needed to build on the host are host support. | |
197 | Examples are tty support, system defined types, host byte order, host | |
198 | float format. | |
199 | ||
200 | Defines and information needed to handle the target format are target | |
201 | dependent. Examples are the stack frame format, instruction set, | |
202 | breakpoint instruction, registers, and how to set up and tear down the stack | |
203 | to call a function. | |
204 | ||
205 | Information that is only needed when the host and target are the same, | |
206 | is native dependent. One example is Unix child process support; if the | |
207 | host and target are not the same, doing a fork to start the target | |
208 | process is a bad idea. The various macros needed for finding the | |
209 | registers in the @code{upage}, running @code{ptrace}, and such are all | |
210 | in the native-dependent files. | |
211 | ||
212 | Another example of native-dependent code is support for features that | |
213 | are really part of the target environment, but which require | |
214 | @code{#include} files that are only available on the host system. Core | |
215 | file handling and @code{setjmp} handling are two common cases. | |
216 | ||
25822942 | 217 | When you want to make @value{GDBN} work ``native'' on a particular machine, you |
c906108c SS |
218 | have to include all three kinds of information. |
219 | ||
220 | ||
221 | @node Algorithms | |
222 | ||
223 | @chapter Algorithms | |
56caf160 | 224 | @cindex algorithms |
c906108c | 225 | |
56caf160 EZ |
226 | @value{GDBN} uses a number of debugging-specific algorithms. They are |
227 | often not very complicated, but get lost in the thicket of special | |
228 | cases and real-world issues. This chapter describes the basic | |
229 | algorithms and mentions some of the specific target definitions that | |
230 | they use. | |
c906108c SS |
231 | |
232 | @section Frames | |
233 | ||
56caf160 EZ |
234 | @cindex frame |
235 | @cindex call stack frame | |
236 | A frame is a construct that @value{GDBN} uses to keep track of calling | |
237 | and called functions. | |
c906108c | 238 | |
56caf160 EZ |
239 | @findex create_new_frame |
240 | @vindex FRAME_FP | |
c906108c | 241 | @code{FRAME_FP} in the machine description has no meaning to the |
56caf160 EZ |
242 | machine-independent part of @value{GDBN}, except that it is used when |
243 | setting up a new frame from scratch, as follows: | |
c906108c SS |
244 | |
245 | @example | |
246 | create_new_frame (read_register (FP_REGNUM), read_pc ())); | |
247 | @end example | |
248 | ||
56caf160 | 249 | @cindex frame pointer register |
c906108c SS |
250 | Other than that, all the meaning imparted to @code{FP_REGNUM} is |
251 | imparted by the machine-dependent code. So, @code{FP_REGNUM} can have | |
252 | any value that is convenient for the code that creates new frames. | |
253 | (@code{create_new_frame} calls @code{INIT_EXTRA_FRAME_INFO} if it is | |
254 | defined; that is where you should use the @code{FP_REGNUM} value, if | |
255 | your frames are nonstandard.) | |
256 | ||
56caf160 EZ |
257 | @cindex frame chain |
258 | Given a @value{GDBN} frame, define @code{FRAME_CHAIN} to determine the | |
259 | address of the calling function's frame. This will be used to create | |
260 | a new @value{GDBN} frame struct, and then @code{INIT_EXTRA_FRAME_INFO} | |
261 | and @code{INIT_FRAME_PC} will be called for the new frame. | |
c906108c SS |
262 | |
263 | @section Breakpoint Handling | |
264 | ||
56caf160 | 265 | @cindex breakpoints |
c906108c SS |
266 | In general, a breakpoint is a user-designated location in the program |
267 | where the user wants to regain control if program execution ever reaches | |
268 | that location. | |
269 | ||
270 | There are two main ways to implement breakpoints; either as ``hardware'' | |
271 | breakpoints or as ``software'' breakpoints. | |
272 | ||
56caf160 EZ |
273 | @cindex hardware breakpoints |
274 | @cindex program counter | |
c906108c SS |
275 | Hardware breakpoints are sometimes available as a builtin debugging |
276 | features with some chips. Typically these work by having dedicated | |
277 | register into which the breakpoint address may be stored. If the PC | |
56caf160 | 278 | (shorthand for @dfn{program counter}) |
c906108c | 279 | ever matches a value in a breakpoint registers, the CPU raises an |
56caf160 EZ |
280 | exception and reports it to @value{GDBN}. |
281 | ||
282 | Another possibility is when an emulator is in use; many emulators | |
283 | include circuitry that watches the address lines coming out from the | |
284 | processor, and force it to stop if the address matches a breakpoint's | |
285 | address. | |
286 | ||
287 | A third possibility is that the target already has the ability to do | |
288 | breakpoints somehow; for instance, a ROM monitor may do its own | |
289 | software breakpoints. So although these are not literally ``hardware | |
290 | breakpoints'', from @value{GDBN}'s point of view they work the same; | |
291 | @value{GDBN} need not do nothing more than set the breakpoint and wait | |
292 | for something to happen. | |
c906108c SS |
293 | |
294 | Since they depend on hardware resources, hardware breakpoints may be | |
56caf160 | 295 | limited in number; when the user asks for more, @value{GDBN} will |
9742079a EZ |
296 | start trying to set software breakpoints. (On some architectures, |
297 | notably the 32-bit x86 platforms, @value{GDBN} cannot alsways know | |
298 | whether there's enough hardware resources to insert all the hardware | |
299 | breakpoints and watchpoints. On those platforms, @value{GDBN} prints | |
300 | an error message only when the program being debugged is continued.) | |
56caf160 EZ |
301 | |
302 | @cindex software breakpoints | |
303 | Software breakpoints require @value{GDBN} to do somewhat more work. | |
304 | The basic theory is that @value{GDBN} will replace a program | |
305 | instruction with a trap, illegal divide, or some other instruction | |
306 | that will cause an exception, and then when it's encountered, | |
307 | @value{GDBN} will take the exception and stop the program. When the | |
308 | user says to continue, @value{GDBN} will restore the original | |
c906108c SS |
309 | instruction, single-step, re-insert the trap, and continue on. |
310 | ||
311 | Since it literally overwrites the program being tested, the program area | |
be9c6c35 | 312 | must be writable, so this technique won't work on programs in ROM. It |
c906108c | 313 | can also distort the behavior of programs that examine themselves, |
56caf160 | 314 | although such a situation would be highly unusual. |
c906108c SS |
315 | |
316 | Also, the software breakpoint instruction should be the smallest size of | |
317 | instruction, so it doesn't overwrite an instruction that might be a jump | |
318 | target, and cause disaster when the program jumps into the middle of the | |
319 | breakpoint instruction. (Strictly speaking, the breakpoint must be no | |
320 | larger than the smallest interval between instructions that may be jump | |
321 | targets; perhaps there is an architecture where only even-numbered | |
322 | instructions may jumped to.) Note that it's possible for an instruction | |
323 | set not to have any instructions usable for a software breakpoint, | |
324 | although in practice only the ARC has failed to define such an | |
325 | instruction. | |
326 | ||
56caf160 | 327 | @findex BREAKPOINT |
c906108c SS |
328 | The basic definition of the software breakpoint is the macro |
329 | @code{BREAKPOINT}. | |
330 | ||
331 | Basic breakpoint object handling is in @file{breakpoint.c}. However, | |
332 | much of the interesting breakpoint action is in @file{infrun.c}. | |
333 | ||
334 | @section Single Stepping | |
335 | ||
336 | @section Signal Handling | |
337 | ||
338 | @section Thread Handling | |
339 | ||
340 | @section Inferior Function Calls | |
341 | ||
342 | @section Longjmp Support | |
343 | ||
56caf160 | 344 | @cindex @code{longjmp} debugging |
25822942 | 345 | @value{GDBN} has support for figuring out that the target is doing a |
c906108c SS |
346 | @code{longjmp} and for stopping at the target of the jump, if we are |
347 | stepping. This is done with a few specialized internal breakpoints, | |
56caf160 EZ |
348 | which are visible in the output of the @samp{maint info breakpoint} |
349 | command. | |
c906108c | 350 | |
56caf160 | 351 | @findex GET_LONGJMP_TARGET |
c906108c SS |
352 | To make this work, you need to define a macro called |
353 | @code{GET_LONGJMP_TARGET}, which will examine the @code{jmp_buf} | |
354 | structure and extract the longjmp target address. Since @code{jmp_buf} | |
355 | is target specific, you will need to define it in the appropriate | |
56caf160 | 356 | @file{tm-@var{target}.h} file. Look in @file{tm-sun4os4.h} and |
c906108c SS |
357 | @file{sparc-tdep.c} for examples of how to do this. |
358 | ||
9742079a EZ |
359 | @section Watchpoints |
360 | @cindex watchpoints | |
361 | ||
362 | Watchpoints are a special kind of breakpoints (@pxref{Algorithms, | |
363 | breakpoints}) which break when data is accessed rather than when some | |
364 | instruction is executed. When you have data which changes without | |
365 | your knowing what code does that, watchpoints are the silver bullet to | |
366 | hunt down and kill such bugs. | |
367 | ||
368 | @cindex hardware watchpoints | |
369 | @cindex software watchpoints | |
370 | Watchpoints can be either hardware-assisted or not; the latter type is | |
371 | known as ``software watchpoints.'' @value{GDBN} always uses | |
372 | hardware-assisted watchpoints if they are available, and falls back on | |
373 | software watchpoints otherwise. Typical situations where @value{GDBN} | |
374 | will use software watchpoints are: | |
375 | ||
376 | @itemize @bullet | |
377 | @item | |
378 | The watched memory region is too large for the underlying hardware | |
379 | watchpoint support. For example, each x86 debug register can watch up | |
380 | to 4 bytes of memory, so trying to watch data structures whose size is | |
381 | more than 16 bytes will cause @value{GDBN} to use software | |
382 | watchpoints. | |
383 | ||
384 | @item | |
385 | The value of the expression to be watched depends on data held in | |
386 | registers (as opposed to memory). | |
387 | ||
388 | @item | |
389 | Too many different watchpoints requested. (On some architectures, | |
390 | this situation is impossible to detect until the debugged program is | |
391 | resumed.) Note that x86 debug registers are used both for hardware | |
392 | breakpoints and for watchpoints, so setting too many hardware | |
393 | breakpoints might cause watchpoint insertion to fail. | |
394 | ||
395 | @item | |
396 | No hardware-assisted watchpoints provided by the target | |
397 | implementation. | |
398 | @end itemize | |
399 | ||
400 | Software watchpoints are very slow, since @value{GDBN} needs to | |
401 | single-step the program being debugged and test the value of the | |
402 | watched expression(s) after each instruction. The rest of this | |
403 | section is mostly irrelevant for software watchpoints. | |
404 | ||
405 | @value{GDBN} uses several macros and primitives to support hardware | |
406 | watchpoints: | |
407 | ||
408 | @table @code | |
409 | @findex TARGET_HAS_HARDWARE_WATCHPOINTS | |
410 | @item TARGET_HAS_HARDWARE_WATCHPOINTS | |
411 | If defined, the target supports hardware watchpoints. | |
412 | ||
413 | @findex TARGET_CAN_USE_HARDWARE_WATCHPOINT | |
414 | @item TARGET_CAN_USE_HARDWARE_WATCHPOINT (@var{type}, @var{count}, @var{other}) | |
415 | Return the number of hardware watchpoints of type @var{type} that are | |
416 | possible to be set. The value is positive if @var{count} watchpoints | |
417 | of this type can be set, zero if setting watchpoints of this type is | |
418 | not supported, and negative if @var{count} is more than the maximum | |
419 | number of watchpoints of type @var{type} that can be set. @var{other} | |
420 | is non-zero if other types of watchpoints are currently enabled (there | |
421 | are architectures which cannot set watchpoints of different types at | |
422 | the same time). | |
423 | ||
424 | @findex TARGET_REGION_OK_FOR_HW_WATCHPOINT | |
425 | @item TARGET_REGION_OK_FOR_HW_WATCHPOINT (@var{addr}, @var{len}) | |
426 | Return non-zero if hardware watchpoints can be used to watch a region | |
427 | whose address is @var{addr} and whose length in bytes is @var{len}. | |
428 | ||
429 | @findex TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT | |
430 | @item TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (@var{size}) | |
431 | Return non-zero if hardware watchpoints can be used to watch a region | |
432 | whose size is @var{size}. @value{GDBN} only uses this macro as a | |
433 | fall-back, in case @code{TARGET_REGION_OK_FOR_HW_WATCHPOINT} is not | |
434 | defined. | |
435 | ||
436 | @findex TARGET_DISABLE_HW_WATCHPOINTS | |
437 | @item TARGET_DISABLE_HW_WATCHPOINTS (@var{pid}) | |
438 | Disables watchpoints in the process identified by @var{pid}. This is | |
439 | used, e.g., on HP-UX which provides operations to disable and enable | |
440 | the page-level memory protection that implements hardware watchpoints | |
441 | on that platform. | |
442 | ||
443 | @findex TARGET_ENABLE_HW_WATCHPOINTS | |
444 | @item TARGET_ENABLE_HW_WATCHPOINTS (@var{pid}) | |
445 | Enables watchpoints in the process identified by @var{pid}. This is | |
446 | used, e.g., on HP-UX which provides operations to disable and enable | |
447 | the page-level memory protection that implements hardware watchpoints | |
448 | on that platform. | |
449 | ||
450 | @findex TARGET_RANGE_PROFITABLE_FOR_HW_WATCHPOINT | |
451 | @item TARGET_RANGE_PROFITABLE_FOR_HW_WATCHPOINT (@var{pid},@var{start},@var{len}) | |
452 | Some addresses may not be profitable to use hardware to watch, or may | |
453 | be difficult to understand when the addressed object is out of scope, | |
454 | and hence should not be watched with hardware watchpoints. On some | |
455 | targets, this may have severe performance penalties, such that we | |
456 | might as well use regular watchpoints, and save (possibly precious) | |
457 | hardware watchpoints for other locations. | |
458 | ||
459 | @findex target_insert_watchpoint | |
460 | @findex target_remove_watchpoint | |
461 | @item target_insert_watchpoint (@var{addr}, @var{len}, @var{type}) | |
462 | @itemx target_remove_watchpoint (@var{addr}, @var{len}, @var{type}) | |
463 | Insert or remove a hardware watchpoint starting at @var{addr}, for | |
464 | @var{len} bytes. @var{type} is the watchpoint type, one of the | |
465 | possible values of the enumerated data type @code{target_hw_bp_type}, | |
466 | defined by @file{breakpoint.h} as follows: | |
467 | ||
468 | @example | |
469 | enum target_hw_bp_type | |
470 | @{ | |
471 | hw_write = 0, /* Common (write) HW watchpoint */ | |
472 | hw_read = 1, /* Read HW watchpoint */ | |
473 | hw_access = 2, /* Access (read or write) HW watchpoint */ | |
474 | hw_execute = 3 /* Execute HW breakpoint */ | |
475 | @}; | |
476 | @end example | |
477 | ||
478 | @noindent | |
479 | These two macros should return 0 for success, non-zero for failure. | |
480 | ||
481 | @cindex insert or remove hardware breakpoint | |
482 | @findex target_remove_hw_breakpoint | |
483 | @findex target_insert_hw_breakpoint | |
484 | @item target_remove_hw_breakpoint (@var{addr}, @var{shadow}) | |
485 | @itemx target_insert_hw_breakpoint (@var{addr}, @var{shadow}) | |
486 | Insert or remove a hardware-assisted breakpoint at address @var{addr}. | |
487 | Returns zero for success, non-zero for failure. @var{shadow} is the | |
488 | real contents of the byte where the breakpoint has been inserted; it | |
489 | is generally not valid when hardware breakpoints are used, but since | |
490 | no other code touches these values, the implementations of the above | |
491 | two macros can use them for their internal purposes. | |
492 | ||
493 | @findex target_stopped_data_address | |
494 | @item target_stopped_data_address () | |
495 | If the inferior has some watchpoint that triggered, return the address | |
496 | associated with that watchpoint. Otherwise, return zero. | |
497 | ||
498 | @findex DECR_PC_AFTER_HW_BREAK | |
499 | @item DECR_PC_AFTER_HW_BREAK | |
500 | If defined, @value{GDBN} decrements the program counter by the value | |
501 | of @code{DECR_PC_AFTER_HW_BREAK} after a hardware break-point. This | |
502 | overrides the value of @code{DECR_PC_AFTER_BREAK} when a breakpoint | |
503 | that breaks is a hardware-assisted breakpoint. | |
504 | ||
505 | @findex HAVE_STEPPABLE_WATCHPOINT | |
506 | @item HAVE_STEPPABLE_WATCHPOINT | |
507 | If defined to a non-zero value, it is not necessary to disable a | |
508 | watchpoint to step over it. | |
509 | ||
510 | @findex HAVE_NONSTEPPABLE_WATCHPOINT | |
511 | @item HAVE_NONSTEPPABLE_WATCHPOINT | |
512 | If defined to a non-zero value, @value{GDBN} should disable a | |
513 | watchpoint to step the inferior over it. | |
514 | ||
515 | @findex HAVE_CONTINUABLE_WATCHPOINT | |
516 | @item HAVE_CONTINUABLE_WATCHPOINT | |
517 | If defined to a non-zero value, it is possible to continue the | |
518 | inferior after a watchpoint has been hit. | |
519 | ||
520 | @findex CANNOT_STEP_HW_WATCHPOINTS | |
521 | @item CANNOT_STEP_HW_WATCHPOINTS | |
522 | If this is defined to a non-zero value, @value{GDBN} will remove all | |
523 | watchpoints before stepping the inferior. | |
524 | ||
525 | @findex STOPPED_BY_WATCHPOINT | |
526 | @item STOPPED_BY_WATCHPOINT (@var{wait_status}) | |
527 | Return non-zero if stopped by a watchpoint. @var{wait_status} is of | |
528 | the type @code{struct target_waitstatus}, defined by @file{target.h}. | |
529 | @end table | |
530 | ||
531 | @subsection x86 Watchpoints | |
532 | @cindex x86 debug registers | |
533 | @cindex watchpoints, on x86 | |
534 | ||
535 | The 32-bit Intel x86 (a.k.a.@: ia32) processors feature special debug | |
536 | registers designed to facilitate debugging. @value{GDBN} provides a | |
537 | generic library of functions that x86-based ports can use to implement | |
538 | support for watchpoints and hardware-assisted breakpoints. This | |
539 | subsection documents the x86 watchpoint facilities in @value{GDBN}. | |
540 | ||
541 | To use the generic x86 watchpoint support, a port should do the | |
542 | following: | |
543 | ||
544 | @itemize @bullet | |
545 | @findex I386_USE_GENERIC_WATCHPOINTS | |
546 | @item | |
547 | Define the macro @code{I386_USE_GENERIC_WATCHPOINTS} somewhere in the | |
548 | target-dependent headers. | |
549 | ||
550 | @item | |
551 | Include the @file{config/i386/nm-i386.h} header file @emph{after} | |
552 | defining @code{I386_USE_GENERIC_WATCHPOINTS}. | |
553 | ||
554 | @item | |
555 | Add @file{i386-nat.o} to the value of the Make variable | |
556 | @code{NATDEPFILES} (@pxref{Native Debugging, NATDEPFILES}) or | |
557 | @code{TDEPFILES} (@pxref{Target Architecture Definition, TDEPFILES}). | |
558 | ||
559 | @item | |
560 | Provide implementations for the @code{I386_DR_LOW_*} macros described | |
561 | below. Typically, each macro should call a target-specific function | |
562 | which does the real work. | |
563 | @end itemize | |
564 | ||
565 | The x86 watchpoint support works by maintaining mirror images of the | |
566 | debug registers. Values are copied between the mirror images and the | |
567 | real debug registers via a set of macros which each target needs to | |
568 | provide: | |
569 | ||
570 | @table @code | |
571 | @findex I386_DR_LOW_SET_CONTROL | |
572 | @item I386_DR_LOW_SET_CONTROL (@var{val}) | |
573 | Set the Debug Control (DR7) register to the value @var{val}. | |
574 | ||
575 | @findex I386_DR_LOW_SET_ADDR | |
576 | @item I386_DR_LOW_SET_ADDR (@var{idx}, @var{addr}) | |
577 | Put the address @var{addr} into the debug register number @var{idx}. | |
578 | ||
579 | @findex I386_DR_LOW_RESET_ADDR | |
580 | @item I386_DR_LOW_RESET_ADDR (@var{idx}) | |
581 | Reset (i.e.@: zero out) the address stored in the debug register | |
582 | number @var{idx}. | |
583 | ||
584 | @findex I386_DR_LOW_GET_STATUS | |
585 | @item I386_DR_LOW_GET_STATUS | |
586 | Return the value of the Debug Status (DR6) register. This value is | |
587 | used immediately after it is returned by | |
588 | @code{I386_DR_LOW_GET_STATUS}, so as to support per-thread status | |
589 | register values. | |
590 | @end table | |
591 | ||
592 | For each one of the 4 debug registers (whose indices are from 0 to 3) | |
593 | that store addresses, a reference count is maintained by @value{GDBN}, | |
594 | to allow sharing of debug registers by several watchpoints. This | |
595 | allows users to define several watchpoints that watch the same | |
596 | expression, but with different conditions and/or commands, without | |
597 | wasting debug registers which are in short supply. @value{GDBN} | |
598 | maintains the reference counts internally, targets don't have to do | |
599 | anything to use this feature. | |
600 | ||
601 | The x86 debug registers can each watch a region that is 1, 2, or 4 | |
602 | bytes long. The ia32 architecture requires that each watched region | |
603 | be appropriately aligned: 2-byte region on 2-byte boundary, 4-byte | |
604 | region on 4-byte boundary. However, the x86 watchpoint support in | |
605 | @value{GDBN} can watch unaligned regions and regions larger than 4 | |
606 | bytes (up to 16 bytes) by allocating several debug registers to watch | |
607 | a single region. This allocation of several registers per a watched | |
608 | region is also done automatically without target code intervention. | |
609 | ||
610 | The generic x86 watchpoint support provides the following API for the | |
611 | @value{GDBN}'s application code: | |
612 | ||
613 | @table @code | |
614 | @findex i386_region_ok_for_watchpoint | |
615 | @item i386_region_ok_for_watchpoint (@var{addr}, @var{len}) | |
616 | The macro @code{TARGET_REGION_OK_FOR_HW_WATCHPOINT} is set to call | |
617 | this function. It counts the number of debug registers required to | |
618 | watch a given region, and returns a non-zero value if that number is | |
619 | less than 4, the number of debug registers available to x86 | |
620 | processors. | |
621 | ||
622 | @findex i386_stopped_data_address | |
623 | @item i386_stopped_data_address (void) | |
624 | The macros @code{STOPPED_BY_WATCHPOINT} and | |
625 | @code{target_stopped_data_address} are set to call this function. The | |
626 | argument passed to @code{STOPPED_BY_WATCHPOINT} is ignored. This | |
627 | function examines the breakpoint condition bits in the DR6 Debug | |
628 | Status register, as returned by the @code{I386_DR_LOW_GET_STATUS} | |
629 | macro, and returns the address associated with the first bit that is | |
630 | set in DR6. | |
631 | ||
632 | @findex i386_insert_watchpoint | |
633 | @findex i386_remove_watchpoint | |
634 | @item i386_insert_watchpoint (@var{addr}, @var{len}, @var{type}) | |
635 | @itemx i386_remove_watchpoint (@var{addr}, @var{len}, @var{type}) | |
636 | Insert or remove a watchpoint. The macros | |
637 | @code{target_insert_watchpoint} and @code{target_remove_watchpoint} | |
638 | are set to call these functions. @code{i386_insert_watchpoint} first | |
639 | looks for a debug register which is already set to watch the same | |
640 | region for the same access types; if found, it just increments the | |
641 | reference count of that debug register, thus implementing debug | |
642 | register sharing between watchpoints. If no such register is found, | |
643 | the function looks for a vacant debug register, sets its mirrorred | |
644 | value to @var{addr}, sets the mirrorred value of DR7 Debug Control | |
645 | register as appropriate for the @var{len} and @var{type} parameters, | |
646 | and then passes the new values of the debug register and DR7 to the | |
647 | inferior by calling @code{I386_DR_LOW_SET_ADDR} and | |
648 | @code{I386_DR_LOW_SET_CONTROL}. If more than one debug register is | |
649 | required to cover the given region, the above process is repeated for | |
650 | each debug register. | |
651 | ||
652 | @code{i386_remove_watchpoint} does the opposite: it resets the address | |
653 | in the mirrorred value of the debug register and its read/write and | |
654 | length bits in the mirrorred value of DR7, then passes these new | |
655 | values to the inferior via @code{I386_DR_LOW_RESET_ADDR} and | |
656 | @code{I386_DR_LOW_SET_CONTROL}. If a register is shared by several | |
657 | watchpoints, each time a @code{i386_remove_watchpoint} is called, it | |
658 | decrements the reference count, and only calls | |
659 | @code{I386_DR_LOW_RESET_ADDR} and @code{I386_DR_LOW_SET_CONTROL} when | |
660 | the count goes to zero. | |
661 | ||
662 | @findex i386_insert_hw_breakpoint | |
663 | @findex i386_remove_hw_breakpoint | |
664 | @item i386_insert_hw_breakpoint (@var{addr}, @var{shadow} | |
665 | @itemx i386_remove_hw_breakpoint (@var{addr}, @var{shadow}) | |
666 | These functions insert and remove hardware-assisted breakpoints. The | |
667 | macros @code{target_insert_hw_breakpoint} and | |
668 | @code{target_remove_hw_breakpoint} are set to call these functions. | |
669 | These functions work like @code{i386_insert_watchpoint} and | |
670 | @code{i386_remove_watchpoint}, respectively, except that they set up | |
671 | the debug registers to watch instruction execution, and each | |
672 | hardware-assisted breakpoint always requires exactly one debug | |
673 | register. | |
674 | ||
675 | @findex i386_stopped_by_hwbp | |
676 | @item i386_stopped_by_hwbp (void) | |
677 | This function returns non-zero if the inferior has some watchpoint or | |
678 | hardware breakpoint that triggered. It works like | |
679 | @code{i386_stopped_data_address}, except that it doesn't return the | |
680 | address whose watchpoint triggered. | |
681 | ||
682 | @findex i386_cleanup_dregs | |
683 | @item i386_cleanup_dregs (void) | |
684 | This function clears all the reference counts, addresses, and control | |
685 | bits in the mirror images of the debug registers. It doesn't affect | |
686 | the actual debug registers in the inferior process. | |
687 | @end table | |
688 | ||
689 | @noindent | |
690 | @strong{Notes:} | |
691 | @enumerate 1 | |
692 | @item | |
693 | x86 processors support setting watchpoints on I/O reads or writes. | |
694 | However, since no target supports this (as of March 2001), and since | |
695 | @code{enum target_hw_bp_type} doesn't even have an enumeration for I/O | |
696 | watchpoints, this feature is not yet available to @value{GDBN} running | |
697 | on x86. | |
698 | ||
699 | @item | |
700 | x86 processors can enable watchpoints locally, for the current task | |
701 | only, or globally, for all the tasks. For each debug register, | |
702 | there's a bit in the DR7 Debug Control register that determines | |
703 | whether the associated address is watched locally or globally. The | |
704 | current implementation of x86 watchpoint support in @value{GDBN} | |
705 | always sets watchpoints to be locally enabled, since global | |
706 | watchpoints might interfere with the underlying OS and are probably | |
707 | unavailable in many platforms. | |
708 | @end enumerate | |
709 | ||
c906108c SS |
710 | @node User Interface |
711 | ||
712 | @chapter User Interface | |
713 | ||
25822942 | 714 | @value{GDBN} has several user interfaces. Although the command-line interface |
c906108c SS |
715 | is the most common and most familiar, there are others. |
716 | ||
717 | @section Command Interpreter | |
718 | ||
56caf160 | 719 | @cindex command interpreter |
0ee54786 | 720 | @cindex CLI |
25822942 | 721 | The command interpreter in @value{GDBN} is fairly simple. It is designed to |
c906108c SS |
722 | allow for the set of commands to be augmented dynamically, and also |
723 | has a recursive subcommand capability, where the first argument to | |
724 | a command may itself direct a lookup on a different command list. | |
725 | ||
56caf160 EZ |
726 | For instance, the @samp{set} command just starts a lookup on the |
727 | @code{setlist} command list, while @samp{set thread} recurses | |
c906108c SS |
728 | to the @code{set_thread_cmd_list}. |
729 | ||
56caf160 EZ |
730 | @findex add_cmd |
731 | @findex add_com | |
c906108c SS |
732 | To add commands in general, use @code{add_cmd}. @code{add_com} adds to |
733 | the main command list, and should be used for those commands. The usual | |
cfeada60 | 734 | place to add commands is in the @code{_initialize_@var{xyz}} routines at |
9742079a | 735 | the ends of most source files. |
cfeada60 | 736 | |
56caf160 EZ |
737 | @cindex deprecating commands |
738 | @findex deprecate_cmd | |
cfeada60 FN |
739 | Before removing commands from the command set it is a good idea to |
740 | deprecate them for some time. Use @code{deprecate_cmd} on commands or | |
741 | aliases to set the deprecated flag. @code{deprecate_cmd} takes a | |
742 | @code{struct cmd_list_element} as it's first argument. You can use the | |
743 | return value from @code{add_com} or @code{add_cmd} to deprecate the | |
744 | command immediately after it is created. | |
745 | ||
c72e7388 | 746 | The first time a command is used the user will be warned and offered a |
cfeada60 FN |
747 | replacement (if one exists). Note that the replacement string passed to |
748 | @code{deprecate_cmd} should be the full name of the command, i.e. the | |
749 | entire string the user should type at the command line. | |
c906108c | 750 | |
0ee54786 EZ |
751 | @section UI-Independent Output---the @code{ui_out} Functions |
752 | @c This section is based on the documentation written by Fernando | |
753 | @c Nasser <fnasser@redhat.com>. | |
754 | ||
755 | @cindex @code{ui_out} functions | |
756 | The @code{ui_out} functions present an abstraction level for the | |
757 | @value{GDBN} output code. They hide the specifics of different user | |
758 | interfaces supported by @value{GDBN}, and thus free the programmer | |
759 | from the need to write several versions of the same code, one each for | |
760 | every UI, to produce output. | |
761 | ||
762 | @subsection Overview and Terminology | |
763 | ||
764 | In general, execution of each @value{GDBN} command produces some sort | |
765 | of output, and can even generate an input request. | |
766 | ||
767 | Output can be generated for the following purposes: | |
768 | ||
769 | @itemize @bullet | |
770 | @item | |
771 | to display a @emph{result} of an operation; | |
772 | ||
773 | @item | |
774 | to convey @emph{info} or produce side-effects of a requested | |
775 | operation; | |
776 | ||
777 | @item | |
778 | to provide a @emph{notification} of an asynchronous event (including | |
779 | progress indication of a prolonged asynchronous operation); | |
780 | ||
781 | @item | |
782 | to display @emph{error messages} (including warnings); | |
783 | ||
784 | @item | |
785 | to show @emph{debug data}; | |
786 | ||
787 | @item | |
788 | to @emph{query} or prompt a user for input (a special case). | |
789 | @end itemize | |
790 | ||
791 | @noindent | |
792 | This section mainly concentrates on how to build result output, | |
793 | although some of it also applies to other kinds of output. | |
794 | ||
795 | Generation of output that displays the results of an operation | |
796 | involves one or more of the following: | |
797 | ||
798 | @itemize @bullet | |
799 | @item | |
800 | output of the actual data | |
801 | ||
802 | @item | |
803 | formatting the output as appropriate for console output, to make it | |
804 | easily readable by humans | |
805 | ||
806 | @item | |
807 | machine oriented formatting--a more terse formatting to allow for easy | |
808 | parsing by programs which read @value{GDBN}'s output | |
809 | ||
810 | @item | |
c72e7388 AC |
811 | annotation, whose purpose is to help legacy GUIs to identify interesting |
812 | parts in the output | |
0ee54786 EZ |
813 | @end itemize |
814 | ||
815 | The @code{ui_out} routines take care of the first three aspects. | |
c72e7388 AC |
816 | Annotations are provided by separate annotation routines. Note that use |
817 | of annotations for an interface between a GUI and @value{GDBN} is | |
0ee54786 EZ |
818 | deprecated. |
819 | ||
c72e7388 AC |
820 | Output can be in the form of a single item, which we call a @dfn{field}; |
821 | a @dfn{list} consisting of identical fields; a @dfn{tuple} consisting of | |
822 | non-identical fields; or a @dfn{table}, which is a tuple consisting of a | |
823 | header and a body. In a BNF-like form: | |
0ee54786 | 824 | |
c72e7388 AC |
825 | @table @code |
826 | @item <table> @expansion{} | |
827 | @code{<header> <body>} | |
828 | @item <header> @expansion{} | |
829 | @code{@{ <column> @}} | |
830 | @item <column> @expansion{} | |
831 | @code{<width> <alignment> <title>} | |
832 | @item <body> @expansion{} | |
833 | @code{@{<row>@}} | |
834 | @end table | |
0ee54786 EZ |
835 | |
836 | ||
837 | @subsection General Conventions | |
838 | ||
c72e7388 AC |
839 | Most @code{ui_out} routines are of type @code{void}, the exceptions are |
840 | @code{ui_out_stream_new} (which returns a pointer to the newly created | |
841 | object) and the @code{make_cleanup} routines. | |
0ee54786 | 842 | |
c72e7388 AC |
843 | The first parameter is always the @code{ui_out} vector object, a pointer |
844 | to a @code{struct ui_out}. | |
0ee54786 | 845 | |
c72e7388 AC |
846 | The @var{format} parameter is like in @code{printf} family of functions. |
847 | When it is present, there must also be a variable list of arguments | |
848 | sufficient used to satisfy the @code{%} specifiers in the supplied | |
0ee54786 EZ |
849 | format. |
850 | ||
c72e7388 AC |
851 | When a character string argument is not used in a @code{ui_out} function |
852 | call, a @code{NULL} pointer has to be supplied instead. | |
0ee54786 EZ |
853 | |
854 | ||
c72e7388 | 855 | @subsection Table, Tuple and List Functions |
0ee54786 EZ |
856 | |
857 | @cindex list output functions | |
858 | @cindex table output functions | |
c72e7388 AC |
859 | @cindex tuple output functions |
860 | This section introduces @code{ui_out} routines for building lists, | |
861 | tuples and tables. The routines to output the actual data items | |
862 | (fields) are presented in the next section. | |
0ee54786 | 863 | |
c72e7388 AC |
864 | To recap: A @dfn{tuple} is a sequence of @dfn{fields}, each field |
865 | containing information about an object; a @dfn{list} is a sequence of | |
866 | fields where each field describes an identical object. | |
0ee54786 | 867 | |
c72e7388 AC |
868 | Use the @dfn{table} functions when your output consists of a list of |
869 | rows (tuples) and the console output should include a heading. Use this | |
870 | even when you are listing just one object but you still want the header. | |
0ee54786 EZ |
871 | |
872 | @cindex nesting level in @code{ui_out} functions | |
c72e7388 AC |
873 | Tables can not be nested. Tuples and lists can be nested up to a |
874 | maximum of five levels. | |
0ee54786 EZ |
875 | |
876 | The overall structure of the table output code is something like this: | |
877 | ||
878 | @example | |
879 | ui_out_table_begin | |
880 | ui_out_table_header | |
c72e7388 | 881 | @dots{} |
0ee54786 | 882 | ui_out_table_body |
c72e7388 | 883 | ui_out_tuple_begin |
0ee54786 | 884 | ui_out_field_* |
c72e7388 AC |
885 | @dots{} |
886 | ui_out_tuple_end | |
887 | @dots{} | |
0ee54786 EZ |
888 | ui_out_table_end |
889 | @end example | |
890 | ||
c72e7388 | 891 | Here is the description of table-, tuple- and list-related @code{ui_out} |
0ee54786 EZ |
892 | functions: |
893 | ||
c72e7388 AC |
894 | @deftypefun void ui_out_table_begin (struct ui_out *@var{uiout}, int @var{nbrofcols}, int @var{nr_rows}, const char *@var{tblid}) |
895 | The function @code{ui_out_table_begin} marks the beginning of the output | |
896 | of a table. It should always be called before any other @code{ui_out} | |
897 | function for a given table. @var{nbrofcols} is the number of columns in | |
898 | the table. @var{nr_rows} is the number of rows in the table. | |
899 | @var{tblid} is an optional string identifying the table. The string | |
900 | pointed to by @var{tblid} is copied by the implementation of | |
901 | @code{ui_out_table_begin}, so the application can free the string if it | |
902 | was @code{malloc}ed. | |
0ee54786 EZ |
903 | |
904 | The companion function @code{ui_out_table_end}, described below, marks | |
905 | the end of the table's output. | |
906 | @end deftypefun | |
907 | ||
c72e7388 AC |
908 | @deftypefun void ui_out_table_header (struct ui_out *@var{uiout}, int @var{width}, enum ui_align @var{alignment}, const char *@var{colhdr}) |
909 | @code{ui_out_table_header} provides the header information for a single | |
910 | table column. You call this function several times, one each for every | |
911 | column of the table, after @code{ui_out_table_begin}, but before | |
912 | @code{ui_out_table_body}. | |
0ee54786 EZ |
913 | |
914 | The value of @var{width} gives the column width in characters. The | |
915 | value of @var{alignment} is one of @code{left}, @code{center}, and | |
916 | @code{right}, and it specifies how to align the header: left-justify, | |
917 | center, or right-justify it. @var{colhdr} points to a string that | |
918 | specifies the column header; the implementation copies that string, so | |
c72e7388 AC |
919 | column header strings in @code{malloc}ed storage can be freed after the |
920 | call. | |
0ee54786 EZ |
921 | @end deftypefun |
922 | ||
923 | @deftypefun void ui_out_table_body (struct ui_out *@var{uiout}) | |
c72e7388 | 924 | This function delimits the table header from the table body. |
0ee54786 EZ |
925 | @end deftypefun |
926 | ||
927 | @deftypefun void ui_out_table_end (struct ui_out *@var{uiout}) | |
c72e7388 AC |
928 | This function signals the end of a table's output. It should be called |
929 | after the table body has been produced by the list and field output | |
930 | functions. | |
0ee54786 EZ |
931 | |
932 | There should be exactly one call to @code{ui_out_table_end} for each | |
c72e7388 AC |
933 | call to @code{ui_out_table_begin}, otherwise the @code{ui_out} functions |
934 | will signal an internal error. | |
0ee54786 EZ |
935 | @end deftypefun |
936 | ||
c72e7388 | 937 | The output of the tuples that represent the table rows must follow the |
0ee54786 | 938 | call to @code{ui_out_table_body} and precede the call to |
c72e7388 AC |
939 | @code{ui_out_table_end}. You build a tuple by calling |
940 | @code{ui_out_tuple_begin} and @code{ui_out_tuple_end}, with suitable | |
0ee54786 EZ |
941 | calls to functions which actually output fields between them. |
942 | ||
c72e7388 AC |
943 | @deftypefun void ui_out_tuple_begin (struct ui_out *@var{uiout}, const char *@var{id}) |
944 | This function marks the beginning of a tuple output. @var{id} points | |
945 | to an optional string that identifies the tuple; it is copied by the | |
946 | implementation, and so strings in @code{malloc}ed storage can be freed | |
947 | after the call. | |
948 | @end deftypefun | |
949 | ||
950 | @deftypefun void ui_out_tuple_end (struct ui_out *@var{uiout}) | |
951 | This function signals an end of a tuple output. There should be exactly | |
952 | one call to @code{ui_out_tuple_end} for each call to | |
953 | @code{ui_out_tuple_begin}, otherwise an internal @value{GDBN} error will | |
954 | be signaled. | |
955 | @end deftypefun | |
956 | ||
957 | @deftypefun struct cleanup *make_cleanup_ui_out_tuple_begin_end (struct ui_out *@var{uiout}, const char *@var{id}) | |
958 | This function first opens the tuple and then establishes a cleanup | |
959 | (@pxref{Coding, Cleanups}) to close the tuple. It provides a convenient | |
960 | and correct implementation of the non-portable@footnote{The function | |
961 | cast is not portable ISO-C.} code sequence: | |
962 | @smallexample | |
963 | struct cleanup *old_cleanup; | |
964 | ui_out_tuple_begin (uiout, "..."); | |
965 | old_cleanup = make_cleanup ((void(*)(void *)) ui_out_tuple_end, | |
966 | uiout); | |
967 | @end smallexample | |
968 | @end deftypefun | |
969 | ||
970 | @deftypefun void ui_out_list_begin (struct ui_out *@var{uiout}, const char *@var{id}) | |
971 | This function marks the beginning of a list output. @var{id} points to | |
972 | an optional string that identifies the list; it is copied by the | |
973 | implementation, and so strings in @code{malloc}ed storage can be freed | |
974 | after the call. | |
0ee54786 EZ |
975 | @end deftypefun |
976 | ||
977 | @deftypefun void ui_out_list_end (struct ui_out *@var{uiout}) | |
c72e7388 AC |
978 | This function signals an end of a list output. There should be exactly |
979 | one call to @code{ui_out_list_end} for each call to | |
980 | @code{ui_out_list_begin}, otherwise an internal @value{GDBN} error will | |
981 | be signaled. | |
982 | @end deftypefun | |
983 | ||
984 | @deftypefun struct cleanup *make_cleanup_ui_out_list_begin_end (struct ui_out *@var{uiout}, const char *@var{id}) | |
985 | Similar to @code{make_cleanup_ui_out_tuple_begin_end}, this function | |
986 | opens a list and then establishes cleanup (@pxref{Coding, Cleanups}) | |
987 | that will close the list.list. | |
0ee54786 EZ |
988 | @end deftypefun |
989 | ||
990 | @subsection Item Output Functions | |
991 | ||
992 | @cindex item output functions | |
993 | @cindex field output functions | |
994 | @cindex data output | |
995 | The functions described below produce output for the actual data | |
996 | items, or fields, which contain information about the object. | |
997 | ||
998 | Choose the appropriate function accordingly to your particular needs. | |
999 | ||
1000 | @deftypefun void ui_out_field_fmt (struct ui_out *@var{uiout}, char *@var{fldname}, char *@var{format}, ...) | |
1001 | This is the most general output function. It produces the | |
1002 | representation of the data in the variable-length argument list | |
1003 | according to formatting specifications in @var{format}, a | |
1004 | @code{printf}-like format string. The optional argument @var{fldname} | |
1005 | supplies the name of the field. The data items themselves are | |
1006 | supplied as additional arguments after @var{format}. | |
1007 | ||
1008 | This generic function should be used only when it is not possible to | |
1009 | use one of the specialized versions (see below). | |
1010 | @end deftypefun | |
1011 | ||
c72e7388 | 1012 | @deftypefun void ui_out_field_int (struct ui_out *@var{uiout}, const char *@var{fldname}, int @var{value}) |
0ee54786 EZ |
1013 | This function outputs a value of an @code{int} variable. It uses the |
1014 | @code{"%d"} output conversion specification. @var{fldname} specifies | |
1015 | the name of the field. | |
1016 | @end deftypefun | |
1017 | ||
c72e7388 | 1018 | @deftypefun void ui_out_field_core_addr (struct ui_out *@var{uiout}, const char *@var{fldname}, CORE_ADDR @var{address}) |
0ee54786 EZ |
1019 | This function outputs an address. |
1020 | @end deftypefun | |
1021 | ||
c72e7388 | 1022 | @deftypefun void ui_out_field_string (struct ui_out *@var{uiout}, const char *@var{fldname}, const char *@var{string}) |
0ee54786 EZ |
1023 | This function outputs a string using the @code{"%s"} conversion |
1024 | specification. | |
1025 | @end deftypefun | |
1026 | ||
1027 | Sometimes, there's a need to compose your output piece by piece using | |
1028 | functions that operate on a stream, such as @code{value_print} or | |
1029 | @code{fprintf_symbol_filtered}. These functions accept an argument of | |
1030 | the type @code{struct ui_file *}, a pointer to a @code{ui_file} object | |
1031 | used to store the data stream used for the output. When you use one | |
1032 | of these functions, you need a way to pass their results stored in a | |
1033 | @code{ui_file} object to the @code{ui_out} functions. To this end, | |
1034 | you first create a @code{ui_stream} object by calling | |
1035 | @code{ui_out_stream_new}, pass the @code{stream} member of that | |
1036 | @code{ui_stream} object to @code{value_print} and similar functions, | |
1037 | and finally call @code{ui_out_field_stream} to output the field you | |
1038 | constructed. When the @code{ui_stream} object is no longer needed, | |
1039 | you should destroy it and free its memory by calling | |
1040 | @code{ui_out_stream_delete}. | |
1041 | ||
1042 | @deftypefun struct ui_stream *ui_out_stream_new (struct ui_out *@var{uiout}) | |
1043 | This function creates a new @code{ui_stream} object which uses the | |
1044 | same output methods as the @code{ui_out} object whose pointer is | |
1045 | passed in @var{uiout}. It returns a pointer to the newly created | |
1046 | @code{ui_stream} object. | |
1047 | @end deftypefun | |
1048 | ||
1049 | @deftypefun void ui_out_stream_delete (struct ui_stream *@var{streambuf}) | |
1050 | This functions destroys a @code{ui_stream} object specified by | |
1051 | @var{streambuf}. | |
1052 | @end deftypefun | |
1053 | ||
c72e7388 | 1054 | @deftypefun void ui_out_field_stream (struct ui_out *@var{uiout}, const char *@var{fieldname}, struct ui_stream *@var{streambuf}) |
0ee54786 EZ |
1055 | This function consumes all the data accumulated in |
1056 | @code{streambuf->stream} and outputs it like | |
1057 | @code{ui_out_field_string} does. After a call to | |
1058 | @code{ui_out_field_stream}, the accumulated data no longer exists, but | |
1059 | the stream is still valid and may be used for producing more fields. | |
1060 | @end deftypefun | |
1061 | ||
1062 | @strong{Important:} If there is any chance that your code could bail | |
1063 | out before completing output generation and reaching the point where | |
1064 | @code{ui_out_stream_delete} is called, it is necessary to set up a | |
1065 | cleanup, to avoid leaking memory and other resources. Here's a | |
1066 | skeleton code to do that: | |
1067 | ||
1068 | @smallexample | |
1069 | struct ui_stream *mybuf = ui_out_stream_new (uiout); | |
1070 | struct cleanup *old = make_cleanup (ui_out_stream_delete, mybuf); | |
1071 | ... | |
1072 | do_cleanups (old); | |
1073 | @end smallexample | |
1074 | ||
1075 | If the function already has the old cleanup chain set (for other kinds | |
1076 | of cleanups), you just have to add your cleanup to it: | |
1077 | ||
1078 | @smallexample | |
1079 | mybuf = ui_out_stream_new (uiout); | |
1080 | make_cleanup (ui_out_stream_delete, mybuf); | |
1081 | @end smallexample | |
1082 | ||
1083 | Note that with cleanups in place, you should not call | |
1084 | @code{ui_out_stream_delete} directly, or you would attempt to free the | |
1085 | same buffer twice. | |
1086 | ||
1087 | @subsection Utility Output Functions | |
1088 | ||
c72e7388 | 1089 | @deftypefun void ui_out_field_skip (struct ui_out *@var{uiout}, const char *@var{fldname}) |
0ee54786 EZ |
1090 | This function skips a field in a table. Use it if you have to leave |
1091 | an empty field without disrupting the table alignment. The argument | |
1092 | @var{fldname} specifies a name for the (missing) filed. | |
1093 | @end deftypefun | |
1094 | ||
c72e7388 | 1095 | @deftypefun void ui_out_text (struct ui_out *@var{uiout}, const char *@var{string}) |
0ee54786 EZ |
1096 | This function outputs the text in @var{string} in a way that makes it |
1097 | easy to be read by humans. For example, the console implementation of | |
1098 | this method filters the text through a built-in pager, to prevent it | |
1099 | from scrolling off the visible portion of the screen. | |
1100 | ||
1101 | Use this function for printing relatively long chunks of text around | |
1102 | the actual field data: the text it produces is not aligned according | |
1103 | to the table's format. Use @code{ui_out_field_string} to output a | |
1104 | string field, and use @code{ui_out_message}, described below, to | |
1105 | output short messages. | |
1106 | @end deftypefun | |
1107 | ||
1108 | @deftypefun void ui_out_spaces (struct ui_out *@var{uiout}, int @var{nspaces}) | |
1109 | This function outputs @var{nspaces} spaces. It is handy to align the | |
1110 | text produced by @code{ui_out_text} with the rest of the table or | |
1111 | list. | |
1112 | @end deftypefun | |
1113 | ||
c72e7388 | 1114 | @deftypefun void ui_out_message (struct ui_out *@var{uiout}, int @var{verbosity}, const char *@var{format}, ...) |
0ee54786 EZ |
1115 | This function produces a formatted message, provided that the current |
1116 | verbosity level is at least as large as given by @var{verbosity}. The | |
1117 | current verbosity level is specified by the user with the @samp{set | |
1118 | verbositylevel} command.@footnote{As of this writing (April 2001), | |
1119 | setting verbosity level is not yet implemented, and is always returned | |
1120 | as zero. So calling @code{ui_out_message} with a @var{verbosity} | |
1121 | argument more than zero will cause the message to never be printed.} | |
1122 | @end deftypefun | |
1123 | ||
1124 | @deftypefun void ui_out_wrap_hint (struct ui_out *@var{uiout}, char *@var{indent}) | |
1125 | This function gives the console output filter (a paging filter) a hint | |
1126 | of where to break lines which are too long. Ignored for all other | |
1127 | output consumers. @var{indent}, if non-@code{NULL}, is the string to | |
1128 | be printed to indent the wrapped text on the next line; it must remain | |
1129 | accessible until the next call to @code{ui_out_wrap_hint}, or until an | |
1130 | explicit newline is produced by one of the other functions. If | |
1131 | @var{indent} is @code{NULL}, the wrapped text will not be indented. | |
1132 | @end deftypefun | |
1133 | ||
1134 | @deftypefun void ui_out_flush (struct ui_out *@var{uiout}) | |
1135 | This function flushes whatever output has been accumulated so far, if | |
1136 | the UI buffers output. | |
1137 | @end deftypefun | |
1138 | ||
1139 | ||
1140 | @subsection Examples of Use of @code{ui_out} functions | |
1141 | ||
1142 | @cindex using @code{ui_out} functions | |
1143 | @cindex @code{ui_out} functions, usage examples | |
1144 | This section gives some practical examples of using the @code{ui_out} | |
1145 | functions to generalize the old console-oriented code in | |
1146 | @value{GDBN}. The examples all come from functions defined on the | |
1147 | @file{breakpoints.c} file. | |
1148 | ||
1149 | This example, from the @code{breakpoint_1} function, shows how to | |
1150 | produce a table. | |
1151 | ||
1152 | The original code was: | |
1153 | ||
1154 | @example | |
1155 | if (!found_a_breakpoint++) | |
1156 | @{ | |
1157 | annotate_breakpoints_headers (); | |
1158 | ||
1159 | annotate_field (0); | |
1160 | printf_filtered ("Num "); | |
1161 | annotate_field (1); | |
1162 | printf_filtered ("Type "); | |
1163 | annotate_field (2); | |
1164 | printf_filtered ("Disp "); | |
1165 | annotate_field (3); | |
1166 | printf_filtered ("Enb "); | |
1167 | if (addressprint) | |
1168 | @{ | |
1169 | annotate_field (4); | |
1170 | printf_filtered ("Address "); | |
1171 | @} | |
1172 | annotate_field (5); | |
1173 | printf_filtered ("What\n"); | |
1174 | ||
1175 | annotate_breakpoints_table (); | |
1176 | @} | |
1177 | @end example | |
1178 | ||
1179 | Here's the new version: | |
1180 | ||
1181 | @example | |
c72e7388 AC |
1182 | nr_printable_breakpoints = @dots{}; |
1183 | ||
1184 | if (addressprint) | |
1185 | ui_out_table_begin (ui, 6, nr_printable_breakpoints, "BreakpointTable"); | |
1186 | else | |
1187 | ui_out_table_begin (ui, 5, nr_printable_breakpoints, "BreakpointTable"); | |
1188 | ||
1189 | if (nr_printable_breakpoints > 0) | |
1190 | annotate_breakpoints_headers (); | |
1191 | if (nr_printable_breakpoints > 0) | |
1192 | annotate_field (0); | |
1193 | ui_out_table_header (uiout, 3, ui_left, "number", "Num"); /* 1 */ | |
1194 | if (nr_printable_breakpoints > 0) | |
1195 | annotate_field (1); | |
1196 | ui_out_table_header (uiout, 14, ui_left, "type", "Type"); /* 2 */ | |
1197 | if (nr_printable_breakpoints > 0) | |
1198 | annotate_field (2); | |
1199 | ui_out_table_header (uiout, 4, ui_left, "disp", "Disp"); /* 3 */ | |
1200 | if (nr_printable_breakpoints > 0) | |
1201 | annotate_field (3); | |
1202 | ui_out_table_header (uiout, 3, ui_left, "enabled", "Enb"); /* 4 */ | |
1203 | if (addressprint) | |
1204 | @{ | |
1205 | if (nr_printable_breakpoints > 0) | |
1206 | annotate_field (4); | |
1207 | if (TARGET_ADDR_BIT <= 32) | |
1208 | ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */ | |
0ee54786 | 1209 | else |
c72e7388 AC |
1210 | ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */ |
1211 | @} | |
1212 | if (nr_printable_breakpoints > 0) | |
1213 | annotate_field (5); | |
1214 | ui_out_table_header (uiout, 40, ui_noalign, "what", "What"); /* 6 */ | |
1215 | ui_out_table_body (uiout); | |
1216 | if (nr_printable_breakpoints > 0) | |
1217 | annotate_breakpoints_table (); | |
0ee54786 EZ |
1218 | @end example |
1219 | ||
1220 | This example, from the @code{print_one_breakpoint} function, shows how | |
1221 | to produce the actual data for the table whose structure was defined | |
1222 | in the above example. The original code was: | |
1223 | ||
1224 | @example | |
1225 | annotate_record (); | |
1226 | annotate_field (0); | |
1227 | printf_filtered ("%-3d ", b->number); | |
1228 | annotate_field (1); | |
1229 | if ((int)b->type > (sizeof(bptypes)/sizeof(bptypes[0])) | |
1230 | || ((int) b->type != bptypes[(int) b->type].type)) | |
1231 | internal_error ("bptypes table does not describe type #%d.", | |
1232 | (int)b->type); | |
1233 | printf_filtered ("%-14s ", bptypes[(int)b->type].description); | |
1234 | annotate_field (2); | |
1235 | printf_filtered ("%-4s ", bpdisps[(int)b->disposition]); | |
1236 | annotate_field (3); | |
1237 | printf_filtered ("%-3c ", bpenables[(int)b->enable]); | |
c72e7388 | 1238 | @dots{} |
0ee54786 EZ |
1239 | @end example |
1240 | ||
1241 | This is the new version: | |
1242 | ||
1243 | @example | |
1244 | annotate_record (); | |
c72e7388 | 1245 | ui_out_tuple_begin (uiout, "bkpt"); |
0ee54786 EZ |
1246 | annotate_field (0); |
1247 | ui_out_field_int (uiout, "number", b->number); | |
1248 | annotate_field (1); | |
1249 | if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0]))) | |
1250 | || ((int) b->type != bptypes[(int) b->type].type)) | |
1251 | internal_error ("bptypes table does not describe type #%d.", | |
1252 | (int) b->type); | |
1253 | ui_out_field_string (uiout, "type", bptypes[(int)b->type].description); | |
1254 | annotate_field (2); | |
1255 | ui_out_field_string (uiout, "disp", bpdisps[(int)b->disposition]); | |
1256 | annotate_field (3); | |
1257 | ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)b->enable]); | |
c72e7388 | 1258 | @dots{} |
0ee54786 EZ |
1259 | @end example |
1260 | ||
1261 | This example, also from @code{print_one_breakpoint}, shows how to | |
1262 | produce a complicated output field using the @code{print_expression} | |
1263 | functions which requires a stream to be passed. It also shows how to | |
1264 | automate stream destruction with cleanups. The original code was: | |
1265 | ||
1266 | @example | |
1267 | annotate_field (5); | |
1268 | print_expression (b->exp, gdb_stdout); | |
1269 | @end example | |
1270 | ||
1271 | The new version is: | |
1272 | ||
1273 | @example | |
1274 | struct ui_stream *stb = ui_out_stream_new (uiout); | |
1275 | struct cleanup *old_chain = make_cleanup_ui_out_stream_delete (stb); | |
1276 | ... | |
1277 | annotate_field (5); | |
1278 | print_expression (b->exp, stb->stream); | |
1279 | ui_out_field_stream (uiout, "what", local_stream); | |
1280 | @end example | |
1281 | ||
1282 | This example, also from @code{print_one_breakpoint}, shows how to use | |
1283 | @code{ui_out_text} and @code{ui_out_field_string}. The original code | |
1284 | was: | |
1285 | ||
1286 | @example | |
1287 | annotate_field (5); | |
1288 | if (b->dll_pathname == NULL) | |
1289 | printf_filtered ("<any library> "); | |
1290 | else | |
1291 | printf_filtered ("library \"%s\" ", b->dll_pathname); | |
1292 | @end example | |
1293 | ||
1294 | It became: | |
1295 | ||
1296 | @example | |
1297 | annotate_field (5); | |
1298 | if (b->dll_pathname == NULL) | |
1299 | @{ | |
1300 | ui_out_field_string (uiout, "what", "<any library>"); | |
1301 | ui_out_spaces (uiout, 1); | |
1302 | @} | |
1303 | else | |
1304 | @{ | |
1305 | ui_out_text (uiout, "library \""); | |
1306 | ui_out_field_string (uiout, "what", b->dll_pathname); | |
1307 | ui_out_text (uiout, "\" "); | |
1308 | @} | |
1309 | @end example | |
1310 | ||
1311 | The following example from @code{print_one_breakpoint} shows how to | |
1312 | use @code{ui_out_field_int} and @code{ui_out_spaces}. The original | |
1313 | code was: | |
1314 | ||
1315 | @example | |
1316 | annotate_field (5); | |
1317 | if (b->forked_inferior_pid != 0) | |
1318 | printf_filtered ("process %d ", b->forked_inferior_pid); | |
1319 | @end example | |
1320 | ||
1321 | It became: | |
1322 | ||
1323 | @example | |
1324 | annotate_field (5); | |
1325 | if (b->forked_inferior_pid != 0) | |
1326 | @{ | |
1327 | ui_out_text (uiout, "process "); | |
1328 | ui_out_field_int (uiout, "what", b->forked_inferior_pid); | |
1329 | ui_out_spaces (uiout, 1); | |
1330 | @} | |
1331 | @end example | |
1332 | ||
1333 | Here's an example of using @code{ui_out_field_string}. The original | |
1334 | code was: | |
1335 | ||
1336 | @example | |
1337 | annotate_field (5); | |
1338 | if (b->exec_pathname != NULL) | |
1339 | printf_filtered ("program \"%s\" ", b->exec_pathname); | |
1340 | @end example | |
1341 | ||
1342 | It became: | |
1343 | ||
1344 | @example | |
1345 | annotate_field (5); | |
1346 | if (b->exec_pathname != NULL) | |
1347 | @{ | |
1348 | ui_out_text (uiout, "program \""); | |
1349 | ui_out_field_string (uiout, "what", b->exec_pathname); | |
1350 | ui_out_text (uiout, "\" "); | |
1351 | @} | |
1352 | @end example | |
1353 | ||
1354 | Finally, here's an example of printing an address. The original code: | |
1355 | ||
1356 | @example | |
1357 | annotate_field (4); | |
1358 | printf_filtered ("%s ", | |
1359 | local_hex_string_custom ((unsigned long) b->address, "08l")); | |
1360 | @end example | |
1361 | ||
1362 | It became: | |
1363 | ||
1364 | @example | |
1365 | annotate_field (4); | |
1366 | ui_out_field_core_addr (uiout, "Address", b->address); | |
1367 | @end example | |
1368 | ||
1369 | ||
c906108c SS |
1370 | @section Console Printing |
1371 | ||
1372 | @section TUI | |
1373 | ||
1374 | @section libgdb | |
1375 | ||
56caf160 | 1376 | @cindex @code{libgdb} |
c906108c | 1377 | @code{libgdb} was an abortive project of years ago. The theory was to |
25822942 | 1378 | provide an API to @value{GDBN}'s functionality. |
c906108c SS |
1379 | |
1380 | @node Symbol Handling | |
1381 | ||
1382 | @chapter Symbol Handling | |
1383 | ||
25822942 | 1384 | Symbols are a key part of @value{GDBN}'s operation. Symbols include variables, |
c906108c SS |
1385 | functions, and types. |
1386 | ||
1387 | @section Symbol Reading | |
1388 | ||
56caf160 EZ |
1389 | @cindex symbol reading |
1390 | @cindex reading of symbols | |
1391 | @cindex symbol files | |
1392 | @value{GDBN} reads symbols from @dfn{symbol files}. The usual symbol | |
1393 | file is the file containing the program which @value{GDBN} is | |
1394 | debugging. @value{GDBN} can be directed to use a different file for | |
1395 | symbols (with the @samp{symbol-file} command), and it can also read | |
1396 | more symbols via the @samp{add-file} and @samp{load} commands, or while | |
1397 | reading symbols from shared libraries. | |
1398 | ||
1399 | @findex find_sym_fns | |
1400 | Symbol files are initially opened by code in @file{symfile.c} using | |
1401 | the BFD library (@pxref{Support Libraries}). BFD identifies the type | |
1402 | of the file by examining its header. @code{find_sym_fns} then uses | |
1403 | this identification to locate a set of symbol-reading functions. | |
1404 | ||
1405 | @findex add_symtab_fns | |
1406 | @cindex @code{sym_fns} structure | |
1407 | @cindex adding a symbol-reading module | |
1408 | Symbol-reading modules identify themselves to @value{GDBN} by calling | |
c906108c SS |
1409 | @code{add_symtab_fns} during their module initialization. The argument |
1410 | to @code{add_symtab_fns} is a @code{struct sym_fns} which contains the | |
1411 | name (or name prefix) of the symbol format, the length of the prefix, | |
1412 | and pointers to four functions. These functions are called at various | |
56caf160 | 1413 | times to process symbol files whose identification matches the specified |
c906108c SS |
1414 | prefix. |
1415 | ||
1416 | The functions supplied by each module are: | |
1417 | ||
1418 | @table @code | |
1419 | @item @var{xyz}_symfile_init(struct sym_fns *sf) | |
1420 | ||
56caf160 | 1421 | @cindex secondary symbol file |
c906108c SS |
1422 | Called from @code{symbol_file_add} when we are about to read a new |
1423 | symbol file. This function should clean up any internal state (possibly | |
1424 | resulting from half-read previous files, for example) and prepare to | |
56caf160 EZ |
1425 | read a new symbol file. Note that the symbol file which we are reading |
1426 | might be a new ``main'' symbol file, or might be a secondary symbol file | |
c906108c SS |
1427 | whose symbols are being added to the existing symbol table. |
1428 | ||
1429 | The argument to @code{@var{xyz}_symfile_init} is a newly allocated | |
1430 | @code{struct sym_fns} whose @code{bfd} field contains the BFD for the | |
1431 | new symbol file being read. Its @code{private} field has been zeroed, | |
1432 | and can be modified as desired. Typically, a struct of private | |
1433 | information will be @code{malloc}'d, and a pointer to it will be placed | |
1434 | in the @code{private} field. | |
1435 | ||
1436 | There is no result from @code{@var{xyz}_symfile_init}, but it can call | |
1437 | @code{error} if it detects an unavoidable problem. | |
1438 | ||
1439 | @item @var{xyz}_new_init() | |
1440 | ||
1441 | Called from @code{symbol_file_add} when discarding existing symbols. | |
56caf160 EZ |
1442 | This function needs only handle the symbol-reading module's internal |
1443 | state; the symbol table data structures visible to the rest of | |
1444 | @value{GDBN} will be discarded by @code{symbol_file_add}. It has no | |
1445 | arguments and no result. It may be called after | |
1446 | @code{@var{xyz}_symfile_init}, if a new symbol table is being read, or | |
1447 | may be called alone if all symbols are simply being discarded. | |
c906108c SS |
1448 | |
1449 | @item @var{xyz}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline) | |
1450 | ||
1451 | Called from @code{symbol_file_add} to actually read the symbols from a | |
1452 | symbol-file into a set of psymtabs or symtabs. | |
1453 | ||
56caf160 | 1454 | @code{sf} points to the @code{struct sym_fns} originally passed to |
c906108c SS |
1455 | @code{@var{xyz}_sym_init} for possible initialization. @code{addr} is |
1456 | the offset between the file's specified start address and its true | |
1457 | address in memory. @code{mainline} is 1 if this is the main symbol | |
1458 | table being read, and 0 if a secondary symbol file (e.g. shared library | |
1459 | or dynamically loaded file) is being read.@refill | |
1460 | @end table | |
1461 | ||
1462 | In addition, if a symbol-reading module creates psymtabs when | |
1463 | @var{xyz}_symfile_read is called, these psymtabs will contain a pointer | |
1464 | to a function @code{@var{xyz}_psymtab_to_symtab}, which can be called | |
25822942 | 1465 | from any point in the @value{GDBN} symbol-handling code. |
c906108c SS |
1466 | |
1467 | @table @code | |
1468 | @item @var{xyz}_psymtab_to_symtab (struct partial_symtab *pst) | |
1469 | ||
56caf160 | 1470 | Called from @code{psymtab_to_symtab} (or the @code{PSYMTAB_TO_SYMTAB} macro) if |
c906108c SS |
1471 | the psymtab has not already been read in and had its @code{pst->symtab} |
1472 | pointer set. The argument is the psymtab to be fleshed-out into a | |
56caf160 EZ |
1473 | symtab. Upon return, @code{pst->readin} should have been set to 1, and |
1474 | @code{pst->symtab} should contain a pointer to the new corresponding symtab, or | |
c906108c SS |
1475 | zero if there were no symbols in that part of the symbol file. |
1476 | @end table | |
1477 | ||
1478 | @section Partial Symbol Tables | |
1479 | ||
56caf160 | 1480 | @value{GDBN} has three types of symbol tables: |
c906108c SS |
1481 | |
1482 | @itemize @bullet | |
56caf160 EZ |
1483 | @cindex full symbol table |
1484 | @cindex symtabs | |
1485 | @item | |
1486 | Full symbol tables (@dfn{symtabs}). These contain the main | |
1487 | information about symbols and addresses. | |
c906108c | 1488 | |
56caf160 EZ |
1489 | @cindex psymtabs |
1490 | @item | |
1491 | Partial symbol tables (@dfn{psymtabs}). These contain enough | |
c906108c SS |
1492 | information to know when to read the corresponding part of the full |
1493 | symbol table. | |
1494 | ||
56caf160 EZ |
1495 | @cindex minimal symbol table |
1496 | @cindex minsymtabs | |
1497 | @item | |
1498 | Minimal symbol tables (@dfn{msymtabs}). These contain information | |
c906108c | 1499 | gleaned from non-debugging symbols. |
c906108c SS |
1500 | @end itemize |
1501 | ||
56caf160 | 1502 | @cindex partial symbol table |
c906108c SS |
1503 | This section describes partial symbol tables. |
1504 | ||
1505 | A psymtab is constructed by doing a very quick pass over an executable | |
1506 | file's debugging information. Small amounts of information are | |
56caf160 | 1507 | extracted---enough to identify which parts of the symbol table will |
c906108c | 1508 | need to be re-read and fully digested later, when the user needs the |
25822942 | 1509 | information. The speed of this pass causes @value{GDBN} to start up very |
c906108c SS |
1510 | quickly. Later, as the detailed rereading occurs, it occurs in small |
1511 | pieces, at various times, and the delay therefrom is mostly invisible to | |
1512 | the user. | |
1513 | @c (@xref{Symbol Reading}.) | |
1514 | ||
1515 | The symbols that show up in a file's psymtab should be, roughly, those | |
1516 | visible to the debugger's user when the program is not running code from | |
1517 | that file. These include external symbols and types, static symbols and | |
56caf160 | 1518 | types, and @code{enum} values declared at file scope. |
c906108c SS |
1519 | |
1520 | The psymtab also contains the range of instruction addresses that the | |
1521 | full symbol table would represent. | |
1522 | ||
56caf160 EZ |
1523 | @cindex finding a symbol |
1524 | @cindex symbol lookup | |
c906108c SS |
1525 | The idea is that there are only two ways for the user (or much of the |
1526 | code in the debugger) to reference a symbol: | |
1527 | ||
1528 | @itemize @bullet | |
56caf160 EZ |
1529 | @findex find_pc_function |
1530 | @findex find_pc_line | |
1531 | @item | |
1532 | By its address (e.g. execution stops at some address which is inside a | |
1533 | function in this file). The address will be noticed to be in the | |
1534 | range of this psymtab, and the full symtab will be read in. | |
1535 | @code{find_pc_function}, @code{find_pc_line}, and other | |
1536 | @code{find_pc_@dots{}} functions handle this. | |
c906108c | 1537 | |
56caf160 EZ |
1538 | @cindex lookup_symbol |
1539 | @item | |
1540 | By its name | |
c906108c SS |
1541 | (e.g. the user asks to print a variable, or set a breakpoint on a |
1542 | function). Global names and file-scope names will be found in the | |
1543 | psymtab, which will cause the symtab to be pulled in. Local names will | |
1544 | have to be qualified by a global name, or a file-scope name, in which | |
1545 | case we will have already read in the symtab as we evaluated the | |
56caf160 | 1546 | qualifier. Or, a local symbol can be referenced when we are ``in'' a |
c906108c SS |
1547 | local scope, in which case the first case applies. @code{lookup_symbol} |
1548 | does most of the work here. | |
c906108c SS |
1549 | @end itemize |
1550 | ||
1551 | The only reason that psymtabs exist is to cause a symtab to be read in | |
1552 | at the right moment. Any symbol that can be elided from a psymtab, | |
1553 | while still causing that to happen, should not appear in it. Since | |
1554 | psymtabs don't have the idea of scope, you can't put local symbols in | |
1555 | them anyway. Psymtabs don't have the idea of the type of a symbol, | |
1556 | either, so types need not appear, unless they will be referenced by | |
1557 | name. | |
1558 | ||
56caf160 EZ |
1559 | It is a bug for @value{GDBN} to behave one way when only a psymtab has |
1560 | been read, and another way if the corresponding symtab has been read | |
1561 | in. Such bugs are typically caused by a psymtab that does not contain | |
1562 | all the visible symbols, or which has the wrong instruction address | |
1563 | ranges. | |
c906108c | 1564 | |
56caf160 | 1565 | The psymtab for a particular section of a symbol file (objfile) could be |
c906108c SS |
1566 | thrown away after the symtab has been read in. The symtab should always |
1567 | be searched before the psymtab, so the psymtab will never be used (in a | |
1568 | bug-free environment). Currently, psymtabs are allocated on an obstack, | |
1569 | and all the psymbols themselves are allocated in a pair of large arrays | |
1570 | on an obstack, so there is little to be gained by trying to free them | |
1571 | unless you want to do a lot more work. | |
1572 | ||
1573 | @section Types | |
1574 | ||
56caf160 | 1575 | @unnumberedsubsec Fundamental Types (e.g., @code{FT_VOID}, @code{FT_BOOLEAN}). |
c906108c | 1576 | |
56caf160 | 1577 | @cindex fundamental types |
25822942 | 1578 | These are the fundamental types that @value{GDBN} uses internally. Fundamental |
c906108c SS |
1579 | types from the various debugging formats (stabs, ELF, etc) are mapped |
1580 | into one of these. They are basically a union of all fundamental types | |
56caf160 EZ |
1581 | that @value{GDBN} knows about for all the languages that @value{GDBN} |
1582 | knows about. | |
c906108c | 1583 | |
56caf160 | 1584 | @unnumberedsubsec Type Codes (e.g., @code{TYPE_CODE_PTR}, @code{TYPE_CODE_ARRAY}). |
c906108c | 1585 | |
56caf160 EZ |
1586 | @cindex type codes |
1587 | Each time @value{GDBN} builds an internal type, it marks it with one | |
1588 | of these types. The type may be a fundamental type, such as | |
1589 | @code{TYPE_CODE_INT}, or a derived type, such as @code{TYPE_CODE_PTR} | |
1590 | which is a pointer to another type. Typically, several @code{FT_*} | |
1591 | types map to one @code{TYPE_CODE_*} type, and are distinguished by | |
1592 | other members of the type struct, such as whether the type is signed | |
1593 | or unsigned, and how many bits it uses. | |
c906108c | 1594 | |
56caf160 | 1595 | @unnumberedsubsec Builtin Types (e.g., @code{builtin_type_void}, @code{builtin_type_char}). |
c906108c SS |
1596 | |
1597 | These are instances of type structs that roughly correspond to | |
56caf160 EZ |
1598 | fundamental types and are created as global types for @value{GDBN} to |
1599 | use for various ugly historical reasons. We eventually want to | |
1600 | eliminate these. Note for example that @code{builtin_type_int} | |
1601 | initialized in @file{gdbtypes.c} is basically the same as a | |
1602 | @code{TYPE_CODE_INT} type that is initialized in @file{c-lang.c} for | |
1603 | an @code{FT_INTEGER} fundamental type. The difference is that the | |
1604 | @code{builtin_type} is not associated with any particular objfile, and | |
1605 | only one instance exists, while @file{c-lang.c} builds as many | |
1606 | @code{TYPE_CODE_INT} types as needed, with each one associated with | |
1607 | some particular objfile. | |
c906108c SS |
1608 | |
1609 | @section Object File Formats | |
56caf160 | 1610 | @cindex object file formats |
c906108c SS |
1611 | |
1612 | @subsection a.out | |
1613 | ||
56caf160 EZ |
1614 | @cindex @code{a.out} format |
1615 | The @code{a.out} format is the original file format for Unix. It | |
1616 | consists of three sections: @code{text}, @code{data}, and @code{bss}, | |
1617 | which are for program code, initialized data, and uninitialized data, | |
1618 | respectively. | |
c906108c | 1619 | |
56caf160 | 1620 | The @code{a.out} format is so simple that it doesn't have any reserved |
c906108c | 1621 | place for debugging information. (Hey, the original Unix hackers used |
56caf160 EZ |
1622 | @samp{adb}, which is a machine-language debugger!) The only debugging |
1623 | format for @code{a.out} is stabs, which is encoded as a set of normal | |
c906108c SS |
1624 | symbols with distinctive attributes. |
1625 | ||
56caf160 | 1626 | The basic @code{a.out} reader is in @file{dbxread.c}. |
c906108c SS |
1627 | |
1628 | @subsection COFF | |
1629 | ||
56caf160 | 1630 | @cindex COFF format |
c906108c SS |
1631 | The COFF format was introduced with System V Release 3 (SVR3) Unix. |
1632 | COFF files may have multiple sections, each prefixed by a header. The | |
1633 | number of sections is limited. | |
1634 | ||
1635 | The COFF specification includes support for debugging. Although this | |
1636 | was a step forward, the debugging information was woefully limited. For | |
1637 | instance, it was not possible to represent code that came from an | |
1638 | included file. | |
1639 | ||
1640 | The COFF reader is in @file{coffread.c}. | |
1641 | ||
1642 | @subsection ECOFF | |
1643 | ||
56caf160 | 1644 | @cindex ECOFF format |
c906108c SS |
1645 | ECOFF is an extended COFF originally introduced for Mips and Alpha |
1646 | workstations. | |
1647 | ||
1648 | The basic ECOFF reader is in @file{mipsread.c}. | |
1649 | ||
1650 | @subsection XCOFF | |
1651 | ||
56caf160 | 1652 | @cindex XCOFF format |
c906108c SS |
1653 | The IBM RS/6000 running AIX uses an object file format called XCOFF. |
1654 | The COFF sections, symbols, and line numbers are used, but debugging | |
56caf160 EZ |
1655 | symbols are @code{dbx}-style stabs whose strings are located in the |
1656 | @code{.debug} section (rather than the string table). For more | |
1657 | information, see @ref{Top,,,stabs,The Stabs Debugging Format}. | |
c906108c SS |
1658 | |
1659 | The shared library scheme has a clean interface for figuring out what | |
1660 | shared libraries are in use, but the catch is that everything which | |
1661 | refers to addresses (symbol tables and breakpoints at least) needs to be | |
1662 | relocated for both shared libraries and the main executable. At least | |
1663 | using the standard mechanism this can only be done once the program has | |
1664 | been run (or the core file has been read). | |
1665 | ||
1666 | @subsection PE | |
1667 | ||
56caf160 EZ |
1668 | @cindex PE-COFF format |
1669 | Windows 95 and NT use the PE (@dfn{Portable Executable}) format for their | |
c906108c SS |
1670 | executables. PE is basically COFF with additional headers. |
1671 | ||
25822942 | 1672 | While BFD includes special PE support, @value{GDBN} needs only the basic |
c906108c SS |
1673 | COFF reader. |
1674 | ||
1675 | @subsection ELF | |
1676 | ||
56caf160 | 1677 | @cindex ELF format |
c906108c SS |
1678 | The ELF format came with System V Release 4 (SVR4) Unix. ELF is similar |
1679 | to COFF in being organized into a number of sections, but it removes | |
1680 | many of COFF's limitations. | |
1681 | ||
1682 | The basic ELF reader is in @file{elfread.c}. | |
1683 | ||
1684 | @subsection SOM | |
1685 | ||
56caf160 | 1686 | @cindex SOM format |
c906108c SS |
1687 | SOM is HP's object file and debug format (not to be confused with IBM's |
1688 | SOM, which is a cross-language ABI). | |
1689 | ||
1690 | The SOM reader is in @file{hpread.c}. | |
1691 | ||
1692 | @subsection Other File Formats | |
1693 | ||
56caf160 | 1694 | @cindex Netware Loadable Module format |
25822942 | 1695 | Other file formats that have been supported by @value{GDBN} include Netware |
4a98ee0e | 1696 | Loadable Modules (@file{nlmread.c}). |
c906108c SS |
1697 | |
1698 | @section Debugging File Formats | |
1699 | ||
1700 | This section describes characteristics of debugging information that | |
1701 | are independent of the object file format. | |
1702 | ||
1703 | @subsection stabs | |
1704 | ||
56caf160 | 1705 | @cindex stabs debugging info |
c906108c SS |
1706 | @code{stabs} started out as special symbols within the @code{a.out} |
1707 | format. Since then, it has been encapsulated into other file | |
1708 | formats, such as COFF and ELF. | |
1709 | ||
1710 | While @file{dbxread.c} does some of the basic stab processing, | |
1711 | including for encapsulated versions, @file{stabsread.c} does | |
1712 | the real work. | |
1713 | ||
1714 | @subsection COFF | |
1715 | ||
56caf160 | 1716 | @cindex COFF debugging info |
c906108c SS |
1717 | The basic COFF definition includes debugging information. The level |
1718 | of support is minimal and non-extensible, and is not often used. | |
1719 | ||
1720 | @subsection Mips debug (Third Eye) | |
1721 | ||
56caf160 | 1722 | @cindex ECOFF debugging info |
c906108c SS |
1723 | ECOFF includes a definition of a special debug format. |
1724 | ||
1725 | The file @file{mdebugread.c} implements reading for this format. | |
1726 | ||
1727 | @subsection DWARF 1 | |
1728 | ||
56caf160 | 1729 | @cindex DWARF 1 debugging info |
c906108c SS |
1730 | DWARF 1 is a debugging format that was originally designed to be |
1731 | used with ELF in SVR4 systems. | |
1732 | ||
1733 | @c CHILL_PRODUCER | |
1734 | @c GCC_PRODUCER | |
1735 | @c GPLUS_PRODUCER | |
1736 | @c LCC_PRODUCER | |
1737 | @c If defined, these are the producer strings in a DWARF 1 file. All of | |
1738 | @c these have reasonable defaults already. | |
1739 | ||
1740 | The DWARF 1 reader is in @file{dwarfread.c}. | |
1741 | ||
1742 | @subsection DWARF 2 | |
1743 | ||
56caf160 | 1744 | @cindex DWARF 2 debugging info |
c906108c SS |
1745 | DWARF 2 is an improved but incompatible version of DWARF 1. |
1746 | ||
1747 | The DWARF 2 reader is in @file{dwarf2read.c}. | |
1748 | ||
1749 | @subsection SOM | |
1750 | ||
56caf160 | 1751 | @cindex SOM debugging info |
c906108c SS |
1752 | Like COFF, the SOM definition includes debugging information. |
1753 | ||
25822942 | 1754 | @section Adding a New Symbol Reader to @value{GDBN} |
c906108c | 1755 | |
56caf160 EZ |
1756 | @cindex adding debugging info reader |
1757 | If you are using an existing object file format (@code{a.out}, COFF, ELF, etc), | |
c906108c SS |
1758 | there is probably little to be done. |
1759 | ||
1760 | If you need to add a new object file format, you must first add it to | |
1761 | BFD. This is beyond the scope of this document. | |
1762 | ||
1763 | You must then arrange for the BFD code to provide access to the | |
25822942 | 1764 | debugging symbols. Generally @value{GDBN} will have to call swapping routines |
c906108c | 1765 | from BFD and a few other BFD internal routines to locate the debugging |
25822942 | 1766 | information. As much as possible, @value{GDBN} should not depend on the BFD |
c906108c SS |
1767 | internal data structures. |
1768 | ||
1769 | For some targets (e.g., COFF), there is a special transfer vector used | |
1770 | to call swapping routines, since the external data structures on various | |
1771 | platforms have different sizes and layouts. Specialized routines that | |
1772 | will only ever be implemented by one object file format may be called | |
1773 | directly. This interface should be described in a file | |
56caf160 | 1774 | @file{bfd/lib@var{xyz}.h}, which is included by @value{GDBN}. |
c906108c SS |
1775 | |
1776 | ||
1777 | @node Language Support | |
1778 | ||
1779 | @chapter Language Support | |
1780 | ||
56caf160 EZ |
1781 | @cindex language support |
1782 | @value{GDBN}'s language support is mainly driven by the symbol reader, | |
1783 | although it is possible for the user to set the source language | |
1784 | manually. | |
c906108c | 1785 | |
56caf160 EZ |
1786 | @value{GDBN} chooses the source language by looking at the extension |
1787 | of the file recorded in the debug info; @file{.c} means C, @file{.f} | |
1788 | means Fortran, etc. It may also use a special-purpose language | |
1789 | identifier if the debug format supports it, like with DWARF. | |
c906108c | 1790 | |
25822942 | 1791 | @section Adding a Source Language to @value{GDBN} |
c906108c | 1792 | |
56caf160 EZ |
1793 | @cindex adding source language |
1794 | To add other languages to @value{GDBN}'s expression parser, follow the | |
1795 | following steps: | |
c906108c SS |
1796 | |
1797 | @table @emph | |
1798 | @item Create the expression parser. | |
1799 | ||
56caf160 | 1800 | @cindex expression parser |
c906108c | 1801 | This should reside in a file @file{@var{lang}-exp.y}. Routines for |
56caf160 | 1802 | building parsed expressions into a @code{union exp_element} list are in |
c906108c SS |
1803 | @file{parse.c}. |
1804 | ||
56caf160 | 1805 | @cindex language parser |
c906108c SS |
1806 | Since we can't depend upon everyone having Bison, and YACC produces |
1807 | parsers that define a bunch of global names, the following lines | |
56caf160 | 1808 | @strong{must} be included at the top of the YACC parser, to prevent the |
c906108c SS |
1809 | various parsers from defining the same global names: |
1810 | ||
1811 | @example | |
56caf160 EZ |
1812 | #define yyparse @var{lang}_parse |
1813 | #define yylex @var{lang}_lex | |
1814 | #define yyerror @var{lang}_error | |
1815 | #define yylval @var{lang}_lval | |
1816 | #define yychar @var{lang}_char | |
1817 | #define yydebug @var{lang}_debug | |
1818 | #define yypact @var{lang}_pact | |
1819 | #define yyr1 @var{lang}_r1 | |
1820 | #define yyr2 @var{lang}_r2 | |
1821 | #define yydef @var{lang}_def | |
1822 | #define yychk @var{lang}_chk | |
1823 | #define yypgo @var{lang}_pgo | |
1824 | #define yyact @var{lang}_act | |
1825 | #define yyexca @var{lang}_exca | |
1826 | #define yyerrflag @var{lang}_errflag | |
1827 | #define yynerrs @var{lang}_nerrs | |
c906108c SS |
1828 | @end example |
1829 | ||
1830 | At the bottom of your parser, define a @code{struct language_defn} and | |
1831 | initialize it with the right values for your language. Define an | |
1832 | @code{initialize_@var{lang}} routine and have it call | |
25822942 | 1833 | @samp{add_language(@var{lang}_language_defn)} to tell the rest of @value{GDBN} |
c906108c SS |
1834 | that your language exists. You'll need some other supporting variables |
1835 | and functions, which will be used via pointers from your | |
1836 | @code{@var{lang}_language_defn}. See the declaration of @code{struct | |
1837 | language_defn} in @file{language.h}, and the other @file{*-exp.y} files, | |
1838 | for more information. | |
1839 | ||
1840 | @item Add any evaluation routines, if necessary | |
1841 | ||
56caf160 EZ |
1842 | @cindex expression evaluation routines |
1843 | @findex evaluate_subexp | |
1844 | @findex prefixify_subexp | |
1845 | @findex length_of_subexp | |
c906108c SS |
1846 | If you need new opcodes (that represent the operations of the language), |
1847 | add them to the enumerated type in @file{expression.h}. Add support | |
56caf160 EZ |
1848 | code for these operations in the @code{evaluate_subexp} function |
1849 | defined in the file @file{eval.c}. Add cases | |
c906108c | 1850 | for new opcodes in two functions from @file{parse.c}: |
56caf160 | 1851 | @code{prefixify_subexp} and @code{length_of_subexp}. These compute |
c906108c SS |
1852 | the number of @code{exp_element}s that a given operation takes up. |
1853 | ||
1854 | @item Update some existing code | |
1855 | ||
1856 | Add an enumerated identifier for your language to the enumerated type | |
1857 | @code{enum language} in @file{defs.h}. | |
1858 | ||
1859 | Update the routines in @file{language.c} so your language is included. | |
1860 | These routines include type predicates and such, which (in some cases) | |
1861 | are language dependent. If your language does not appear in the switch | |
1862 | statement, an error is reported. | |
1863 | ||
56caf160 | 1864 | @vindex current_language |
c906108c SS |
1865 | Also included in @file{language.c} is the code that updates the variable |
1866 | @code{current_language}, and the routines that translate the | |
1867 | @code{language_@var{lang}} enumerated identifier into a printable | |
1868 | string. | |
1869 | ||
56caf160 | 1870 | @findex _initialize_language |
c906108c SS |
1871 | Update the function @code{_initialize_language} to include your |
1872 | language. This function picks the default language upon startup, so is | |
25822942 | 1873 | dependent upon which languages that @value{GDBN} is built for. |
c906108c | 1874 | |
56caf160 | 1875 | @findex allocate_symtab |
c906108c SS |
1876 | Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading |
1877 | code so that the language of each symtab (source file) is set properly. | |
1878 | This is used to determine the language to use at each stack frame level. | |
1879 | Currently, the language is set based upon the extension of the source | |
1880 | file. If the language can be better inferred from the symbol | |
1881 | information, please set the language of the symtab in the symbol-reading | |
1882 | code. | |
1883 | ||
56caf160 EZ |
1884 | @findex print_subexp |
1885 | @findex op_print_tab | |
1886 | Add helper code to @code{print_subexp} (in @file{expprint.c}) to handle any new | |
c906108c SS |
1887 | expression opcodes you have added to @file{expression.h}. Also, add the |
1888 | printed representations of your operators to @code{op_print_tab}. | |
1889 | ||
1890 | @item Add a place of call | |
1891 | ||
56caf160 | 1892 | @findex parse_exp_1 |
c906108c | 1893 | Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in |
56caf160 | 1894 | @code{parse_exp_1} (defined in @file{parse.c}). |
c906108c SS |
1895 | |
1896 | @item Use macros to trim code | |
1897 | ||
56caf160 | 1898 | @cindex trimming language-dependent code |
25822942 DB |
1899 | The user has the option of building @value{GDBN} for some or all of the |
1900 | languages. If the user decides to build @value{GDBN} for the language | |
c906108c SS |
1901 | @var{lang}, then every file dependent on @file{language.h} will have the |
1902 | macro @code{_LANG_@var{lang}} defined in it. Use @code{#ifdef}s to | |
1903 | leave out large routines that the user won't need if he or she is not | |
1904 | using your language. | |
1905 | ||
25822942 | 1906 | Note that you do not need to do this in your YACC parser, since if @value{GDBN} |
c906108c | 1907 | is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the |
25822942 | 1908 | compiled form of your parser) is not linked into @value{GDBN} at all. |
c906108c | 1909 | |
56caf160 EZ |
1910 | See the file @file{configure.in} for how @value{GDBN} is configured |
1911 | for different languages. | |
c906108c SS |
1912 | |
1913 | @item Edit @file{Makefile.in} | |
1914 | ||
1915 | Add dependencies in @file{Makefile.in}. Make sure you update the macro | |
1916 | variables such as @code{HFILES} and @code{OBJS}, otherwise your code may | |
1917 | not get linked in, or, worse yet, it may not get @code{tar}red into the | |
1918 | distribution! | |
c906108c SS |
1919 | @end table |
1920 | ||
1921 | ||
1922 | @node Host Definition | |
1923 | ||
1924 | @chapter Host Definition | |
1925 | ||
af6c57ea AC |
1926 | @emph{Maintainer's note: In theory, new targets no longer need to use |
1927 | the host framework described below. Instead it should be possible to | |
1928 | handle everything using autoconf. Patches eliminating this framework | |
1929 | welcome.} | |
1930 | ||
56caf160 | 1931 | With the advent of Autoconf, it's rarely necessary to have host |
c906108c SS |
1932 | definition machinery anymore. |
1933 | ||
1934 | @section Adding a New Host | |
1935 | ||
56caf160 EZ |
1936 | @cindex adding a new host |
1937 | @cindex host, adding | |
1938 | Most of @value{GDBN}'s host configuration support happens via | |
1939 | Autoconf. New host-specific definitions should be rarely needed. | |
1940 | @value{GDBN} still uses the host-specific definitions and files listed | |
1941 | below, but these mostly exist for historical reasons, and should | |
1942 | eventually disappear. | |
c906108c | 1943 | |
25822942 | 1944 | Several files control @value{GDBN}'s configuration for host systems: |
c906108c SS |
1945 | |
1946 | @table @file | |
56caf160 | 1947 | @vindex XDEPFILES |
c906108c SS |
1948 | @item gdb/config/@var{arch}/@var{xyz}.mh |
1949 | Specifies Makefile fragments needed when hosting on machine @var{xyz}. | |
1950 | In particular, this lists the required machine-dependent object files, | |
1951 | by defining @samp{XDEPFILES=@dots{}}. Also specifies the header file | |
1952 | which describes host @var{xyz}, by defining @code{XM_FILE= | |
1953 | xm-@var{xyz}.h}. You can also define @code{CC}, @code{SYSV_DEFINE}, | |
1954 | @code{XM_CFLAGS}, @code{XM_ADD_FILES}, @code{XM_CLIBS}, @code{XM_CDEPS}, | |
1955 | etc.; see @file{Makefile.in}. | |
1956 | ||
1957 | @item gdb/config/@var{arch}/xm-@var{xyz}.h | |
56caf160 | 1958 | (@file{xm.h} is a link to this file, created by @code{configure}). Contains C |
c906108c SS |
1959 | macro definitions describing the host system environment, such as byte |
1960 | order, host C compiler and library. | |
1961 | ||
1962 | @item gdb/@var{xyz}-xdep.c | |
1963 | Contains any miscellaneous C code required for this machine as a host. | |
1964 | On most machines it doesn't exist at all. If it does exist, put | |
1965 | @file{@var{xyz}-xdep.o} into the @code{XDEPFILES} line in | |
1966 | @file{gdb/config/@var{arch}/@var{xyz}.mh}. | |
c906108c SS |
1967 | @end table |
1968 | ||
1969 | @subheading Generic Host Support Files | |
1970 | ||
56caf160 | 1971 | @cindex generic host support |
c906108c SS |
1972 | There are some ``generic'' versions of routines that can be used by |
1973 | various systems. These can be customized in various ways by macros | |
1974 | defined in your @file{xm-@var{xyz}.h} file. If these routines work for | |
1975 | the @var{xyz} host, you can just include the generic file's name (with | |
1976 | @samp{.o}, not @samp{.c}) in @code{XDEPFILES}. | |
1977 | ||
1978 | Otherwise, if your machine needs custom support routines, you will need | |
1979 | to write routines that perform the same functions as the generic file. | |
1980 | Put them into @code{@var{xyz}-xdep.c}, and put @code{@var{xyz}-xdep.o} | |
1981 | into @code{XDEPFILES}. | |
1982 | ||
1983 | @table @file | |
56caf160 EZ |
1984 | @cindex remote debugging support |
1985 | @cindex serial line support | |
c906108c SS |
1986 | @item ser-unix.c |
1987 | This contains serial line support for Unix systems. This is always | |
1988 | included, via the makefile variable @code{SER_HARDWIRE}; override this | |
1989 | variable in the @file{.mh} file to avoid it. | |
1990 | ||
1991 | @item ser-go32.c | |
1992 | This contains serial line support for 32-bit programs running under DOS, | |
56caf160 | 1993 | using the DJGPP (a.k.a.@: GO32) execution environment. |
c906108c | 1994 | |
56caf160 | 1995 | @cindex TCP remote support |
c906108c SS |
1996 | @item ser-tcp.c |
1997 | This contains generic TCP support using sockets. | |
c906108c SS |
1998 | @end table |
1999 | ||
2000 | @section Host Conditionals | |
2001 | ||
56caf160 EZ |
2002 | When @value{GDBN} is configured and compiled, various macros are |
2003 | defined or left undefined, to control compilation based on the | |
2004 | attributes of the host system. These macros and their meanings (or if | |
2005 | the meaning is not documented here, then one of the source files where | |
2006 | they are used is indicated) are: | |
c906108c | 2007 | |
56caf160 | 2008 | @ftable @code |
25822942 | 2009 | @item @value{GDBN}INIT_FILENAME |
56caf160 EZ |
2010 | The default name of @value{GDBN}'s initialization file (normally |
2011 | @file{.gdbinit}). | |
c906108c SS |
2012 | |
2013 | @item MEM_FNS_DECLARED | |
2014 | Your host config file defines this if it includes declarations of | |
2015 | @code{memcpy} and @code{memset}. Define this to avoid conflicts between | |
2016 | the native include files and the declarations in @file{defs.h}. | |
2017 | ||
cce74817 JM |
2018 | @item NO_STD_REGS |
2019 | This macro is deprecated. | |
2020 | ||
c906108c SS |
2021 | @item NO_SYS_FILE |
2022 | Define this if your system does not have a @code{<sys/file.h>}. | |
2023 | ||
2024 | @item SIGWINCH_HANDLER | |
2025 | If your host defines @code{SIGWINCH}, you can define this to be the name | |
2026 | of a function to be called if @code{SIGWINCH} is received. | |
2027 | ||
2028 | @item SIGWINCH_HANDLER_BODY | |
2029 | Define this to expand into code that will define the function named by | |
2030 | the expansion of @code{SIGWINCH_HANDLER}. | |
2031 | ||
2032 | @item ALIGN_STACK_ON_STARTUP | |
56caf160 | 2033 | @cindex stack alignment |
c906108c SS |
2034 | Define this if your system is of a sort that will crash in |
2035 | @code{tgetent} if the stack happens not to be longword-aligned when | |
2036 | @code{main} is called. This is a rare situation, but is known to occur | |
2037 | on several different types of systems. | |
2038 | ||
2039 | @item CRLF_SOURCE_FILES | |
56caf160 | 2040 | @cindex DOS text files |
c906108c SS |
2041 | Define this if host files use @code{\r\n} rather than @code{\n} as a |
2042 | line terminator. This will cause source file listings to omit @code{\r} | |
56caf160 EZ |
2043 | characters when printing and it will allow @code{\r\n} line endings of files |
2044 | which are ``sourced'' by gdb. It must be possible to open files in binary | |
c906108c SS |
2045 | mode using @code{O_BINARY} or, for fopen, @code{"rb"}. |
2046 | ||
2047 | @item DEFAULT_PROMPT | |
56caf160 | 2048 | @cindex prompt |
c906108c SS |
2049 | The default value of the prompt string (normally @code{"(gdb) "}). |
2050 | ||
2051 | @item DEV_TTY | |
56caf160 | 2052 | @cindex terminal device |
c906108c SS |
2053 | The name of the generic TTY device, defaults to @code{"/dev/tty"}. |
2054 | ||
2055 | @item FCLOSE_PROVIDED | |
2056 | Define this if the system declares @code{fclose} in the headers included | |
2057 | in @code{defs.h}. This isn't needed unless your compiler is unusually | |
2058 | anal. | |
2059 | ||
2060 | @item FOPEN_RB | |
2061 | Define this if binary files are opened the same way as text files. | |
2062 | ||
2063 | @item GETENV_PROVIDED | |
2064 | Define this if the system declares @code{getenv} in its headers included | |
56caf160 | 2065 | in @code{defs.h}. This isn't needed unless your compiler is unusually |
c906108c SS |
2066 | anal. |
2067 | ||
2068 | @item HAVE_MMAP | |
56caf160 | 2069 | @findex mmap |
c906108c SS |
2070 | In some cases, use the system call @code{mmap} for reading symbol |
2071 | tables. For some machines this allows for sharing and quick updates. | |
2072 | ||
2073 | @item HAVE_SIGSETMASK | |
56caf160 | 2074 | @findex sigsetmask |
c906108c | 2075 | Define this if the host system has job control, but does not define |
56caf160 | 2076 | @code{sigsetmask}. Currently, this is only true of the RS/6000. |
c906108c SS |
2077 | |
2078 | @item HAVE_TERMIO | |
2079 | Define this if the host system has @code{termio.h}. | |
2080 | ||
2081 | @item HOST_BYTE_ORDER | |
56caf160 | 2082 | @cindex byte order |
c906108c SS |
2083 | The ordering of bytes in the host. This must be defined to be either |
2084 | @code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}. | |
2085 | ||
2086 | @item INT_MAX | |
9742079a EZ |
2087 | @itemx INT_MIN |
2088 | @itemx LONG_MAX | |
2089 | @itemx UINT_MAX | |
2090 | @itemx ULONG_MAX | |
c906108c SS |
2091 | Values for host-side constants. |
2092 | ||
2093 | @item ISATTY | |
2094 | Substitute for isatty, if not available. | |
2095 | ||
2096 | @item LONGEST | |
2097 | This is the longest integer type available on the host. If not defined, | |
2098 | it will default to @code{long long} or @code{long}, depending on | |
2099 | @code{CC_HAS_LONG_LONG}. | |
2100 | ||
2101 | @item CC_HAS_LONG_LONG | |
56caf160 EZ |
2102 | @cindex @code{long long} data type |
2103 | Define this if the host C compiler supports @code{long long}. This is set | |
2104 | by the @code{configure} script. | |
c906108c SS |
2105 | |
2106 | @item PRINTF_HAS_LONG_LONG | |
2107 | Define this if the host can handle printing of long long integers via | |
56caf160 EZ |
2108 | the printf format conversion specifier @code{ll}. This is set by the |
2109 | @code{configure} script. | |
c906108c SS |
2110 | |
2111 | @item HAVE_LONG_DOUBLE | |
56caf160 EZ |
2112 | Define this if the host C compiler supports @code{long double}. This is |
2113 | set by the @code{configure} script. | |
c906108c SS |
2114 | |
2115 | @item PRINTF_HAS_LONG_DOUBLE | |
2116 | Define this if the host can handle printing of long double float-point | |
56caf160 EZ |
2117 | numbers via the printf format conversion specifier @code{Lg}. This is |
2118 | set by the @code{configure} script. | |
c906108c SS |
2119 | |
2120 | @item SCANF_HAS_LONG_DOUBLE | |
2121 | Define this if the host can handle the parsing of long double | |
56caf160 EZ |
2122 | float-point numbers via the scanf format conversion specifier |
2123 | @code{Lg}. This is set by the @code{configure} script. | |
c906108c SS |
2124 | |
2125 | @item LSEEK_NOT_LINEAR | |
2126 | Define this if @code{lseek (n)} does not necessarily move to byte number | |
2127 | @code{n} in the file. This is only used when reading source files. It | |
2128 | is normally faster to define @code{CRLF_SOURCE_FILES} when possible. | |
2129 | ||
2130 | @item L_SET | |
56caf160 EZ |
2131 | This macro is used as the argument to @code{lseek} (or, most commonly, |
2132 | @code{bfd_seek}). FIXME, should be replaced by SEEK_SET instead, | |
2133 | which is the POSIX equivalent. | |
c906108c | 2134 | |
c906108c SS |
2135 | @item MALLOC_INCOMPATIBLE |
2136 | Define this if the system's prototype for @code{malloc} differs from the | |
56caf160 | 2137 | @sc{ansi} definition. |
c906108c SS |
2138 | |
2139 | @item MMAP_BASE_ADDRESS | |
2140 | When using HAVE_MMAP, the first mapping should go at this address. | |
2141 | ||
2142 | @item MMAP_INCREMENT | |
2143 | when using HAVE_MMAP, this is the increment between mappings. | |
2144 | ||
c906108c SS |
2145 | @item NORETURN |
2146 | If defined, this should be one or more tokens, such as @code{volatile}, | |
2147 | that can be used in both the declaration and definition of functions to | |
2148 | indicate that they never return. The default is already set correctly | |
2149 | if compiling with GCC. This will almost never need to be defined. | |
2150 | ||
2151 | @item ATTR_NORETURN | |
2152 | If defined, this should be one or more tokens, such as | |
2153 | @code{__attribute__ ((noreturn))}, that can be used in the declarations | |
2154 | of functions to indicate that they never return. The default is already | |
2155 | set correctly if compiling with GCC. This will almost never need to be | |
2156 | defined. | |
2157 | ||
7a292a7a | 2158 | @item USE_GENERIC_DUMMY_FRAMES |
56caf160 | 2159 | @cindex generic dummy frames |
7a292a7a SS |
2160 | Define this to 1 if the target is using the generic inferior function |
2161 | call code. See @code{blockframe.c} for more information. | |
2162 | ||
c906108c | 2163 | @item USE_MMALLOC |
56caf160 EZ |
2164 | @findex mmalloc |
2165 | @value{GDBN} will use the @code{mmalloc} library for memory allocation | |
2166 | for symbol reading if this symbol is defined. Be careful defining it | |
2167 | since there are systems on which @code{mmalloc} does not work for some | |
2168 | reason. One example is the DECstation, where its RPC library can't | |
2169 | cope with our redefinition of @code{malloc} to call @code{mmalloc}. | |
2170 | When defining @code{USE_MMALLOC}, you will also have to set | |
2171 | @code{MMALLOC} in the Makefile, to point to the @code{mmalloc} library. This | |
2172 | define is set when you configure with @samp{--with-mmalloc}. | |
c906108c SS |
2173 | |
2174 | @item NO_MMCHECK | |
56caf160 | 2175 | @findex mmcheck |
c906108c SS |
2176 | Define this if you are using @code{mmalloc}, but don't want the overhead |
2177 | of checking the heap with @code{mmcheck}. Note that on some systems, | |
56caf160 | 2178 | the C runtime makes calls to @code{malloc} prior to calling @code{main}, and if |
c906108c SS |
2179 | @code{free} is ever called with these pointers after calling |
2180 | @code{mmcheck} to enable checking, a memory corruption abort is certain | |
56caf160 EZ |
2181 | to occur. These systems can still use @code{mmalloc}, but must define |
2182 | @code{NO_MMCHECK}. | |
c906108c SS |
2183 | |
2184 | @item MMCHECK_FORCE | |
2185 | Define this to 1 if the C runtime allocates memory prior to | |
2186 | @code{mmcheck} being called, but that memory is never freed so we don't | |
2187 | have to worry about it triggering a memory corruption abort. The | |
2188 | default is 0, which means that @code{mmcheck} will only install the heap | |
2189 | checking functions if there has not yet been any memory allocation | |
56caf160 | 2190 | calls, and if it fails to install the functions, @value{GDBN} will issue a |
c906108c | 2191 | warning. This is currently defined if you configure using |
56caf160 | 2192 | @samp{--with-mmalloc}. |
c906108c SS |
2193 | |
2194 | @item NO_SIGINTERRUPT | |
56caf160 EZ |
2195 | @findex siginterrupt |
2196 | Define this to indicate that @code{siginterrupt} is not available. | |
c906108c SS |
2197 | |
2198 | @item R_OK | |
56caf160 | 2199 | Define if this is not in a system header file (typically, @file{unistd.h}). |
c906108c SS |
2200 | |
2201 | @item SEEK_CUR | |
9742079a | 2202 | @itemx SEEK_SET |
56caf160 | 2203 | Define these to appropriate value for the system @code{lseek}, if not already |
c906108c SS |
2204 | defined. |
2205 | ||
2206 | @item STOP_SIGNAL | |
56caf160 EZ |
2207 | This is the signal for stopping @value{GDBN}. Defaults to |
2208 | @code{SIGTSTP}. (Only redefined for the Convex.) | |
c906108c SS |
2209 | |
2210 | @item USE_O_NOCTTY | |
56caf160 | 2211 | Define this if the interior's tty should be opened with the @code{O_NOCTTY} |
c906108c SS |
2212 | flag. (FIXME: This should be a native-only flag, but @file{inflow.c} is |
2213 | always linked in.) | |
2214 | ||
2215 | @item USG | |
2216 | Means that System V (prior to SVR4) include files are in use. (FIXME: | |
2217 | This symbol is abused in @file{infrun.c}, @file{regex.c}, | |
2218 | @file{remote-nindy.c}, and @file{utils.c} for other things, at the | |
2219 | moment.) | |
2220 | ||
2221 | @item lint | |
56caf160 | 2222 | Define this to help placate @code{lint} in some situations. |
c906108c SS |
2223 | |
2224 | @item volatile | |
2225 | Define this to override the defaults of @code{__volatile__} or | |
2226 | @code{/**/}. | |
56caf160 | 2227 | @end ftable |
c906108c SS |
2228 | |
2229 | ||
2230 | @node Target Architecture Definition | |
2231 | ||
2232 | @chapter Target Architecture Definition | |
2233 | ||
56caf160 EZ |
2234 | @cindex target architecture definition |
2235 | @value{GDBN}'s target architecture defines what sort of | |
2236 | machine-language programs @value{GDBN} can work with, and how it works | |
2237 | with them. | |
c906108c | 2238 | |
af6c57ea AC |
2239 | The target architecture object is implemented as the C structure |
2240 | @code{struct gdbarch *}. The structure, and its methods, are generated | |
2241 | using the Bourn shell script @file{gdbarch.sh}. | |
c906108c SS |
2242 | |
2243 | @section Registers and Memory | |
2244 | ||
56caf160 EZ |
2245 | @value{GDBN}'s model of the target machine is rather simple. |
2246 | @value{GDBN} assumes the machine includes a bank of registers and a | |
2247 | block of memory. Each register may have a different size. | |
c906108c | 2248 | |
56caf160 EZ |
2249 | @value{GDBN} does not have a magical way to match up with the |
2250 | compiler's idea of which registers are which; however, it is critical | |
2251 | that they do match up accurately. The only way to make this work is | |
2252 | to get accurate information about the order that the compiler uses, | |
2253 | and to reflect that in the @code{REGISTER_NAME} and related macros. | |
c906108c | 2254 | |
25822942 | 2255 | @value{GDBN} can handle big-endian, little-endian, and bi-endian architectures. |
c906108c | 2256 | |
93e79dbd JB |
2257 | @section Pointers Are Not Always Addresses |
2258 | @cindex pointer representation | |
2259 | @cindex address representation | |
2260 | @cindex word-addressed machines | |
2261 | @cindex separate data and code address spaces | |
2262 | @cindex spaces, separate data and code address | |
2263 | @cindex address spaces, separate data and code | |
2264 | @cindex code pointers, word-addressed | |
2265 | @cindex converting between pointers and addresses | |
2266 | @cindex D10V addresses | |
2267 | ||
2268 | On almost all 32-bit architectures, the representation of a pointer is | |
2269 | indistinguishable from the representation of some fixed-length number | |
2270 | whose value is the byte address of the object pointed to. On such | |
56caf160 | 2271 | machines, the words ``pointer'' and ``address'' can be used interchangeably. |
93e79dbd JB |
2272 | However, architectures with smaller word sizes are often cramped for |
2273 | address space, so they may choose a pointer representation that breaks this | |
2274 | identity, and allows a larger code address space. | |
2275 | ||
2276 | For example, the Mitsubishi D10V is a 16-bit VLIW processor whose | |
2277 | instructions are 32 bits long@footnote{Some D10V instructions are | |
2278 | actually pairs of 16-bit sub-instructions. However, since you can't | |
2279 | jump into the middle of such a pair, code addresses can only refer to | |
2280 | full 32 bit instructions, which is what matters in this explanation.}. | |
2281 | If the D10V used ordinary byte addresses to refer to code locations, | |
2282 | then the processor would only be able to address 64kb of instructions. | |
2283 | However, since instructions must be aligned on four-byte boundaries, the | |
56caf160 EZ |
2284 | low two bits of any valid instruction's byte address are always |
2285 | zero---byte addresses waste two bits. So instead of byte addresses, | |
2286 | the D10V uses word addresses---byte addresses shifted right two bits---to | |
93e79dbd JB |
2287 | refer to code. Thus, the D10V can use 16-bit words to address 256kb of |
2288 | code space. | |
2289 | ||
2290 | However, this means that code pointers and data pointers have different | |
2291 | forms on the D10V. The 16-bit word @code{0xC020} refers to byte address | |
2292 | @code{0xC020} when used as a data address, but refers to byte address | |
2293 | @code{0x30080} when used as a code address. | |
2294 | ||
2295 | (The D10V also uses separate code and data address spaces, which also | |
2296 | affects the correspondence between pointers and addresses, but we're | |
2297 | going to ignore that here; this example is already too long.) | |
2298 | ||
56caf160 EZ |
2299 | To cope with architectures like this---the D10V is not the only |
2300 | one!---@value{GDBN} tries to distinguish between @dfn{addresses}, which are | |
93e79dbd JB |
2301 | byte numbers, and @dfn{pointers}, which are the target's representation |
2302 | of an address of a particular type of data. In the example above, | |
2303 | @code{0xC020} is the pointer, which refers to one of the addresses | |
2304 | @code{0xC020} or @code{0x30080}, depending on the type imposed upon it. | |
2305 | @value{GDBN} provides functions for turning a pointer into an address | |
2306 | and vice versa, in the appropriate way for the current architecture. | |
2307 | ||
2308 | Unfortunately, since addresses and pointers are identical on almost all | |
2309 | processors, this distinction tends to bit-rot pretty quickly. Thus, | |
2310 | each time you port @value{GDBN} to an architecture which does | |
2311 | distinguish between pointers and addresses, you'll probably need to | |
2312 | clean up some architecture-independent code. | |
2313 | ||
2314 | Here are functions which convert between pointers and addresses: | |
2315 | ||
2316 | @deftypefun CORE_ADDR extract_typed_address (void *@var{buf}, struct type *@var{type}) | |
2317 | Treat the bytes at @var{buf} as a pointer or reference of type | |
2318 | @var{type}, and return the address it represents, in a manner | |
2319 | appropriate for the current architecture. This yields an address | |
2320 | @value{GDBN} can use to read target memory, disassemble, etc. Note that | |
2321 | @var{buf} refers to a buffer in @value{GDBN}'s memory, not the | |
2322 | inferior's. | |
2323 | ||
2324 | For example, if the current architecture is the Intel x86, this function | |
2325 | extracts a little-endian integer of the appropriate length from | |
2326 | @var{buf} and returns it. However, if the current architecture is the | |
2327 | D10V, this function will return a 16-bit integer extracted from | |
2328 | @var{buf}, multiplied by four if @var{type} is a pointer to a function. | |
2329 | ||
2330 | If @var{type} is not a pointer or reference type, then this function | |
2331 | will signal an internal error. | |
2332 | @end deftypefun | |
2333 | ||
2334 | @deftypefun CORE_ADDR store_typed_address (void *@var{buf}, struct type *@var{type}, CORE_ADDR @var{addr}) | |
2335 | Store the address @var{addr} in @var{buf}, in the proper format for a | |
2336 | pointer of type @var{type} in the current architecture. Note that | |
2337 | @var{buf} refers to a buffer in @value{GDBN}'s memory, not the | |
2338 | inferior's. | |
2339 | ||
2340 | For example, if the current architecture is the Intel x86, this function | |
2341 | stores @var{addr} unmodified as a little-endian integer of the | |
2342 | appropriate length in @var{buf}. However, if the current architecture | |
2343 | is the D10V, this function divides @var{addr} by four if @var{type} is | |
2344 | a pointer to a function, and then stores it in @var{buf}. | |
2345 | ||
2346 | If @var{type} is not a pointer or reference type, then this function | |
2347 | will signal an internal error. | |
2348 | @end deftypefun | |
2349 | ||
2350 | @deftypefun CORE_ADDR value_as_pointer (value_ptr @var{val}) | |
2351 | Assuming that @var{val} is a pointer, return the address it represents, | |
2352 | as appropriate for the current architecture. | |
2353 | ||
2354 | This function actually works on integral values, as well as pointers. | |
2355 | For pointers, it performs architecture-specific conversions as | |
2356 | described above for @code{extract_typed_address}. | |
2357 | @end deftypefun | |
2358 | ||
2359 | @deftypefun CORE_ADDR value_from_pointer (struct type *@var{type}, CORE_ADDR @var{addr}) | |
2360 | Create and return a value representing a pointer of type @var{type} to | |
2361 | the address @var{addr}, as appropriate for the current architecture. | |
2362 | This function performs architecture-specific conversions as described | |
2363 | above for @code{store_typed_address}. | |
2364 | @end deftypefun | |
2365 | ||
2366 | ||
2367 | @value{GDBN} also provides functions that do the same tasks, but assume | |
2368 | that pointers are simply byte addresses; they aren't sensitive to the | |
2369 | current architecture, beyond knowing the appropriate endianness. | |
2370 | ||
2371 | @deftypefun CORE_ADDR extract_address (void *@var{addr}, int len) | |
2372 | Extract a @var{len}-byte number from @var{addr} in the appropriate | |
2373 | endianness for the current architecture, and return it. Note that | |
2374 | @var{addr} refers to @value{GDBN}'s memory, not the inferior's. | |
2375 | ||
2376 | This function should only be used in architecture-specific code; it | |
2377 | doesn't have enough information to turn bits into a true address in the | |
2378 | appropriate way for the current architecture. If you can, use | |
2379 | @code{extract_typed_address} instead. | |
2380 | @end deftypefun | |
2381 | ||
2382 | @deftypefun void store_address (void *@var{addr}, int @var{len}, LONGEST @var{val}) | |
2383 | Store @var{val} at @var{addr} as a @var{len}-byte integer, in the | |
2384 | appropriate endianness for the current architecture. Note that | |
2385 | @var{addr} refers to a buffer in @value{GDBN}'s memory, not the | |
2386 | inferior's. | |
2387 | ||
2388 | This function should only be used in architecture-specific code; it | |
2389 | doesn't have enough information to turn a true address into bits in the | |
2390 | appropriate way for the current architecture. If you can, use | |
2391 | @code{store_typed_address} instead. | |
2392 | @end deftypefun | |
2393 | ||
2394 | ||
2395 | Here are some macros which architectures can define to indicate the | |
2396 | relationship between pointers and addresses. These have default | |
2397 | definitions, appropriate for architectures on which all pointers are | |
2398 | simple byte addresses. | |
2399 | ||
2400 | @deftypefn {Target Macro} CORE_ADDR POINTER_TO_ADDRESS (struct type *@var{type}, char *@var{buf}) | |
2401 | Assume that @var{buf} holds a pointer of type @var{type}, in the | |
2402 | appropriate format for the current architecture. Return the byte | |
2403 | address the pointer refers to. | |
2404 | ||
2405 | This function may safely assume that @var{type} is either a pointer or a | |
56caf160 | 2406 | C@t{++} reference type. |
93e79dbd JB |
2407 | @end deftypefn |
2408 | ||
2409 | @deftypefn {Target Macro} void ADDRESS_TO_POINTER (struct type *@var{type}, char *@var{buf}, CORE_ADDR @var{addr}) | |
2410 | Store in @var{buf} a pointer of type @var{type} representing the address | |
2411 | @var{addr}, in the appropriate format for the current architecture. | |
2412 | ||
2413 | This function may safely assume that @var{type} is either a pointer or a | |
56caf160 | 2414 | C@t{++} reference type. |
93e79dbd JB |
2415 | @end deftypefn |
2416 | ||
2417 | ||
9fb4dd36 JB |
2418 | @section Using Different Register and Memory Data Representations |
2419 | @cindex raw representation | |
2420 | @cindex virtual representation | |
2421 | @cindex representations, raw and virtual | |
2422 | @cindex register data formats, converting | |
2423 | @cindex @code{struct value}, converting register contents to | |
2424 | ||
af6c57ea AC |
2425 | @emph{Maintainer's note: The way GDB manipulates registers is undergoing |
2426 | significant change. Many of the macros and functions refered to in the | |
2427 | sections below are likely to be made obsolete. See the file @file{TODO} | |
2428 | for more up-to-date information.} | |
2429 | ||
9fb4dd36 JB |
2430 | Some architectures use one representation for a value when it lives in a |
2431 | register, but use a different representation when it lives in memory. | |
25822942 | 2432 | In @value{GDBN}'s terminology, the @dfn{raw} representation is the one used in |
9fb4dd36 | 2433 | the target registers, and the @dfn{virtual} representation is the one |
25822942 | 2434 | used in memory, and within @value{GDBN} @code{struct value} objects. |
9fb4dd36 JB |
2435 | |
2436 | For almost all data types on almost all architectures, the virtual and | |
2437 | raw representations are identical, and no special handling is needed. | |
2438 | However, they do occasionally differ. For example: | |
2439 | ||
2440 | @itemize @bullet | |
9fb4dd36 | 2441 | @item |
56caf160 | 2442 | The x86 architecture supports an 80-bit @code{long double} type. However, when |
9fb4dd36 JB |
2443 | we store those values in memory, they occupy twelve bytes: the |
2444 | floating-point number occupies the first ten, and the final two bytes | |
2445 | are unused. This keeps the values aligned on four-byte boundaries, | |
2446 | allowing more efficient access. Thus, the x86 80-bit floating-point | |
2447 | type is the raw representation, and the twelve-byte loosely-packed | |
2448 | arrangement is the virtual representation. | |
2449 | ||
2450 | @item | |
25822942 DB |
2451 | Some 64-bit MIPS targets present 32-bit registers to @value{GDBN} as 64-bit |
2452 | registers, with garbage in their upper bits. @value{GDBN} ignores the top 32 | |
9fb4dd36 JB |
2453 | bits. Thus, the 64-bit form, with garbage in the upper 32 bits, is the |
2454 | raw representation, and the trimmed 32-bit representation is the | |
2455 | virtual representation. | |
9fb4dd36 JB |
2456 | @end itemize |
2457 | ||
2458 | In general, the raw representation is determined by the architecture, or | |
25822942 DB |
2459 | @value{GDBN}'s interface to the architecture, while the virtual representation |
2460 | can be chosen for @value{GDBN}'s convenience. @value{GDBN}'s register file, | |
56caf160 EZ |
2461 | @code{registers}, holds the register contents in raw format, and the |
2462 | @value{GDBN} remote protocol transmits register values in raw format. | |
9fb4dd36 | 2463 | |
56caf160 EZ |
2464 | Your architecture may define the following macros to request |
2465 | conversions between the raw and virtual format: | |
9fb4dd36 JB |
2466 | |
2467 | @deftypefn {Target Macro} int REGISTER_CONVERTIBLE (int @var{reg}) | |
2468 | Return non-zero if register number @var{reg}'s value needs different raw | |
2469 | and virtual formats. | |
6f6ef15a EZ |
2470 | |
2471 | You should not use @code{REGISTER_CONVERT_TO_VIRTUAL} for a register | |
2472 | unless this macro returns a non-zero value for that register. | |
9fb4dd36 JB |
2473 | @end deftypefn |
2474 | ||
2475 | @deftypefn {Target Macro} int REGISTER_RAW_SIZE (int @var{reg}) | |
2476 | The size of register number @var{reg}'s raw value. This is the number | |
25822942 | 2477 | of bytes the register will occupy in @code{registers}, or in a @value{GDBN} |
9fb4dd36 JB |
2478 | remote protocol packet. |
2479 | @end deftypefn | |
2480 | ||
2481 | @deftypefn {Target Macro} int REGISTER_VIRTUAL_SIZE (int @var{reg}) | |
2482 | The size of register number @var{reg}'s value, in its virtual format. | |
2483 | This is the size a @code{struct value}'s buffer will have, holding that | |
2484 | register's value. | |
2485 | @end deftypefn | |
2486 | ||
2487 | @deftypefn {Target Macro} struct type *REGISTER_VIRTUAL_TYPE (int @var{reg}) | |
2488 | This is the type of the virtual representation of register number | |
2489 | @var{reg}. Note that there is no need for a macro giving a type for the | |
25822942 | 2490 | register's raw form; once the register's value has been obtained, @value{GDBN} |
9fb4dd36 JB |
2491 | always uses the virtual form. |
2492 | @end deftypefn | |
2493 | ||
2494 | @deftypefn {Target Macro} void REGISTER_CONVERT_TO_VIRTUAL (int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to}) | |
2495 | Convert the value of register number @var{reg} to @var{type}, which | |
2496 | should always be @code{REGISTER_VIRTUAL_TYPE (@var{reg})}. The buffer | |
2497 | at @var{from} holds the register's value in raw format; the macro should | |
2498 | convert the value to virtual format, and place it at @var{to}. | |
2499 | ||
6f6ef15a EZ |
2500 | Note that @code{REGISTER_CONVERT_TO_VIRTUAL} and |
2501 | @code{REGISTER_CONVERT_TO_RAW} take their @var{reg} and @var{type} | |
2502 | arguments in different orders. | |
2503 | ||
2504 | You should only use @code{REGISTER_CONVERT_TO_VIRTUAL} with registers | |
2505 | for which the @code{REGISTER_CONVERTIBLE} macro returns a non-zero | |
2506 | value. | |
9fb4dd36 JB |
2507 | @end deftypefn |
2508 | ||
2509 | @deftypefn {Target Macro} void REGISTER_CONVERT_TO_RAW (struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to}) | |
2510 | Convert the value of register number @var{reg} to @var{type}, which | |
2511 | should always be @code{REGISTER_VIRTUAL_TYPE (@var{reg})}. The buffer | |
2512 | at @var{from} holds the register's value in raw format; the macro should | |
2513 | convert the value to virtual format, and place it at @var{to}. | |
2514 | ||
2515 | Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW take | |
2516 | their @var{reg} and @var{type} arguments in different orders. | |
2517 | @end deftypefn | |
2518 | ||
2519 | ||
c906108c SS |
2520 | @section Frame Interpretation |
2521 | ||
2522 | @section Inferior Call Setup | |
2523 | ||
2524 | @section Compiler Characteristics | |
2525 | ||
2526 | @section Target Conditionals | |
2527 | ||
2528 | This section describes the macros that you can use to define the target | |
2529 | machine. | |
2530 | ||
2531 | @table @code | |
2532 | ||
2533 | @item ADDITIONAL_OPTIONS | |
56caf160 EZ |
2534 | @itemx ADDITIONAL_OPTION_CASES |
2535 | @itemx ADDITIONAL_OPTION_HANDLER | |
2536 | @itemx ADDITIONAL_OPTION_HELP | |
2537 | @findex ADDITIONAL_OPTION_HELP | |
2538 | @findex ADDITIONAL_OPTION_HANDLER | |
2539 | @findex ADDITIONAL_OPTION_CASES | |
2540 | @findex ADDITIONAL_OPTIONS | |
c906108c | 2541 | These are a set of macros that allow the addition of additional command |
25822942 | 2542 | line options to @value{GDBN}. They are currently used only for the unsupported |
c906108c SS |
2543 | i960 Nindy target, and should not be used in any other configuration. |
2544 | ||
2545 | @item ADDR_BITS_REMOVE (addr) | |
56caf160 | 2546 | @findex ADDR_BITS_REMOVE |
adf40b2e JM |
2547 | If a raw machine instruction address includes any bits that are not |
2548 | really part of the address, then define this macro to expand into an | |
56caf160 | 2549 | expression that zeroes those bits in @var{addr}. This is only used for |
adf40b2e JM |
2550 | addresses of instructions, and even then not in all contexts. |
2551 | ||
2552 | For example, the two low-order bits of the PC on the Hewlett-Packard PA | |
2553 | 2.0 architecture contain the privilege level of the corresponding | |
2554 | instruction. Since instructions must always be aligned on four-byte | |
2555 | boundaries, the processor masks out these bits to generate the actual | |
2556 | address of the instruction. ADDR_BITS_REMOVE should filter out these | |
2557 | bits with an expression such as @code{((addr) & ~3)}. | |
c906108c | 2558 | |
93e79dbd | 2559 | @item ADDRESS_TO_POINTER (@var{type}, @var{buf}, @var{addr}) |
56caf160 | 2560 | @findex ADDRESS_TO_POINTER |
93e79dbd JB |
2561 | Store in @var{buf} a pointer of type @var{type} representing the address |
2562 | @var{addr}, in the appropriate format for the current architecture. | |
2563 | This macro may safely assume that @var{type} is either a pointer or a | |
56caf160 | 2564 | C@t{++} reference type. |
93e79dbd JB |
2565 | @xref{Target Architecture Definition, , Pointers Are Not Always Addresses}. |
2566 | ||
c906108c | 2567 | @item BEFORE_MAIN_LOOP_HOOK |
56caf160 | 2568 | @findex BEFORE_MAIN_LOOP_HOOK |
c906108c SS |
2569 | Define this to expand into any code that you want to execute before the |
2570 | main loop starts. Although this is not, strictly speaking, a target | |
2571 | conditional, that is how it is currently being used. Note that if a | |
2572 | configuration were to define it one way for a host and a different way | |
56caf160 EZ |
2573 | for the target, @value{GDBN} will probably not compile, let alone run |
2574 | correctly. This macro is currently used only for the unsupported i960 Nindy | |
2575 | target, and should not be used in any other configuration. | |
c906108c SS |
2576 | |
2577 | @item BELIEVE_PCC_PROMOTION | |
56caf160 EZ |
2578 | @findex BELIEVE_PCC_PROMOTION |
2579 | Define if the compiler promotes a @code{short} or @code{char} | |
2580 | parameter to an @code{int}, but still reports the parameter as its | |
2581 | original type, rather than the promoted type. | |
c906108c SS |
2582 | |
2583 | @item BELIEVE_PCC_PROMOTION_TYPE | |
56caf160 EZ |
2584 | @findex BELIEVE_PCC_PROMOTION_TYPE |
2585 | Define this if @value{GDBN} should believe the type of a @code{short} | |
2586 | argument when compiled by @code{pcc}, but look within a full int space to get | |
2587 | its value. Only defined for Sun-3 at present. | |
c906108c SS |
2588 | |
2589 | @item BITS_BIG_ENDIAN | |
56caf160 EZ |
2590 | @findex BITS_BIG_ENDIAN |
2591 | Define this if the numbering of bits in the targets does @strong{not} match the | |
c906108c | 2592 | endianness of the target byte order. A value of 1 means that the bits |
56caf160 | 2593 | are numbered in a big-endian bit order, 0 means little-endian. |
c906108c SS |
2594 | |
2595 | @item BREAKPOINT | |
56caf160 | 2596 | @findex BREAKPOINT |
c906108c SS |
2597 | This is the character array initializer for the bit pattern to put into |
2598 | memory where a breakpoint is set. Although it's common to use a trap | |
2599 | instruction for a breakpoint, it's not required; for instance, the bit | |
2600 | pattern could be an invalid instruction. The breakpoint must be no | |
2601 | longer than the shortest instruction of the architecture. | |
2602 | ||
56caf160 EZ |
2603 | @code{BREAKPOINT} has been deprecated in favor of |
2604 | @code{BREAKPOINT_FROM_PC}. | |
7a292a7a | 2605 | |
c906108c | 2606 | @item BIG_BREAKPOINT |
56caf160 EZ |
2607 | @itemx LITTLE_BREAKPOINT |
2608 | @findex LITTLE_BREAKPOINT | |
2609 | @findex BIG_BREAKPOINT | |
c906108c SS |
2610 | Similar to BREAKPOINT, but used for bi-endian targets. |
2611 | ||
56caf160 EZ |
2612 | @code{BIG_BREAKPOINT} and @code{LITTLE_BREAKPOINT} have been deprecated in |
2613 | favor of @code{BREAKPOINT_FROM_PC}. | |
7a292a7a | 2614 | |
c906108c | 2615 | @item REMOTE_BREAKPOINT |
56caf160 EZ |
2616 | @itemx LITTLE_REMOTE_BREAKPOINT |
2617 | @itemx BIG_REMOTE_BREAKPOINT | |
2618 | @findex BIG_REMOTE_BREAKPOINT | |
2619 | @findex LITTLE_REMOTE_BREAKPOINT | |
2620 | @findex REMOTE_BREAKPOINT | |
c906108c SS |
2621 | Similar to BREAKPOINT, but used for remote targets. |
2622 | ||
56caf160 EZ |
2623 | @code{BIG_REMOTE_BREAKPOINT} and @code{LITTLE_REMOTE_BREAKPOINT} have been |
2624 | deprecated in favor of @code{BREAKPOINT_FROM_PC}. | |
c906108c | 2625 | |
56caf160 EZ |
2626 | @item BREAKPOINT_FROM_PC (@var{pcptr}, @var{lenptr}) |
2627 | @findex BREAKPOINT_FROM_PC | |
c906108c | 2628 | Use the program counter to determine the contents and size of a |
56caf160 EZ |
2629 | breakpoint instruction. It returns a pointer to a string of bytes |
2630 | that encode a breakpoint instruction, stores the length of the string | |
2631 | to *@var{lenptr}, and adjusts pc (if necessary) to point to the actual | |
2632 | memory location where the breakpoint should be inserted. | |
c906108c SS |
2633 | |
2634 | Although it is common to use a trap instruction for a breakpoint, it's | |
2635 | not required; for instance, the bit pattern could be an invalid | |
2636 | instruction. The breakpoint must be no longer than the shortest | |
2637 | instruction of the architecture. | |
2638 | ||
7a292a7a SS |
2639 | Replaces all the other @var{BREAKPOINT} macros. |
2640 | ||
56caf160 EZ |
2641 | @item MEMORY_INSERT_BREAKPOINT (@var{addr}, @var{contents_cache}) |
2642 | @itemx MEMORY_REMOVE_BREAKPOINT (@var{addr}, @var{contents_cache}) | |
2643 | @findex MEMORY_REMOVE_BREAKPOINT | |
2644 | @findex MEMORY_INSERT_BREAKPOINT | |
917317f4 JM |
2645 | Insert or remove memory based breakpoints. Reasonable defaults |
2646 | (@code{default_memory_insert_breakpoint} and | |
2647 | @code{default_memory_remove_breakpoint} respectively) have been | |
2648 | provided so that it is not necessary to define these for most | |
2649 | architectures. Architectures which may want to define | |
56caf160 | 2650 | @code{MEMORY_INSERT_BREAKPOINT} and @code{MEMORY_REMOVE_BREAKPOINT} will |
917317f4 JM |
2651 | likely have instructions that are oddly sized or are not stored in a |
2652 | conventional manner. | |
2653 | ||
2654 | It may also be desirable (from an efficiency standpoint) to define | |
2655 | custom breakpoint insertion and removal routines if | |
56caf160 | 2656 | @code{BREAKPOINT_FROM_PC} needs to read the target's memory for some |
917317f4 JM |
2657 | reason. |
2658 | ||
7a292a7a | 2659 | @item CALL_DUMMY_P |
56caf160 | 2660 | @findex CALL_DUMMY_P |
7a292a7a SS |
2661 | A C expresson that is non-zero when the target suports inferior function |
2662 | calls. | |
2663 | ||
2664 | @item CALL_DUMMY_WORDS | |
56caf160 EZ |
2665 | @findex CALL_DUMMY_WORDS |
2666 | Pointer to an array of @code{LONGEST} words of data containing | |
2667 | host-byte-ordered @code{REGISTER_BYTES} sized values that partially | |
7a292a7a SS |
2668 | specify the sequence of instructions needed for an inferior function |
2669 | call. | |
2670 | ||
56caf160 | 2671 | Should be deprecated in favor of a macro that uses target-byte-ordered |
7a292a7a SS |
2672 | data. |
2673 | ||
2674 | @item SIZEOF_CALL_DUMMY_WORDS | |
56caf160 EZ |
2675 | @findex SIZEOF_CALL_DUMMY_WORDS |
2676 | The size of @code{CALL_DUMMY_WORDS}. When @code{CALL_DUMMY_P} this must | |
2677 | return a positive value. See also @code{CALL_DUMMY_LENGTH}. | |
c906108c SS |
2678 | |
2679 | @item CALL_DUMMY | |
56caf160 EZ |
2680 | @findex CALL_DUMMY |
2681 | A static initializer for @code{CALL_DUMMY_WORDS}. Deprecated. | |
7a292a7a | 2682 | |
c906108c | 2683 | @item CALL_DUMMY_LOCATION |
56caf160 EZ |
2684 | @findex CALL_DUMMY_LOCATION |
2685 | See the file @file{inferior.h}. | |
7a292a7a | 2686 | |
c906108c | 2687 | @item CALL_DUMMY_STACK_ADJUST |
56caf160 | 2688 | @findex CALL_DUMMY_STACK_ADJUST |
7a292a7a SS |
2689 | Stack adjustment needed when performing an inferior function call. |
2690 | ||
56caf160 | 2691 | Should be deprecated in favor of something like @code{STACK_ALIGN}. |
7a292a7a SS |
2692 | |
2693 | @item CALL_DUMMY_STACK_ADJUST_P | |
56caf160 EZ |
2694 | @findex CALL_DUMMY_STACK_ADJUST_P |
2695 | Predicate for use of @code{CALL_DUMMY_STACK_ADJUST}. | |
7a292a7a | 2696 | |
56caf160 | 2697 | Should be deprecated in favor of something like @code{STACK_ALIGN}. |
c906108c | 2698 | |
56caf160 EZ |
2699 | @item CANNOT_FETCH_REGISTER (@var{regno}) |
2700 | @findex CANNOT_FETCH_REGISTER | |
c906108c SS |
2701 | A C expression that should be nonzero if @var{regno} cannot be fetched |
2702 | from an inferior process. This is only relevant if | |
2703 | @code{FETCH_INFERIOR_REGISTERS} is not defined. | |
2704 | ||
56caf160 EZ |
2705 | @item CANNOT_STORE_REGISTER (@var{regno}) |
2706 | @findex CANNOT_STORE_REGISTER | |
c906108c SS |
2707 | A C expression that should be nonzero if @var{regno} should not be |
2708 | written to the target. This is often the case for program counters, | |
56caf160 EZ |
2709 | status words, and other special registers. If this is not defined, |
2710 | @value{GDBN} will assume that all registers may be written. | |
c906108c SS |
2711 | |
2712 | @item DO_DEFERRED_STORES | |
a5d7c491 | 2713 | @itemx CLEAR_DEFERRED_STORES |
56caf160 EZ |
2714 | @findex CLEAR_DEFERRED_STORES |
2715 | @findex DO_DEFERRED_STORES | |
c906108c SS |
2716 | Define this to execute any deferred stores of registers into the inferior, |
2717 | and to cancel any deferred stores. | |
2718 | ||
2719 | Currently only implemented correctly for native Sparc configurations? | |
2720 | ||
ef36d45e | 2721 | @item COERCE_FLOAT_TO_DOUBLE (@var{formal}, @var{actual}) |
56caf160 EZ |
2722 | @findex COERCE_FLOAT_TO_DOUBLE |
2723 | @cindex promotion to @code{double} | |
ef36d45e JB |
2724 | If we are calling a function by hand, and the function was declared |
2725 | (according to the debug info) without a prototype, should we | |
56caf160 EZ |
2726 | automatically promote @code{float}s to @code{double}s? This macro |
2727 | must evaluate to non-zero if we should, or zero if we should leave the | |
2728 | value alone. | |
ef36d45e JB |
2729 | |
2730 | The argument @var{actual} is the type of the value we want to pass to | |
2731 | the function. The argument @var{formal} is the type of this argument, | |
2732 | as it appears in the function's definition. Note that @var{formal} may | |
2733 | be zero if we have no debugging information for the function, or if | |
2734 | we're passing more arguments than are officially declared (for example, | |
2735 | varargs). This macro is never invoked if the function definitely has a | |
2736 | prototype. | |
2737 | ||
56caf160 EZ |
2738 | @findex set_gdbarch_coerce_float_to_double |
2739 | @findex standard_coerce_float_to_double | |
ef36d45e JB |
2740 | The default behavior is to promote only when we have no type information |
2741 | for the formal parameter. This is different from the obvious behavior, | |
2742 | which would be to promote whenever we have no prototype, just as the | |
2743 | compiler does. It's annoying, but some older targets rely on this. If | |
56caf160 EZ |
2744 | you want @value{GDBN} to follow the typical compiler behavior---to always |
2745 | promote when there is no prototype in scope---your gdbarch @code{init} | |
ef36d45e JB |
2746 | function can call @code{set_gdbarch_coerce_float_to_double} and select |
2747 | the @code{standard_coerce_float_to_double} function. | |
2748 | ||
c906108c | 2749 | @item CPLUS_MARKER |
56caf160 EZ |
2750 | @findex CPLUS_MARKERz |
2751 | Define this to expand into the character that G@t{++} uses to distinguish | |
c906108c SS |
2752 | compiler-generated identifiers from programmer-specified identifiers. |
2753 | By default, this expands into @code{'$'}. Most System V targets should | |
2754 | define this to @code{'.'}. | |
2755 | ||
2756 | @item DBX_PARM_SYMBOL_CLASS | |
56caf160 | 2757 | @findex DBX_PARM_SYMBOL_CLASS |
c906108c SS |
2758 | Hook for the @code{SYMBOL_CLASS} of a parameter when decoding DBX symbol |
2759 | information. In the i960, parameters can be stored as locals or as | |
2760 | args, depending on the type of the debug record. | |
2761 | ||
2762 | @item DECR_PC_AFTER_BREAK | |
56caf160 | 2763 | @findex DECR_PC_AFTER_BREAK |
c906108c SS |
2764 | Define this to be the amount by which to decrement the PC after the |
2765 | program encounters a breakpoint. This is often the number of bytes in | |
56caf160 | 2766 | @code{BREAKPOINT}, though not always. For most targets this value will be 0. |
c906108c SS |
2767 | |
2768 | @item DECR_PC_AFTER_HW_BREAK | |
56caf160 | 2769 | @findex DECR_PC_AFTER_HW_BREAK |
c906108c SS |
2770 | Similarly, for hardware breakpoints. |
2771 | ||
56caf160 EZ |
2772 | @item DISABLE_UNSETTABLE_BREAK (@var{addr}) |
2773 | @findex DISABLE_UNSETTABLE_BREAK | |
c906108c SS |
2774 | If defined, this should evaluate to 1 if @var{addr} is in a shared |
2775 | library in which breakpoints cannot be set and so should be disabled. | |
2776 | ||
2777 | @item DO_REGISTERS_INFO | |
56caf160 | 2778 | @findex DO_REGISTERS_INFO |
c906108c SS |
2779 | If defined, use this to print the value of a register or all registers. |
2780 | ||
0dcedd82 | 2781 | @item DWARF_REG_TO_REGNUM |
56caf160 | 2782 | @findex DWARF_REG_TO_REGNUM |
0dcedd82 AC |
2783 | Convert DWARF register number into @value{GDBN} regnum. If not defined, |
2784 | no conversion will be performed. | |
2785 | ||
2786 | @item DWARF2_REG_TO_REGNUM | |
56caf160 | 2787 | @findex DWARF2_REG_TO_REGNUM |
0dcedd82 AC |
2788 | Convert DWARF2 register number into @value{GDBN} regnum. If not |
2789 | defined, no conversion will be performed. | |
2790 | ||
2791 | @item ECOFF_REG_TO_REGNUM | |
56caf160 | 2792 | @findex ECOFF_REG_TO_REGNUM |
0dcedd82 AC |
2793 | Convert ECOFF register number into @value{GDBN} regnum. If not defined, |
2794 | no conversion will be performed. | |
2795 | ||
c906108c | 2796 | @item END_OF_TEXT_DEFAULT |
56caf160 EZ |
2797 | @findex END_OF_TEXT_DEFAULT |
2798 | This is an expression that should designate the end of the text section. | |
2799 | @c (? FIXME ?) | |
c906108c | 2800 | |
56caf160 EZ |
2801 | @item EXTRACT_RETURN_VALUE(@var{type}, @var{regbuf}, @var{valbuf}) |
2802 | @findex EXTRACT_RETURN_VALUE | |
c906108c SS |
2803 | Define this to extract a function's return value of type @var{type} from |
2804 | the raw register state @var{regbuf} and copy that, in virtual format, | |
2805 | into @var{valbuf}. | |
2806 | ||
56caf160 EZ |
2807 | @item EXTRACT_STRUCT_VALUE_ADDRESS(@var{regbuf}) |
2808 | @findex EXTRACT_STRUCT_VALUE_ADDRESS | |
83aa8bc6 AC |
2809 | When defined, extract from the array @var{regbuf} (containing the raw |
2810 | register state) the @code{CORE_ADDR} at which a function should return | |
2811 | its structure value. | |
ac9a91a7 | 2812 | |
83aa8bc6 AC |
2813 | If not defined, @code{EXTRACT_RETURN_VALUE} is used. |
2814 | ||
2815 | @item EXTRACT_STRUCT_VALUE_ADDRESS_P() | |
56caf160 EZ |
2816 | @findex EXTRACT_STRUCT_VALUE_ADDRESS_P |
2817 | Predicate for @code{EXTRACT_STRUCT_VALUE_ADDRESS}. | |
c906108c SS |
2818 | |
2819 | @item FLOAT_INFO | |
56caf160 EZ |
2820 | @findex FLOAT_INFO |
2821 | If defined, then the @samp{info float} command will print information about | |
c906108c SS |
2822 | the processor's floating point unit. |
2823 | ||
2824 | @item FP_REGNUM | |
56caf160 | 2825 | @findex FP_REGNUM |
cce74817 JM |
2826 | If the virtual frame pointer is kept in a register, then define this |
2827 | macro to be the number (greater than or equal to zero) of that register. | |
2828 | ||
2829 | This should only need to be defined if @code{TARGET_READ_FP} and | |
2830 | @code{TARGET_WRITE_FP} are not defined. | |
c906108c | 2831 | |
56caf160 EZ |
2832 | @item FRAMELESS_FUNCTION_INVOCATION(@var{fi}) |
2833 | @findex FRAMELESS_FUNCTION_INVOCATION | |
392a587b JM |
2834 | Define this to an expression that returns 1 if the function invocation |
2835 | represented by @var{fi} does not have a stack frame associated with it. | |
2836 | Otherwise return 0. | |
c906108c | 2837 | |
a5d7c491 | 2838 | @item FRAME_ARGS_ADDRESS_CORRECT |
56caf160 EZ |
2839 | @findex FRAME_ARGS_ADDRESS_CORRECT |
2840 | See @file{stack.c}. | |
c906108c | 2841 | |
56caf160 EZ |
2842 | @item FRAME_CHAIN(@var{frame}) |
2843 | @findex FRAME_CHAIN | |
c906108c SS |
2844 | Given @var{frame}, return a pointer to the calling frame. |
2845 | ||
56caf160 EZ |
2846 | @item FRAME_CHAIN_COMBINE(@var{chain}, @var{frame}) |
2847 | @findex FRAME_CHAIN_COMBINE | |
c906108c SS |
2848 | Define this to take the frame chain pointer and the frame's nominal |
2849 | address and produce the nominal address of the caller's frame. | |
2850 | Presently only defined for HP PA. | |
2851 | ||
56caf160 EZ |
2852 | @item FRAME_CHAIN_VALID(@var{chain}, @var{thisframe}) |
2853 | @findex FRAME_CHAIN_VALID | |
c906108c | 2854 | Define this to be an expression that returns zero if the given frame is |
c4093a6a | 2855 | an outermost frame, with no caller, and nonzero otherwise. Several |
56caf160 | 2856 | common definitions are available: |
c4093a6a | 2857 | |
56caf160 EZ |
2858 | @itemize @bullet |
2859 | @item | |
c4093a6a JM |
2860 | @code{file_frame_chain_valid} is nonzero if the chain pointer is nonzero |
2861 | and given frame's PC is not inside the startup file (such as | |
56caf160 EZ |
2862 | @file{crt0.o}). |
2863 | ||
2864 | @item | |
2865 | @code{func_frame_chain_valid} is nonzero if the chain | |
2866 | pointer is nonzero and the given frame's PC is not in @code{main} or a | |
2867 | known entry point function (such as @code{_start}). | |
2868 | ||
2869 | @item | |
c4093a6a JM |
2870 | @code{generic_file_frame_chain_valid} and |
2871 | @code{generic_func_frame_chain_valid} are equivalent implementations for | |
2872 | targets using generic dummy frames. | |
56caf160 | 2873 | @end itemize |
c906108c | 2874 | |
56caf160 EZ |
2875 | @item FRAME_INIT_SAVED_REGS(@var{frame}) |
2876 | @findex FRAME_INIT_SAVED_REGS | |
c906108c SS |
2877 | See @file{frame.h}. Determines the address of all registers in the |
2878 | current stack frame storing each in @code{frame->saved_regs}. Space for | |
2879 | @code{frame->saved_regs} shall be allocated by | |
2880 | @code{FRAME_INIT_SAVED_REGS} using either | |
2881 | @code{frame_saved_regs_zalloc} or @code{frame_obstack_alloc}. | |
2882 | ||
56caf160 | 2883 | @code{FRAME_FIND_SAVED_REGS} and @code{EXTRA_FRAME_INFO} are deprecated. |
c906108c | 2884 | |
56caf160 EZ |
2885 | @item FRAME_NUM_ARGS (@var{fi}) |
2886 | @findex FRAME_NUM_ARGS | |
392a587b JM |
2887 | For the frame described by @var{fi} return the number of arguments that |
2888 | are being passed. If the number of arguments is not known, return | |
2889 | @code{-1}. | |
c906108c | 2890 | |
56caf160 EZ |
2891 | @item FRAME_SAVED_PC(@var{frame}) |
2892 | @findex FRAME_SAVED_PC | |
2893 | Given @var{frame}, return the pc saved there. This is the return | |
c906108c SS |
2894 | address. |
2895 | ||
2896 | @item FUNCTION_EPILOGUE_SIZE | |
56caf160 | 2897 | @findex FUNCTION_EPILOGUE_SIZE |
c906108c SS |
2898 | For some COFF targets, the @code{x_sym.x_misc.x_fsize} field of the |
2899 | function end symbol is 0. For such targets, you must define | |
2900 | @code{FUNCTION_EPILOGUE_SIZE} to expand into the standard size of a | |
2901 | function's epilogue. | |
2902 | ||
f7cb2b90 | 2903 | @item FUNCTION_START_OFFSET |
56caf160 | 2904 | @findex FUNCTION_START_OFFSET |
f7cb2b90 JB |
2905 | An integer, giving the offset in bytes from a function's address (as |
2906 | used in the values of symbols, function pointers, etc.), and the | |
2907 | function's first genuine instruction. | |
2908 | ||
2909 | This is zero on almost all machines: the function's address is usually | |
2910 | the address of its first instruction. However, on the VAX, for example, | |
2911 | each function starts with two bytes containing a bitmask indicating | |
2912 | which registers to save upon entry to the function. The VAX @code{call} | |
2913 | instructions check this value, and save the appropriate registers | |
2914 | automatically. Thus, since the offset from the function's address to | |
2915 | its first instruction is two bytes, @code{FUNCTION_START_OFFSET} would | |
2916 | be 2 on the VAX. | |
2917 | ||
c906108c | 2918 | @item GCC_COMPILED_FLAG_SYMBOL |
56caf160 EZ |
2919 | @itemx GCC2_COMPILED_FLAG_SYMBOL |
2920 | @findex GCC2_COMPILED_FLAG_SYMBOL | |
2921 | @findex GCC_COMPILED_FLAG_SYMBOL | |
2922 | If defined, these are the names of the symbols that @value{GDBN} will | |
2923 | look for to detect that GCC compiled the file. The default symbols | |
2924 | are @code{gcc_compiled.} and @code{gcc2_compiled.}, | |
2925 | respectively. (Currently only defined for the Delta 68.) | |
c906108c | 2926 | |
25822942 | 2927 | @item @value{GDBN}_MULTI_ARCH |
56caf160 | 2928 | @findex @value{GDBN}_MULTI_ARCH |
0f71a2f6 | 2929 | If defined and non-zero, enables suport for multiple architectures |
25822942 | 2930 | within @value{GDBN}. |
0f71a2f6 | 2931 | |
56caf160 | 2932 | This support can be enabled at two levels. At level one, only |
0f71a2f6 JM |
2933 | definitions for previously undefined macros are provided; at level two, |
2934 | a multi-arch definition of all architecture dependant macros will be | |
2935 | defined. | |
2936 | ||
25822942 | 2937 | @item @value{GDBN}_TARGET_IS_HPPA |
56caf160 EZ |
2938 | @findex @value{GDBN}_TARGET_IS_HPPA |
2939 | This determines whether horrible kludge code in @file{dbxread.c} and | |
2940 | @file{partial-stab.h} is used to mangle multiple-symbol-table files from | |
2941 | HPPA's. This should all be ripped out, and a scheme like @file{elfread.c} | |
2942 | used instead. | |
c906108c | 2943 | |
c906108c | 2944 | @item GET_LONGJMP_TARGET |
56caf160 | 2945 | @findex GET_LONGJMP_TARGET |
c906108c SS |
2946 | For most machines, this is a target-dependent parameter. On the |
2947 | DECstation and the Iris, this is a native-dependent parameter, since | |
56caf160 | 2948 | trhe header file @file{setjmp.h} is needed to define it. |
c906108c | 2949 | |
56caf160 EZ |
2950 | This macro determines the target PC address that @code{longjmp} will jump to, |
2951 | assuming that we have just stopped at a @code{longjmp} breakpoint. It takes a | |
2952 | @code{CORE_ADDR *} as argument, and stores the target PC value through this | |
c906108c SS |
2953 | pointer. It examines the current state of the machine as needed. |
2954 | ||
2955 | @item GET_SAVED_REGISTER | |
56caf160 EZ |
2956 | @findex GET_SAVED_REGISTER |
2957 | @findex get_saved_register | |
c906108c | 2958 | Define this if you need to supply your own definition for the function |
7a292a7a | 2959 | @code{get_saved_register}. |
c906108c SS |
2960 | |
2961 | @item HAVE_REGISTER_WINDOWS | |
56caf160 | 2962 | @findex HAVE_REGISTER_WINDOWS |
c906108c | 2963 | Define this if the target has register windows. |
56caf160 EZ |
2964 | |
2965 | @item REGISTER_IN_WINDOW_P (@var{regnum}) | |
2966 | @findex REGISTER_IN_WINDOW_P | |
c906108c SS |
2967 | Define this to be an expression that is 1 if the given register is in |
2968 | the window. | |
2969 | ||
2970 | @item IBM6000_TARGET | |
56caf160 | 2971 | @findex IBM6000_TARGET |
c906108c SS |
2972 | Shows that we are configured for an IBM RS/6000 target. This |
2973 | conditional should be eliminated (FIXME) and replaced by | |
56caf160 | 2974 | feature-specific macros. It was introduced in a haste and we are |
c906108c SS |
2975 | repenting at leisure. |
2976 | ||
9742079a EZ |
2977 | @item I386_USE_GENERIC_WATCHPOINTS |
2978 | An x86-based target can define this to use the generic x86 watchpoint | |
2979 | support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}. | |
2980 | ||
2df3850c | 2981 | @item SYMBOLS_CAN_START_WITH_DOLLAR |
56caf160 | 2982 | @findex SYMBOLS_CAN_START_WITH_DOLLAR |
2df3850c | 2983 | Some systems have routines whose names start with @samp{$}. Giving this |
25822942 | 2984 | macro a non-zero value tells @value{GDBN}'s expression parser to check for such |
2df3850c JM |
2985 | routines when parsing tokens that begin with @samp{$}. |
2986 | ||
2987 | On HP-UX, certain system routines (millicode) have names beginning with | |
2988 | @samp{$} or @samp{$$}. For example, @code{$$dyncall} is a millicode | |
2989 | routine that handles inter-space procedure calls on PA-RISC. | |
2990 | ||
c906108c | 2991 | @item IEEE_FLOAT |
56caf160 | 2992 | @findex IEEE_FLOAT |
c906108c SS |
2993 | Define this if the target system uses IEEE-format floating point numbers. |
2994 | ||
56caf160 EZ |
2995 | @item INIT_EXTRA_FRAME_INFO (@var{fromleaf}, @var{frame}) |
2996 | @findex INIT_EXTRA_FRAME_INFO | |
c906108c SS |
2997 | If additional information about the frame is required this should be |
2998 | stored in @code{frame->extra_info}. Space for @code{frame->extra_info} | |
2999 | is allocated using @code{frame_obstack_alloc}. | |
3000 | ||
56caf160 EZ |
3001 | @item INIT_FRAME_PC (@var{fromleaf}, @var{prev}) |
3002 | @findex INIT_FRAME_PC | |
c906108c SS |
3003 | This is a C statement that sets the pc of the frame pointed to by |
3004 | @var{prev}. [By default...] | |
3005 | ||
56caf160 EZ |
3006 | @item INNER_THAN (@var{lhs}, @var{rhs}) |
3007 | @findex INNER_THAN | |
c906108c SS |
3008 | Returns non-zero if stack address @var{lhs} is inner than (nearer to the |
3009 | stack top) stack address @var{rhs}. Define this as @code{lhs < rhs} if | |
3010 | the target's stack grows downward in memory, or @code{lhs > rsh} if the | |
3011 | stack grows upward. | |
3012 | ||
56caf160 EZ |
3013 | @item IN_SIGTRAMP (@var{pc}, @var{name}) |
3014 | @findex IN_SIGTRAMP | |
3015 | Define this to return non-zero if the given @var{pc} and/or @var{name} | |
3016 | indicates that the current function is a @code{sigtramp}. | |
c906108c | 3017 | |
56caf160 EZ |
3018 | @item SIGTRAMP_START (@var{pc}) |
3019 | @findex SIGTRAMP_START | |
3020 | @itemx SIGTRAMP_END (@var{pc}) | |
3021 | @findex SIGTRAMP_END | |
3022 | Define these to be the start and end address of the @code{sigtramp} for the | |
c906108c SS |
3023 | given @var{pc}. On machines where the address is just a compile time |
3024 | constant, the macro expansion will typically just ignore the supplied | |
3025 | @var{pc}. | |
3026 | ||
56caf160 EZ |
3027 | @item IN_SOLIB_CALL_TRAMPOLINE (@var{pc}, @var{name}) |
3028 | @findex IN_SOLIB_CALL_TRAMPOLINE | |
c906108c SS |
3029 | Define this to evaluate to nonzero if the program is stopped in the |
3030 | trampoline that connects to a shared library. | |
3031 | ||
56caf160 EZ |
3032 | @item IN_SOLIB_RETURN_TRAMPOLINE (@var{pc}, @var{name}) |
3033 | @findex IN_SOLIB_RETURN_TRAMPOLINE | |
c906108c SS |
3034 | Define this to evaluate to nonzero if the program is stopped in the |
3035 | trampoline that returns from a shared library. | |
3036 | ||
56caf160 EZ |
3037 | @item IN_SOLIB_DYNSYM_RESOLVE_CODE (@var{pc}) |
3038 | @findex IN_SOLIB_DYNSYM_RESOLVE_CODE | |
d4f3574e SS |
3039 | Define this to evaluate to nonzero if the program is stopped in the |
3040 | dynamic linker. | |
3041 | ||
56caf160 EZ |
3042 | @item SKIP_SOLIB_RESOLVER (@var{pc}) |
3043 | @findex SKIP_SOLIB_RESOLVER | |
d4f3574e SS |
3044 | Define this to evaluate to the (nonzero) address at which execution |
3045 | should continue to get past the dynamic linker's symbol resolution | |
3046 | function. A zero value indicates that it is not important or necessary | |
3047 | to set a breakpoint to get through the dynamic linker and that single | |
3048 | stepping will suffice. | |
3049 | ||
56caf160 EZ |
3050 | @item IS_TRAPPED_INTERNALVAR (@var{name}) |
3051 | @findex IS_TRAPPED_INTERNALVAR | |
c906108c SS |
3052 | This is an ugly hook to allow the specification of special actions that |
3053 | should occur as a side-effect of setting the value of a variable | |
25822942 | 3054 | internal to @value{GDBN}. Currently only used by the h8500. Note that this |
c906108c SS |
3055 | could be either a host or target conditional. |
3056 | ||
3057 | @item NEED_TEXT_START_END | |
56caf160 | 3058 | @findex NEED_TEXT_START_END |
25822942 | 3059 | Define this if @value{GDBN} should determine the start and end addresses of the |
c906108c SS |
3060 | text section. (Seems dubious.) |
3061 | ||
3062 | @item NO_HIF_SUPPORT | |
56caf160 | 3063 | @findex NO_HIF_SUPPORT |
c906108c SS |
3064 | (Specific to the a29k.) |
3065 | ||
93e79dbd | 3066 | @item POINTER_TO_ADDRESS (@var{type}, @var{buf}) |
56caf160 | 3067 | @findex POINTER_TO_ADDRESS |
93e79dbd JB |
3068 | Assume that @var{buf} holds a pointer of type @var{type}, in the |
3069 | appropriate format for the current architecture. Return the byte | |
3070 | address the pointer refers to. | |
3071 | @xref{Target Architecture Definition, , Pointers Are Not Always Addresses}. | |
3072 | ||
9fb4dd36 | 3073 | @item REGISTER_CONVERTIBLE (@var{reg}) |
56caf160 | 3074 | @findex REGISTER_CONVERTIBLE |
9fb4dd36 | 3075 | Return non-zero if @var{reg} uses different raw and virtual formats. |
4281a42e | 3076 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
9fb4dd36 JB |
3077 | |
3078 | @item REGISTER_RAW_SIZE (@var{reg}) | |
56caf160 | 3079 | @findex REGISTER_RAW_SIZE |
9fb4dd36 | 3080 | Return the raw size of @var{reg}. |
4281a42e | 3081 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
9fb4dd36 JB |
3082 | |
3083 | @item REGISTER_VIRTUAL_SIZE (@var{reg}) | |
56caf160 | 3084 | @findex REGISTER_VIRTUAL_SIZE |
9fb4dd36 | 3085 | Return the virtual size of @var{reg}. |
4281a42e | 3086 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
9fb4dd36 JB |
3087 | |
3088 | @item REGISTER_VIRTUAL_TYPE (@var{reg}) | |
56caf160 | 3089 | @findex REGISTER_VIRTUAL_TYPE |
9fb4dd36 | 3090 | Return the virtual type of @var{reg}. |
4281a42e | 3091 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. |
9fb4dd36 JB |
3092 | |
3093 | @item REGISTER_CONVERT_TO_VIRTUAL(@var{reg}, @var{type}, @var{from}, @var{to}) | |
56caf160 | 3094 | @findex REGISTER_CONVERT_TO_VIRTUAL |
9fb4dd36 | 3095 | Convert the value of register @var{reg} from its raw form to its virtual |
4281a42e JB |
3096 | form. |
3097 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. | |
9fb4dd36 JB |
3098 | |
3099 | @item REGISTER_CONVERT_TO_RAW(@var{type}, @var{reg}, @var{from}, @var{to}) | |
56caf160 | 3100 | @findex REGISTER_CONVERT_TO_RAW |
9fb4dd36 | 3101 | Convert the value of register @var{reg} from its virtual form to its raw |
4281a42e JB |
3102 | form. |
3103 | @xref{Target Architecture Definition, , Using Different Register and Memory Data Representations}. | |
9fb4dd36 | 3104 | |
e5419804 JB |
3105 | @item RETURN_VALUE_ON_STACK(@var{type}) |
3106 | @findex RETURN_VALUE_ON_STACK | |
3107 | @cindex returning structures by value | |
3108 | @cindex structures, returning by value | |
3109 | ||
3110 | Return non-zero if values of type TYPE are returned on the stack, using | |
3111 | the ``struct convention'' (i.e., the caller provides a pointer to a | |
3112 | buffer in which the callee should store the return value). This | |
3113 | controls how the @samp{finish} command finds a function's return value, | |
3114 | and whether an inferior function call reserves space on the stack for | |
3115 | the return value. | |
3116 | ||
3117 | The full logic @value{GDBN} uses here is kind of odd. | |
e5419804 | 3118 | |
56caf160 | 3119 | @itemize @bullet |
e5419804 JB |
3120 | @item |
3121 | If the type being returned by value is not a structure, union, or array, | |
3122 | and @code{RETURN_VALUE_ON_STACK} returns zero, then @value{GDBN} | |
3123 | concludes the value is not returned using the struct convention. | |
3124 | ||
3125 | @item | |
3126 | Otherwise, @value{GDBN} calls @code{USE_STRUCT_CONVENTION} (see below). | |
3127 | If that returns non-zero, @value{GDBN} assumes the struct convention is | |
3128 | in use. | |
e5419804 JB |
3129 | @end itemize |
3130 | ||
3131 | In other words, to indicate that a given type is returned by value using | |
3132 | the struct convention, that type must be either a struct, union, array, | |
3133 | or something @code{RETURN_VALUE_ON_STACK} likes, @emph{and} something | |
3134 | that @code{USE_STRUCT_CONVENTION} likes. | |
3135 | ||
56caf160 | 3136 | Note that, in C and C@t{++}, arrays are never returned by value. In those |
e5419804 JB |
3137 | languages, these predicates will always see a pointer type, never an |
3138 | array type. All the references above to arrays being returned by value | |
3139 | apply only to other languages. | |
3140 | ||
b0ed3589 | 3141 | @item SOFTWARE_SINGLE_STEP_P() |
56caf160 | 3142 | @findex SOFTWARE_SINGLE_STEP_P |
c906108c | 3143 | Define this as 1 if the target does not have a hardware single-step |
56caf160 | 3144 | mechanism. The macro @code{SOFTWARE_SINGLE_STEP} must also be defined. |
c906108c | 3145 | |
56caf160 EZ |
3146 | @item SOFTWARE_SINGLE_STEP(@var{signal}, @var{insert_breapoints_p}) |
3147 | @findex SOFTWARE_SINGLE_STEP | |
3148 | A function that inserts or removes (depending on | |
c906108c | 3149 | @var{insert_breapoints_p}) breakpoints at each possible destinations of |
56caf160 | 3150 | the next instruction. See @file{sparc-tdep.c} and @file{rs6000-tdep.c} |
c906108c SS |
3151 | for examples. |
3152 | ||
da59e081 | 3153 | @item SOFUN_ADDRESS_MAYBE_MISSING |
56caf160 | 3154 | @findex SOFUN_ADDRESS_MAYBE_MISSING |
da59e081 JM |
3155 | Somebody clever observed that, the more actual addresses you have in the |
3156 | debug information, the more time the linker has to spend relocating | |
3157 | them. So whenever there's some other way the debugger could find the | |
3158 | address it needs, you should omit it from the debug info, to make | |
3159 | linking faster. | |
3160 | ||
3161 | @code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of | |
3162 | hacks of this sort are in use, affecting @code{N_SO} and @code{N_FUN} | |
3163 | entries in stabs-format debugging information. @code{N_SO} stabs mark | |
3164 | the beginning and ending addresses of compilation units in the text | |
3165 | segment. @code{N_FUN} stabs mark the starts and ends of functions. | |
3166 | ||
3167 | @code{SOFUN_ADDRESS_MAYBE_MISSING} means two things: | |
da59e081 | 3168 | |
56caf160 | 3169 | @itemize @bullet |
da59e081 JM |
3170 | @item |
3171 | @code{N_FUN} stabs have an address of zero. Instead, you should find the | |
3172 | addresses where the function starts by taking the function name from | |
56caf160 EZ |
3173 | the stab, and then looking that up in the minsyms (the |
3174 | linker/assembler symbol table). In other words, the stab has the | |
3175 | name, and the linker/assembler symbol table is the only place that carries | |
da59e081 JM |
3176 | the address. |
3177 | ||
3178 | @item | |
3179 | @code{N_SO} stabs have an address of zero, too. You just look at the | |
3180 | @code{N_FUN} stabs that appear before and after the @code{N_SO} stab, | |
3181 | and guess the starting and ending addresses of the compilation unit from | |
3182 | them. | |
da59e081 JM |
3183 | @end itemize |
3184 | ||
c906108c | 3185 | @item PCC_SOL_BROKEN |
56caf160 | 3186 | @findex PCC_SOL_BROKEN |
c906108c SS |
3187 | (Used only in the Convex target.) |
3188 | ||
3189 | @item PC_IN_CALL_DUMMY | |
56caf160 EZ |
3190 | @findex PC_IN_CALL_DUMMY |
3191 | See @file{inferior.h}. | |
c906108c SS |
3192 | |
3193 | @item PC_LOAD_SEGMENT | |
56caf160 | 3194 | @findex PC_LOAD_SEGMENT |
c906108c SS |
3195 | If defined, print information about the load segment for the program |
3196 | counter. (Defined only for the RS/6000.) | |
3197 | ||
3198 | @item PC_REGNUM | |
56caf160 | 3199 | @findex PC_REGNUM |
c906108c | 3200 | If the program counter is kept in a register, then define this macro to |
cce74817 JM |
3201 | be the number (greater than or equal to zero) of that register. |
3202 | ||
3203 | This should only need to be defined if @code{TARGET_READ_PC} and | |
3204 | @code{TARGET_WRITE_PC} are not defined. | |
c906108c SS |
3205 | |
3206 | @item NPC_REGNUM | |
56caf160 | 3207 | @findex NPC_REGNUM |
c906108c SS |
3208 | The number of the ``next program counter'' register, if defined. |
3209 | ||
3210 | @item NNPC_REGNUM | |
56caf160 | 3211 | @findex NNPC_REGNUM |
c906108c SS |
3212 | The number of the ``next next program counter'' register, if defined. |
3213 | Currently, this is only defined for the Motorola 88K. | |
3214 | ||
2df3850c | 3215 | @item PARM_BOUNDARY |
56caf160 | 3216 | @findex PARM_BOUNDARY |
2df3850c JM |
3217 | If non-zero, round arguments to a boundary of this many bits before |
3218 | pushing them on the stack. | |
3219 | ||
56caf160 EZ |
3220 | @item PRINT_REGISTER_HOOK (@var{regno}) |
3221 | @findex PRINT_REGISTER_HOOK | |
c906108c SS |
3222 | If defined, this must be a function that prints the contents of the |
3223 | given register to standard output. | |
3224 | ||
3225 | @item PRINT_TYPELESS_INTEGER | |
56caf160 | 3226 | @findex PRINT_TYPELESS_INTEGER |
c906108c SS |
3227 | This is an obscure substitute for @code{print_longest} that seems to |
3228 | have been defined for the Convex target. | |
3229 | ||
3230 | @item PROCESS_LINENUMBER_HOOK | |
56caf160 | 3231 | @findex PROCESS_LINENUMBER_HOOK |
c906108c SS |
3232 | A hook defined for XCOFF reading. |
3233 | ||
3234 | @item PROLOGUE_FIRSTLINE_OVERLAP | |
56caf160 | 3235 | @findex PROLOGUE_FIRSTLINE_OVERLAP |
c906108c SS |
3236 | (Only used in unsupported Convex configuration.) |
3237 | ||
3238 | @item PS_REGNUM | |
56caf160 | 3239 | @findex PS_REGNUM |
c906108c SS |
3240 | If defined, this is the number of the processor status register. (This |
3241 | definition is only used in generic code when parsing "$ps".) | |
3242 | ||
3243 | @item POP_FRAME | |
56caf160 EZ |
3244 | @findex POP_FRAME |
3245 | @findex call_function_by_hand | |
3246 | @findex return_command | |
c906108c | 3247 | Used in @samp{call_function_by_hand} to remove an artificial stack |
1c6147de | 3248 | frame and in @samp{return_command} to remove a real stack frame. |
c906108c | 3249 | |
56caf160 EZ |
3250 | @item PUSH_ARGUMENTS (@var{nargs}, @var{args}, @var{sp}, @var{struct_return}, @var{struct_addr}) |
3251 | @findex PUSH_ARGUMENTS | |
392a587b | 3252 | Define this to push arguments onto the stack for inferior function |
56caf160 | 3253 | call. Returns the updated stack pointer value. |
c906108c SS |
3254 | |
3255 | @item PUSH_DUMMY_FRAME | |
56caf160 | 3256 | @findex PUSH_DUMMY_FRAME |
c906108c SS |
3257 | Used in @samp{call_function_by_hand} to create an artificial stack frame. |
3258 | ||
3259 | @item REGISTER_BYTES | |
56caf160 | 3260 | @findex REGISTER_BYTES |
25822942 | 3261 | The total amount of space needed to store @value{GDBN}'s copy of the machine's |
c906108c SS |
3262 | register state. |
3263 | ||
56caf160 EZ |
3264 | @item REGISTER_NAME(@var{i}) |
3265 | @findex REGISTER_NAME | |
3266 | Return the name of register @var{i} as a string. May return @code{NULL} | |
3267 | or @code{NUL} to indicate that register @var{i} is not valid. | |
c906108c | 3268 | |
7a292a7a | 3269 | @item REGISTER_NAMES |
56caf160 EZ |
3270 | @findex REGISTER_NAMES |
3271 | Deprecated in favor of @code{REGISTER_NAME}. | |
7a292a7a | 3272 | |
56caf160 EZ |
3273 | @item REG_STRUCT_HAS_ADDR (@var{gcc_p}, @var{type}) |
3274 | @findex REG_STRUCT_HAS_ADDR | |
c906108c SS |
3275 | Define this to return 1 if the given type will be passed by pointer |
3276 | rather than directly. | |
3277 | ||
56caf160 EZ |
3278 | @item SAVE_DUMMY_FRAME_TOS (@var{sp}) |
3279 | @findex SAVE_DUMMY_FRAME_TOS | |
43ff13b4 JM |
3280 | Used in @samp{call_function_by_hand} to notify the target dependent code |
3281 | of the top-of-stack value that will be passed to the the inferior code. | |
56caf160 | 3282 | This is the value of the @code{SP} after both the dummy frame and space |
43ff13b4 JM |
3283 | for parameters/results have been allocated on the stack. |
3284 | ||
c906108c | 3285 | @item SDB_REG_TO_REGNUM |
56caf160 | 3286 | @findex SDB_REG_TO_REGNUM |
25822942 | 3287 | Define this to convert sdb register numbers into @value{GDBN} regnums. If not |
c906108c SS |
3288 | defined, no conversion will be done. |
3289 | ||
3290 | @item SHIFT_INST_REGS | |
56caf160 | 3291 | @findex SHIFT_INST_REGS |
c906108c SS |
3292 | (Only used for m88k targets.) |
3293 | ||
c2c6d25f | 3294 | @item SKIP_PERMANENT_BREAKPOINT |
56caf160 | 3295 | @findex SKIP_PERMANENT_BREAKPOINT |
25822942 | 3296 | Advance the inferior's PC past a permanent breakpoint. @value{GDBN} normally |
c2c6d25f JM |
3297 | steps over a breakpoint by removing it, stepping one instruction, and |
3298 | re-inserting the breakpoint. However, permanent breakpoints are | |
3299 | hardwired into the inferior, and can't be removed, so this strategy | |
56caf160 | 3300 | doesn't work. Calling @code{SKIP_PERMANENT_BREAKPOINT} adjusts the processor's |
c2c6d25f JM |
3301 | state so that execution will resume just after the breakpoint. This |
3302 | macro does the right thing even when the breakpoint is in the delay slot | |
3303 | of a branch or jump. | |
3304 | ||
56caf160 EZ |
3305 | @item SKIP_PROLOGUE (@var{pc}) |
3306 | @findex SKIP_PROLOGUE | |
b83266a0 SS |
3307 | A C expression that returns the address of the ``real'' code beyond the |
3308 | function entry prologue found at @var{pc}. | |
c906108c SS |
3309 | |
3310 | @item SKIP_PROLOGUE_FRAMELESS_P | |
56caf160 | 3311 | @findex SKIP_PROLOGUE_FRAMELESS_P |
b83266a0 SS |
3312 | A C expression that should behave similarly, but that can stop as soon |
3313 | as the function is known to have a frame. If not defined, | |
c906108c SS |
3314 | @code{SKIP_PROLOGUE} will be used instead. |
3315 | ||
56caf160 EZ |
3316 | @item SKIP_TRAMPOLINE_CODE (@var{pc}) |
3317 | @findex SKIP_TRAMPOLINE_CODE | |
c906108c SS |
3318 | If the target machine has trampoline code that sits between callers and |
3319 | the functions being called, then define this macro to return a new PC | |
3320 | that is at the start of the real function. | |
3321 | ||
3322 | @item SP_REGNUM | |
56caf160 | 3323 | @findex SP_REGNUM |
cce74817 JM |
3324 | If the stack-pointer is kept in a register, then define this macro to be |
3325 | the number (greater than or equal to zero) of that register. | |
3326 | ||
3327 | This should only need to be defined if @code{TARGET_WRITE_SP} and | |
3328 | @code{TARGET_WRITE_SP} are not defined. | |
c906108c SS |
3329 | |
3330 | @item STAB_REG_TO_REGNUM | |
56caf160 | 3331 | @findex STAB_REG_TO_REGNUM |
c906108c | 3332 | Define this to convert stab register numbers (as gotten from `r' |
25822942 | 3333 | declarations) into @value{GDBN} regnums. If not defined, no conversion will be |
c906108c SS |
3334 | done. |
3335 | ||
56caf160 EZ |
3336 | @item STACK_ALIGN (@var{addr}) |
3337 | @findex STACK_ALIGN | |
c906108c SS |
3338 | Define this to adjust the address to the alignment required for the |
3339 | processor's stack. | |
3340 | ||
56caf160 EZ |
3341 | @item STEP_SKIPS_DELAY (@var{addr}) |
3342 | @findex STEP_SKIPS_DELAY | |
c906108c SS |
3343 | Define this to return true if the address is of an instruction with a |
3344 | delay slot. If a breakpoint has been placed in the instruction's delay | |
25822942 | 3345 | slot, @value{GDBN} will single-step over that instruction before resuming |
c906108c SS |
3346 | normally. Currently only defined for the Mips. |
3347 | ||
56caf160 EZ |
3348 | @item STORE_RETURN_VALUE (@var{type}, @var{valbuf}) |
3349 | @findex STORE_RETURN_VALUE | |
c906108c SS |
3350 | A C expression that stores a function return value of type @var{type}, |
3351 | where @var{valbuf} is the address of the value to be stored. | |
3352 | ||
3353 | @item SUN_FIXED_LBRAC_BUG | |
56caf160 | 3354 | @findex SUN_FIXED_LBRAC_BUG |
c906108c SS |
3355 | (Used only for Sun-3 and Sun-4 targets.) |
3356 | ||
3357 | @item SYMBOL_RELOADING_DEFAULT | |
56caf160 EZ |
3358 | @findex SYMBOL_RELOADING_DEFAULT |
3359 | The default value of the ``symbol-reloading'' variable. (Never defined in | |
c906108c SS |
3360 | current sources.) |
3361 | ||
3362 | @item TARGET_BYTE_ORDER_DEFAULT | |
56caf160 | 3363 | @findex TARGET_BYTE_ORDER_DEFAULT |
c906108c SS |
3364 | The ordering of bytes in the target. This must be either |
3365 | @code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}. This macro replaces | |
56caf160 | 3366 | @code{TARGET_BYTE_ORDER} which is deprecated. |
c906108c SS |
3367 | |
3368 | @item TARGET_BYTE_ORDER_SELECTABLE_P | |
56caf160 | 3369 | @findex TARGET_BYTE_ORDER_SELECTABLE_P |
c906108c SS |
3370 | Non-zero if the target has both @code{BIG_ENDIAN} and |
3371 | @code{LITTLE_ENDIAN} variants. This macro replaces | |
56caf160 | 3372 | @code{TARGET_BYTE_ORDER_SELECTABLE} which is deprecated. |
c906108c SS |
3373 | |
3374 | @item TARGET_CHAR_BIT | |
56caf160 | 3375 | @findex TARGET_CHAR_BIT |
c906108c SS |
3376 | Number of bits in a char; defaults to 8. |
3377 | ||
3378 | @item TARGET_COMPLEX_BIT | |
56caf160 | 3379 | @findex TARGET_COMPLEX_BIT |
c906108c SS |
3380 | Number of bits in a complex number; defaults to @code{2 * TARGET_FLOAT_BIT}. |
3381 | ||
ac9a91a7 JM |
3382 | At present this macro is not used. |
3383 | ||
c906108c | 3384 | @item TARGET_DOUBLE_BIT |
56caf160 | 3385 | @findex TARGET_DOUBLE_BIT |
c906108c SS |
3386 | Number of bits in a double float; defaults to @code{8 * TARGET_CHAR_BIT}. |
3387 | ||
3388 | @item TARGET_DOUBLE_COMPLEX_BIT | |
56caf160 | 3389 | @findex TARGET_DOUBLE_COMPLEX_BIT |
c906108c SS |
3390 | Number of bits in a double complex; defaults to @code{2 * TARGET_DOUBLE_BIT}. |
3391 | ||
ac9a91a7 JM |
3392 | At present this macro is not used. |
3393 | ||
c906108c | 3394 | @item TARGET_FLOAT_BIT |
56caf160 | 3395 | @findex TARGET_FLOAT_BIT |
c906108c SS |
3396 | Number of bits in a float; defaults to @code{4 * TARGET_CHAR_BIT}. |
3397 | ||
3398 | @item TARGET_INT_BIT | |
56caf160 | 3399 | @findex TARGET_INT_BIT |
c906108c SS |
3400 | Number of bits in an integer; defaults to @code{4 * TARGET_CHAR_BIT}. |
3401 | ||
3402 | @item TARGET_LONG_BIT | |
56caf160 | 3403 | @findex TARGET_LONG_BIT |
c906108c SS |
3404 | Number of bits in a long integer; defaults to @code{4 * TARGET_CHAR_BIT}. |
3405 | ||
3406 | @item TARGET_LONG_DOUBLE_BIT | |
56caf160 | 3407 | @findex TARGET_LONG_DOUBLE_BIT |
c906108c SS |
3408 | Number of bits in a long double float; |
3409 | defaults to @code{2 * TARGET_DOUBLE_BIT}. | |
3410 | ||
3411 | @item TARGET_LONG_LONG_BIT | |
56caf160 | 3412 | @findex TARGET_LONG_LONG_BIT |
c906108c SS |
3413 | Number of bits in a long long integer; defaults to @code{2 * TARGET_LONG_BIT}. |
3414 | ||
3415 | @item TARGET_PTR_BIT | |
56caf160 | 3416 | @findex TARGET_PTR_BIT |
c906108c SS |
3417 | Number of bits in a pointer; defaults to @code{TARGET_INT_BIT}. |
3418 | ||
3419 | @item TARGET_SHORT_BIT | |
56caf160 | 3420 | @findex TARGET_SHORT_BIT |
c906108c SS |
3421 | Number of bits in a short integer; defaults to @code{2 * TARGET_CHAR_BIT}. |
3422 | ||
3423 | @item TARGET_READ_PC | |
56caf160 EZ |
3424 | @findex TARGET_READ_PC |
3425 | @itemx TARGET_WRITE_PC (@var{val}, @var{pid}) | |
3426 | @findex TARGET_WRITE_PC | |
3427 | @itemx TARGET_READ_SP | |
3428 | @findex TARGET_READ_SP | |
3429 | @itemx TARGET_WRITE_SP | |
3430 | @findex TARGET_WRITE_SP | |
3431 | @itemx TARGET_READ_FP | |
3432 | @findex TARGET_READ_FP | |
3433 | @itemx TARGET_WRITE_FP | |
3434 | @findex TARGET_WRITE_FP | |
3435 | @findex read_pc | |
3436 | @findex write_pc | |
3437 | @findex read_sp | |
3438 | @findex write_sp | |
3439 | @findex read_fp | |
3440 | @findex write_fp | |
c906108c SS |
3441 | These change the behavior of @code{read_pc}, @code{write_pc}, |
3442 | @code{read_sp}, @code{write_sp}, @code{read_fp} and @code{write_fp}. | |
25822942 | 3443 | For most targets, these may be left undefined. @value{GDBN} will call the read |
c906108c SS |
3444 | and write register functions with the relevant @code{_REGNUM} argument. |
3445 | ||
3446 | These macros are useful when a target keeps one of these registers in a | |
3447 | hard to get at place; for example, part in a segment register and part | |
3448 | in an ordinary register. | |
3449 | ||
56caf160 EZ |
3450 | @item TARGET_VIRTUAL_FRAME_POINTER(@var{pc}, @var{regp}, @var{offsetp}) |
3451 | @findex TARGET_VIRTUAL_FRAME_POINTER | |
c906108c | 3452 | Returns a @code{(register, offset)} pair representing the virtual |
56caf160 | 3453 | frame pointer in use at the code address @var{pc}. If virtual |
c906108c SS |
3454 | frame pointers are not used, a default definition simply returns |
3455 | @code{FP_REGNUM}, with an offset of zero. | |
3456 | ||
9742079a EZ |
3457 | @item TARGET_HAS_HARDWARE_WATCHPOINTS |
3458 | If non-zero, the target has support for hardware-assisted | |
3459 | watchpoints. @xref{Algorithms, watchpoints}, for more details and | |
3460 | other related macros. | |
3461 | ||
56caf160 EZ |
3462 | @item USE_STRUCT_CONVENTION (@var{gcc_p}, @var{type}) |
3463 | @findex USE_STRUCT_CONVENTION | |
c906108c SS |
3464 | If defined, this must be an expression that is nonzero if a value of the |
3465 | given @var{type} being returned from a function must have space | |
3466 | allocated for it on the stack. @var{gcc_p} is true if the function | |
3467 | being considered is known to have been compiled by GCC; this is helpful | |
3468 | for systems where GCC is known to use different calling convention than | |
3469 | other compilers. | |
3470 | ||
56caf160 EZ |
3471 | @item VARIABLES_INSIDE_BLOCK (@var{desc}, @var{gcc_p}) |
3472 | @findex VARIABLES_INSIDE_BLOCK | |
c906108c SS |
3473 | For dbx-style debugging information, if the compiler puts variable |
3474 | declarations inside LBRAC/RBRAC blocks, this should be defined to be | |
3475 | nonzero. @var{desc} is the value of @code{n_desc} from the | |
25822942 | 3476 | @code{N_RBRAC} symbol, and @var{gcc_p} is true if @value{GDBN} has noticed the |
c906108c SS |
3477 | presence of either the @code{GCC_COMPILED_SYMBOL} or the |
3478 | @code{GCC2_COMPILED_SYMBOL}. By default, this is 0. | |
3479 | ||
56caf160 EZ |
3480 | @item OS9K_VARIABLES_INSIDE_BLOCK (@var{desc}, @var{gcc_p}) |
3481 | @findex OS9K_VARIABLES_INSIDE_BLOCK | |
c906108c | 3482 | Similarly, for OS/9000. Defaults to 1. |
c906108c SS |
3483 | @end table |
3484 | ||
3485 | Motorola M68K target conditionals. | |
3486 | ||
56caf160 | 3487 | @ftable @code |
c906108c SS |
3488 | @item BPT_VECTOR |
3489 | Define this to be the 4-bit location of the breakpoint trap vector. If | |
3490 | not defined, it will default to @code{0xf}. | |
3491 | ||
3492 | @item REMOTE_BPT_VECTOR | |
3493 | Defaults to @code{1}. | |
56caf160 | 3494 | @end ftable |
c906108c SS |
3495 | |
3496 | @section Adding a New Target | |
3497 | ||
56caf160 | 3498 | @cindex adding a target |
af6c57ea | 3499 | The following files add a target to @value{GDBN}: |
c906108c SS |
3500 | |
3501 | @table @file | |
56caf160 | 3502 | @vindex TDEPFILES |
c906108c SS |
3503 | @item gdb/config/@var{arch}/@var{ttt}.mt |
3504 | Contains a Makefile fragment specific to this target. Specifies what | |
3505 | object files are needed for target @var{ttt}, by defining | |
104c1213 JM |
3506 | @samp{TDEPFILES=@dots{}} and @samp{TDEPLIBS=@dots{}}. Also specifies |
3507 | the header file which describes @var{ttt}, by defining @samp{TM_FILE= | |
3508 | tm-@var{ttt}.h}. | |
3509 | ||
3510 | You can also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, @samp{TM_CDEPS}, | |
3511 | but these are now deprecated, replaced by autoconf, and may go away in | |
25822942 | 3512 | future versions of @value{GDBN}. |
c906108c | 3513 | |
c906108c SS |
3514 | @item gdb/@var{ttt}-tdep.c |
3515 | Contains any miscellaneous code required for this target machine. On | |
3516 | some machines it doesn't exist at all. Sometimes the macros in | |
3517 | @file{tm-@var{ttt}.h} become very complicated, so they are implemented | |
3518 | as functions here instead, and the macro is simply defined to call the | |
3519 | function. This is vastly preferable, since it is easier to understand | |
3520 | and debug. | |
3521 | ||
af6c57ea AC |
3522 | @item gdb/@var{arch}-tdep.c |
3523 | @itemx gdb/@var{arch}-tdep.h | |
3524 | This often exists to describe the basic layout of the target machine's | |
3525 | processor chip (registers, stack, etc.). If used, it is included by | |
3526 | @file{@var{ttt}-tdep.h}. It can be shared among many targets that use | |
3527 | the same processor. | |
3528 | ||
3529 | @item gdb/config/@var{arch}/tm-@var{ttt}.h | |
3530 | (@file{tm.h} is a link to this file, created by @code{configure}). Contains | |
3531 | macro definitions about the target machine's registers, stack frame | |
3532 | format and instructions. | |
3533 | ||
3534 | New targets do not need this file and should not create it. | |
3535 | ||
c906108c SS |
3536 | @item gdb/config/@var{arch}/tm-@var{arch}.h |
3537 | This often exists to describe the basic layout of the target machine's | |
56caf160 | 3538 | processor chip (registers, stack, etc.). If used, it is included by |
c906108c SS |
3539 | @file{tm-@var{ttt}.h}. It can be shared among many targets that use the |
3540 | same processor. | |
3541 | ||
af6c57ea AC |
3542 | New targets do not need this file and should not create it. |
3543 | ||
c906108c SS |
3544 | @end table |
3545 | ||
3546 | If you are adding a new operating system for an existing CPU chip, add a | |
3547 | @file{config/tm-@var{os}.h} file that describes the operating system | |
3548 | facilities that are unusual (extra symbol table info; the breakpoint | |
56caf160 | 3549 | instruction needed; etc.). Then write a @file{@var{arch}/tm-@var{os}.h} |
c906108c SS |
3550 | that just @code{#include}s @file{tm-@var{arch}.h} and |
3551 | @file{config/tm-@var{os}.h}. | |
3552 | ||
3553 | ||
3554 | @node Target Vector Definition | |
3555 | ||
3556 | @chapter Target Vector Definition | |
56caf160 | 3557 | @cindex target vector |
c906108c | 3558 | |
56caf160 EZ |
3559 | The target vector defines the interface between @value{GDBN}'s |
3560 | abstract handling of target systems, and the nitty-gritty code that | |
3561 | actually exercises control over a process or a serial port. | |
3562 | @value{GDBN} includes some 30-40 different target vectors; however, | |
3563 | each configuration of @value{GDBN} includes only a few of them. | |
c906108c SS |
3564 | |
3565 | @section File Targets | |
3566 | ||
3567 | Both executables and core files have target vectors. | |
3568 | ||
3569 | @section Standard Protocol and Remote Stubs | |
3570 | ||
56caf160 EZ |
3571 | @value{GDBN}'s file @file{remote.c} talks a serial protocol to code |
3572 | that runs in the target system. @value{GDBN} provides several sample | |
3573 | @dfn{stubs} that can be integrated into target programs or operating | |
3574 | systems for this purpose; they are named @file{*-stub.c}. | |
c906108c | 3575 | |
56caf160 EZ |
3576 | The @value{GDBN} user's manual describes how to put such a stub into |
3577 | your target code. What follows is a discussion of integrating the | |
3578 | SPARC stub into a complicated operating system (rather than a simple | |
3579 | program), by Stu Grossman, the author of this stub. | |
c906108c SS |
3580 | |
3581 | The trap handling code in the stub assumes the following upon entry to | |
56caf160 | 3582 | @code{trap_low}: |
c906108c SS |
3583 | |
3584 | @enumerate | |
56caf160 EZ |
3585 | @item |
3586 | %l1 and %l2 contain pc and npc respectively at the time of the trap; | |
c906108c | 3587 | |
56caf160 EZ |
3588 | @item |
3589 | traps are disabled; | |
c906108c | 3590 | |
56caf160 EZ |
3591 | @item |
3592 | you are in the correct trap window. | |
c906108c SS |
3593 | @end enumerate |
3594 | ||
3595 | As long as your trap handler can guarantee those conditions, then there | |
56caf160 | 3596 | is no reason why you shouldn't be able to ``share'' traps with the stub. |
c906108c SS |
3597 | The stub has no requirement that it be jumped to directly from the |
3598 | hardware trap vector. That is why it calls @code{exceptionHandler()}, | |
3599 | which is provided by the external environment. For instance, this could | |
56caf160 | 3600 | set up the hardware traps to actually execute code which calls the stub |
c906108c SS |
3601 | first, and then transfers to its own trap handler. |
3602 | ||
3603 | For the most point, there probably won't be much of an issue with | |
56caf160 | 3604 | ``sharing'' traps, as the traps we use are usually not used by the kernel, |
c906108c SS |
3605 | and often indicate unrecoverable error conditions. Anyway, this is all |
3606 | controlled by a table, and is trivial to modify. The most important | |
3607 | trap for us is for @code{ta 1}. Without that, we can't single step or | |
3608 | do breakpoints. Everything else is unnecessary for the proper operation | |
3609 | of the debugger/stub. | |
3610 | ||
3611 | From reading the stub, it's probably not obvious how breakpoints work. | |
25822942 | 3612 | They are simply done by deposit/examine operations from @value{GDBN}. |
c906108c SS |
3613 | |
3614 | @section ROM Monitor Interface | |
3615 | ||
3616 | @section Custom Protocols | |
3617 | ||
3618 | @section Transport Layer | |
3619 | ||
3620 | @section Builtin Simulator | |
3621 | ||
3622 | ||
3623 | @node Native Debugging | |
3624 | ||
3625 | @chapter Native Debugging | |
56caf160 | 3626 | @cindex native debugging |
c906108c | 3627 | |
25822942 | 3628 | Several files control @value{GDBN}'s configuration for native support: |
c906108c SS |
3629 | |
3630 | @table @file | |
56caf160 | 3631 | @vindex NATDEPFILES |
c906108c SS |
3632 | @item gdb/config/@var{arch}/@var{xyz}.mh |
3633 | Specifies Makefile fragments needed when hosting @emph{or native} on | |
3634 | machine @var{xyz}. In particular, this lists the required | |
3635 | native-dependent object files, by defining @samp{NATDEPFILES=@dots{}}. | |
3636 | Also specifies the header file which describes native support on | |
3637 | @var{xyz}, by defining @samp{NAT_FILE= nm-@var{xyz}.h}. You can also | |
3638 | define @samp{NAT_CFLAGS}, @samp{NAT_ADD_FILES}, @samp{NAT_CLIBS}, | |
3639 | @samp{NAT_CDEPS}, etc.; see @file{Makefile.in}. | |
3640 | ||
3641 | @item gdb/config/@var{arch}/nm-@var{xyz}.h | |
56caf160 | 3642 | (@file{nm.h} is a link to this file, created by @code{configure}). Contains C |
c906108c SS |
3643 | macro definitions describing the native system environment, such as |
3644 | child process control and core file support. | |
3645 | ||
3646 | @item gdb/@var{xyz}-nat.c | |
3647 | Contains any miscellaneous C code required for this native support of | |
3648 | this machine. On some machines it doesn't exist at all. | |
c906108c SS |
3649 | @end table |
3650 | ||
3651 | There are some ``generic'' versions of routines that can be used by | |
3652 | various systems. These can be customized in various ways by macros | |
3653 | defined in your @file{nm-@var{xyz}.h} file. If these routines work for | |
3654 | the @var{xyz} host, you can just include the generic file's name (with | |
3655 | @samp{.o}, not @samp{.c}) in @code{NATDEPFILES}. | |
3656 | ||
3657 | Otherwise, if your machine needs custom support routines, you will need | |
3658 | to write routines that perform the same functions as the generic file. | |
56caf160 | 3659 | Put them into @file{@var{xyz}-nat.c}, and put @file{@var{xyz}-nat.o} |
c906108c SS |
3660 | into @code{NATDEPFILES}. |
3661 | ||
3662 | @table @file | |
c906108c SS |
3663 | @item inftarg.c |
3664 | This contains the @emph{target_ops vector} that supports Unix child | |
3665 | processes on systems which use ptrace and wait to control the child. | |
3666 | ||
3667 | @item procfs.c | |
3668 | This contains the @emph{target_ops vector} that supports Unix child | |
3669 | processes on systems which use /proc to control the child. | |
3670 | ||
3671 | @item fork-child.c | |
56caf160 EZ |
3672 | This does the low-level grunge that uses Unix system calls to do a ``fork |
3673 | and exec'' to start up a child process. | |
c906108c SS |
3674 | |
3675 | @item infptrace.c | |
3676 | This is the low level interface to inferior processes for systems using | |
3677 | the Unix @code{ptrace} call in a vanilla way. | |
c906108c SS |
3678 | @end table |
3679 | ||
3680 | @section Native core file Support | |
56caf160 | 3681 | @cindex native core files |
c906108c SS |
3682 | |
3683 | @table @file | |
56caf160 | 3684 | @findex fetch_core_registers |
c906108c SS |
3685 | @item core-aout.c::fetch_core_registers() |
3686 | Support for reading registers out of a core file. This routine calls | |
3687 | @code{register_addr()}, see below. Now that BFD is used to read core | |
3688 | files, virtually all machines should use @code{core-aout.c}, and should | |
3689 | just provide @code{fetch_core_registers} in @code{@var{xyz}-nat.c} (or | |
3690 | @code{REGISTER_U_ADDR} in @code{nm-@var{xyz}.h}). | |
3691 | ||
3692 | @item core-aout.c::register_addr() | |
3693 | If your @code{nm-@var{xyz}.h} file defines the macro | |
3694 | @code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to | |
25822942 | 3695 | set @code{addr} to the offset within the @samp{user} struct of @value{GDBN} |
c906108c SS |
3696 | register number @code{regno}. @code{blockend} is the offset within the |
3697 | ``upage'' of @code{u.u_ar0}. If @code{REGISTER_U_ADDR} is defined, | |
3698 | @file{core-aout.c} will define the @code{register_addr()} function and | |
3699 | use the macro in it. If you do not define @code{REGISTER_U_ADDR}, but | |
3700 | you are using the standard @code{fetch_core_registers()}, you will need | |
3701 | to define your own version of @code{register_addr()}, put it into your | |
3702 | @code{@var{xyz}-nat.c} file, and be sure @code{@var{xyz}-nat.o} is in | |
3703 | the @code{NATDEPFILES} list. If you have your own | |
3704 | @code{fetch_core_registers()}, you may not need a separate | |
3705 | @code{register_addr()}. Many custom @code{fetch_core_registers()} | |
3706 | implementations simply locate the registers themselves.@refill | |
c906108c SS |
3707 | @end table |
3708 | ||
25822942 | 3709 | When making @value{GDBN} run native on a new operating system, to make it |
c906108c SS |
3710 | possible to debug core files, you will need to either write specific |
3711 | code for parsing your OS's core files, or customize | |
3712 | @file{bfd/trad-core.c}. First, use whatever @code{#include} files your | |
3713 | machine uses to define the struct of registers that is accessible | |
3714 | (possibly in the u-area) in a core file (rather than | |
3715 | @file{machine/reg.h}), and an include file that defines whatever header | |
56caf160 EZ |
3716 | exists on a core file (e.g. the u-area or a @code{struct core}). Then |
3717 | modify @code{trad_unix_core_file_p} to use these values to set up the | |
c906108c SS |
3718 | section information for the data segment, stack segment, any other |
3719 | segments in the core file (perhaps shared library contents or control | |
3720 | information), ``registers'' segment, and if there are two discontiguous | |
3721 | sets of registers (e.g. integer and float), the ``reg2'' segment. This | |
3722 | section information basically delimits areas in the core file in a | |
3723 | standard way, which the section-reading routines in BFD know how to seek | |
3724 | around in. | |
3725 | ||
25822942 | 3726 | Then back in @value{GDBN}, you need a matching routine called |
56caf160 | 3727 | @code{fetch_core_registers}. If you can use the generic one, it's in |
c906108c SS |
3728 | @file{core-aout.c}; if not, it's in your @file{@var{xyz}-nat.c} file. |
3729 | It will be passed a char pointer to the entire ``registers'' segment, | |
3730 | its length, and a zero; or a char pointer to the entire ``regs2'' | |
3731 | segment, its length, and a 2. The routine should suck out the supplied | |
25822942 | 3732 | register values and install them into @value{GDBN}'s ``registers'' array. |
c906108c SS |
3733 | |
3734 | If your system uses @file{/proc} to control processes, and uses ELF | |
3735 | format core files, then you may be able to use the same routines for | |
3736 | reading the registers out of processes and out of core files. | |
3737 | ||
3738 | @section ptrace | |
3739 | ||
3740 | @section /proc | |
3741 | ||
3742 | @section win32 | |
3743 | ||
3744 | @section shared libraries | |
3745 | ||
3746 | @section Native Conditionals | |
56caf160 | 3747 | @cindex native conditionals |
c906108c | 3748 | |
56caf160 EZ |
3749 | When @value{GDBN} is configured and compiled, various macros are |
3750 | defined or left undefined, to control compilation when the host and | |
3751 | target systems are the same. These macros should be defined (or left | |
3752 | undefined) in @file{nm-@var{system}.h}. | |
c906108c SS |
3753 | |
3754 | @table @code | |
c906108c | 3755 | @item ATTACH_DETACH |
56caf160 | 3756 | @findex ATTACH_DETACH |
25822942 | 3757 | If defined, then @value{GDBN} will include support for the @code{attach} and |
c906108c SS |
3758 | @code{detach} commands. |
3759 | ||
3760 | @item CHILD_PREPARE_TO_STORE | |
56caf160 | 3761 | @findex CHILD_PREPARE_TO_STORE |
c906108c SS |
3762 | If the machine stores all registers at once in the child process, then |
3763 | define this to ensure that all values are correct. This usually entails | |
3764 | a read from the child. | |
3765 | ||
3766 | [Note that this is incorrectly defined in @file{xm-@var{system}.h} files | |
3767 | currently.] | |
3768 | ||
3769 | @item FETCH_INFERIOR_REGISTERS | |
56caf160 | 3770 | @findex FETCH_INFERIOR_REGISTERS |
c906108c SS |
3771 | Define this if the native-dependent code will provide its own routines |
3772 | @code{fetch_inferior_registers} and @code{store_inferior_registers} in | |
56caf160 | 3773 | @file{@var{host}-nat.c}. If this symbol is @emph{not} defined, and |
c906108c SS |
3774 | @file{infptrace.c} is included in this configuration, the default |
3775 | routines in @file{infptrace.c} are used for these functions. | |
3776 | ||
3777 | @item FILES_INFO_HOOK | |
56caf160 | 3778 | @findex FILES_INFO_HOOK |
c906108c SS |
3779 | (Only defined for Convex.) |
3780 | ||
3781 | @item FP0_REGNUM | |
56caf160 | 3782 | @findex FP0_REGNUM |
c906108c SS |
3783 | This macro is normally defined to be the number of the first floating |
3784 | point register, if the machine has such registers. As such, it would | |
56caf160 | 3785 | appear only in target-specific code. However, @file{/proc} support uses this |
c906108c SS |
3786 | to decide whether floats are in use on this target. |
3787 | ||
3788 | @item GET_LONGJMP_TARGET | |
56caf160 | 3789 | @findex GET_LONGJMP_TARGET |
c906108c SS |
3790 | For most machines, this is a target-dependent parameter. On the |
3791 | DECstation and the Iris, this is a native-dependent parameter, since | |
56caf160 | 3792 | @file{setjmp.h} is needed to define it. |
c906108c | 3793 | |
56caf160 | 3794 | This macro determines the target PC address that @code{longjmp} will jump to, |
c906108c | 3795 | assuming that we have just stopped at a longjmp breakpoint. It takes a |
56caf160 | 3796 | @code{CORE_ADDR *} as argument, and stores the target PC value through this |
c906108c SS |
3797 | pointer. It examines the current state of the machine as needed. |
3798 | ||
9742079a EZ |
3799 | @item I386_USE_GENERIC_WATCHPOINTS |
3800 | An x86-based machine can define this to use the generic x86 watchpoint | |
3801 | support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}. | |
3802 | ||
c906108c | 3803 | @item KERNEL_U_ADDR |
56caf160 | 3804 | @findex KERNEL_U_ADDR |
c906108c | 3805 | Define this to the address of the @code{u} structure (the ``user |
25822942 | 3806 | struct'', also known as the ``u-page'') in kernel virtual memory. @value{GDBN} |
c906108c SS |
3807 | needs to know this so that it can subtract this address from absolute |
3808 | addresses in the upage, that are obtained via ptrace or from core files. | |
3809 | On systems that don't need this value, set it to zero. | |
3810 | ||
3811 | @item KERNEL_U_ADDR_BSD | |
56caf160 | 3812 | @findex KERNEL_U_ADDR_BSD |
25822942 | 3813 | Define this to cause @value{GDBN} to determine the address of @code{u} at |
c906108c SS |
3814 | runtime, by using Berkeley-style @code{nlist} on the kernel's image in |
3815 | the root directory. | |
3816 | ||
3817 | @item KERNEL_U_ADDR_HPUX | |
56caf160 | 3818 | @findex KERNEL_U_ADDR_HPUX |
25822942 | 3819 | Define this to cause @value{GDBN} to determine the address of @code{u} at |
c906108c SS |
3820 | runtime, by using HP-style @code{nlist} on the kernel's image in the |
3821 | root directory. | |
3822 | ||
3823 | @item ONE_PROCESS_WRITETEXT | |
56caf160 | 3824 | @findex ONE_PROCESS_WRITETEXT |
c906108c SS |
3825 | Define this to be able to, when a breakpoint insertion fails, warn the |
3826 | user that another process may be running with the same executable. | |
3827 | ||
56caf160 EZ |
3828 | @item PREPARE_TO_PROCEED (@var{select_it}) |
3829 | @findex PREPARE_TO_PROCEED | |
adf40b2e JM |
3830 | This (ugly) macro allows a native configuration to customize the way the |
3831 | @code{proceed} function in @file{infrun.c} deals with switching between | |
3832 | threads. | |
3833 | ||
3834 | In a multi-threaded task we may select another thread and then continue | |
3835 | or step. But if the old thread was stopped at a breakpoint, it will | |
3836 | immediately cause another breakpoint stop without any execution (i.e. it | |
25822942 | 3837 | will report a breakpoint hit incorrectly). So @value{GDBN} must step over it |
adf40b2e JM |
3838 | first. |
3839 | ||
3840 | If defined, @code{PREPARE_TO_PROCEED} should check the current thread | |
3841 | against the thread that reported the most recent event. If a step-over | |
3842 | is required, it returns TRUE. If @var{select_it} is non-zero, it should | |
3843 | reselect the old thread. | |
3844 | ||
c906108c | 3845 | @item PROC_NAME_FMT |
56caf160 | 3846 | @findex PROC_NAME_FMT |
c906108c SS |
3847 | Defines the format for the name of a @file{/proc} device. Should be |
3848 | defined in @file{nm.h} @emph{only} in order to override the default | |
3849 | definition in @file{procfs.c}. | |
3850 | ||
3851 | @item PTRACE_FP_BUG | |
56caf160 EZ |
3852 | @findex PTRACE_FP_BUG |
3853 | See @file{mach386-xdep.c}. | |
c906108c SS |
3854 | |
3855 | @item PTRACE_ARG3_TYPE | |
56caf160 | 3856 | @findex PTRACE_ARG3_TYPE |
c906108c SS |
3857 | The type of the third argument to the @code{ptrace} system call, if it |
3858 | exists and is different from @code{int}. | |
3859 | ||
3860 | @item REGISTER_U_ADDR | |
56caf160 | 3861 | @findex REGISTER_U_ADDR |
c906108c SS |
3862 | Defines the offset of the registers in the ``u area''. |
3863 | ||
3864 | @item SHELL_COMMAND_CONCAT | |
56caf160 | 3865 | @findex SHELL_COMMAND_CONCAT |
c906108c SS |
3866 | If defined, is a string to prefix on the shell command used to start the |
3867 | inferior. | |
3868 | ||
3869 | @item SHELL_FILE | |
56caf160 | 3870 | @findex SHELL_FILE |
c906108c SS |
3871 | If defined, this is the name of the shell to use to run the inferior. |
3872 | Defaults to @code{"/bin/sh"}. | |
3873 | ||
56caf160 EZ |
3874 | @item SOLIB_ADD (@var{filename}, @var{from_tty}, @var{targ}) |
3875 | @findex SOLIB_ADD | |
c906108c | 3876 | Define this to expand into an expression that will cause the symbols in |
25822942 | 3877 | @var{filename} to be added to @value{GDBN}'s symbol table. |
c906108c SS |
3878 | |
3879 | @item SOLIB_CREATE_INFERIOR_HOOK | |
56caf160 | 3880 | @findex SOLIB_CREATE_INFERIOR_HOOK |
c906108c SS |
3881 | Define this to expand into any shared-library-relocation code that you |
3882 | want to be run just after the child process has been forked. | |
3883 | ||
3884 | @item START_INFERIOR_TRAPS_EXPECTED | |
56caf160 EZ |
3885 | @findex START_INFERIOR_TRAPS_EXPECTED |
3886 | When starting an inferior, @value{GDBN} normally expects to trap | |
3887 | twice; once when | |
c906108c SS |
3888 | the shell execs, and once when the program itself execs. If the actual |
3889 | number of traps is something other than 2, then define this macro to | |
3890 | expand into the number expected. | |
3891 | ||
3892 | @item SVR4_SHARED_LIBS | |
56caf160 | 3893 | @findex SVR4_SHARED_LIBS |
c906108c SS |
3894 | Define this to indicate that SVR4-style shared libraries are in use. |
3895 | ||
3896 | @item USE_PROC_FS | |
56caf160 | 3897 | @findex USE_PROC_FS |
c906108c | 3898 | This determines whether small routines in @file{*-tdep.c}, which |
56caf160 EZ |
3899 | translate register values between @value{GDBN}'s internal |
3900 | representation and the @file{/proc} representation, are compiled. | |
c906108c SS |
3901 | |
3902 | @item U_REGS_OFFSET | |
56caf160 | 3903 | @findex U_REGS_OFFSET |
c906108c SS |
3904 | This is the offset of the registers in the upage. It need only be |
3905 | defined if the generic ptrace register access routines in | |
3906 | @file{infptrace.c} are being used (that is, @file{infptrace.c} is | |
3907 | configured in, and @code{FETCH_INFERIOR_REGISTERS} is not defined). If | |
3908 | the default value from @file{infptrace.c} is good enough, leave it | |
3909 | undefined. | |
3910 | ||
3911 | The default value means that u.u_ar0 @emph{points to} the location of | |
3912 | the registers. I'm guessing that @code{#define U_REGS_OFFSET 0} means | |
56caf160 | 3913 | that @code{u.u_ar0} @emph{is} the location of the registers. |
c906108c SS |
3914 | |
3915 | @item CLEAR_SOLIB | |
56caf160 EZ |
3916 | @findex CLEAR_SOLIB |
3917 | See @file{objfiles.c}. | |
c906108c SS |
3918 | |
3919 | @item DEBUG_PTRACE | |
56caf160 EZ |
3920 | @findex DEBUG_PTRACE |
3921 | Define this to debug @code{ptrace} calls. | |
c906108c SS |
3922 | @end table |
3923 | ||
3924 | ||
3925 | @node Support Libraries | |
3926 | ||
3927 | @chapter Support Libraries | |
3928 | ||
3929 | @section BFD | |
56caf160 | 3930 | @cindex BFD library |
c906108c | 3931 | |
25822942 | 3932 | BFD provides support for @value{GDBN} in several ways: |
c906108c SS |
3933 | |
3934 | @table @emph | |
c906108c SS |
3935 | @item identifying executable and core files |
3936 | BFD will identify a variety of file types, including a.out, coff, and | |
3937 | several variants thereof, as well as several kinds of core files. | |
3938 | ||
3939 | @item access to sections of files | |
3940 | BFD parses the file headers to determine the names, virtual addresses, | |
3941 | sizes, and file locations of all the various named sections in files | |
56caf160 EZ |
3942 | (such as the text section or the data section). @value{GDBN} simply |
3943 | calls BFD to read or write section @var{x} at byte offset @var{y} for | |
3944 | length @var{z}. | |
c906108c SS |
3945 | |
3946 | @item specialized core file support | |
3947 | BFD provides routines to determine the failing command name stored in a | |
3948 | core file, the signal with which the program failed, and whether a core | |
56caf160 | 3949 | file matches (i.e.@: could be a core dump of) a particular executable |
c906108c SS |
3950 | file. |
3951 | ||
3952 | @item locating the symbol information | |
25822942 DB |
3953 | @value{GDBN} uses an internal interface of BFD to determine where to find the |
3954 | symbol information in an executable file or symbol-file. @value{GDBN} itself | |
c906108c | 3955 | handles the reading of symbols, since BFD does not ``understand'' debug |
25822942 | 3956 | symbols, but @value{GDBN} uses BFD's cached information to find the symbols, |
c906108c | 3957 | string table, etc. |
c906108c SS |
3958 | @end table |
3959 | ||
3960 | @section opcodes | |
56caf160 | 3961 | @cindex opcodes library |
c906108c | 3962 | |
25822942 | 3963 | The opcodes library provides @value{GDBN}'s disassembler. (It's a separate |
c906108c SS |
3964 | library because it's also used in binutils, for @file{objdump}). |
3965 | ||
3966 | @section readline | |
3967 | ||
3968 | @section mmalloc | |
3969 | ||
3970 | @section libiberty | |
3971 | ||
3972 | @section gnu-regex | |
56caf160 | 3973 | @cindex regular expressions library |
c906108c SS |
3974 | |
3975 | Regex conditionals. | |
3976 | ||
3977 | @table @code | |
c906108c SS |
3978 | @item C_ALLOCA |
3979 | ||
3980 | @item NFAILURES | |
3981 | ||
3982 | @item RE_NREGS | |
3983 | ||
3984 | @item SIGN_EXTEND_CHAR | |
3985 | ||
3986 | @item SWITCH_ENUM_BUG | |
3987 | ||
3988 | @item SYNTAX_TABLE | |
3989 | ||
3990 | @item Sword | |
3991 | ||
3992 | @item sparc | |
c906108c SS |
3993 | @end table |
3994 | ||
3995 | @section include | |
3996 | ||
3997 | @node Coding | |
3998 | ||
3999 | @chapter Coding | |
4000 | ||
4001 | This chapter covers topics that are lower-level than the major | |
25822942 | 4002 | algorithms of @value{GDBN}. |
c906108c SS |
4003 | |
4004 | @section Cleanups | |
56caf160 | 4005 | @cindex cleanups |
c906108c SS |
4006 | |
4007 | Cleanups are a structured way to deal with things that need to be done | |
4008 | later. When your code does something (like @code{malloc} some memory, | |
56caf160 | 4009 | or open a file) that needs to be undone later (e.g., free the memory or |
c906108c SS |
4010 | close the file), it can make a cleanup. The cleanup will be done at |
4011 | some future point: when the command is finished, when an error occurs, | |
4012 | or when your code decides it's time to do cleanups. | |
4013 | ||
4014 | You can also discard cleanups, that is, throw them away without doing | |
4015 | what they say. This is only done if you ask that it be done. | |
4016 | ||
4017 | Syntax: | |
4018 | ||
4019 | @table @code | |
c906108c SS |
4020 | @item struct cleanup *@var{old_chain}; |
4021 | Declare a variable which will hold a cleanup chain handle. | |
4022 | ||
56caf160 | 4023 | @findex make_cleanup |
c906108c SS |
4024 | @item @var{old_chain} = make_cleanup (@var{function}, @var{arg}); |
4025 | Make a cleanup which will cause @var{function} to be called with | |
4026 | @var{arg} (a @code{char *}) later. The result, @var{old_chain}, is a | |
4027 | handle that can be passed to @code{do_cleanups} or | |
4028 | @code{discard_cleanups} later. Unless you are going to call | |
4029 | @code{do_cleanups} or @code{discard_cleanups} yourself, you can ignore | |
4030 | the result from @code{make_cleanup}. | |
4031 | ||
56caf160 | 4032 | @findex do_cleanups |
c906108c SS |
4033 | @item do_cleanups (@var{old_chain}); |
4034 | Perform all cleanups done since @code{make_cleanup} returned | |
4035 | @var{old_chain}. E.g.: | |
56caf160 | 4036 | |
c906108c SS |
4037 | @example |
4038 | make_cleanup (a, 0); | |
4039 | old = make_cleanup (b, 0); | |
4040 | do_cleanups (old); | |
4041 | @end example | |
56caf160 | 4042 | |
c906108c SS |
4043 | @noindent |
4044 | will call @code{b()} but will not call @code{a()}. The cleanup that | |
4045 | calls @code{a()} will remain in the cleanup chain, and will be done | |
4046 | later unless otherwise discarded.@refill | |
4047 | ||
56caf160 | 4048 | @findex discard_cleanups |
c906108c SS |
4049 | @item discard_cleanups (@var{old_chain}); |
4050 | Same as @code{do_cleanups} except that it just removes the cleanups from | |
4051 | the chain and does not call the specified functions. | |
c906108c SS |
4052 | @end table |
4053 | ||
4054 | Some functions, e.g. @code{fputs_filtered()} or @code{error()}, specify | |
4055 | that they ``should not be called when cleanups are not in place''. This | |
4056 | means that any actions you need to reverse in the case of an error or | |
4057 | interruption must be on the cleanup chain before you call these | |
4058 | functions, since they might never return to your code (they | |
4059 | @samp{longjmp} instead). | |
4060 | ||
4061 | @section Wrapping Output Lines | |
56caf160 | 4062 | @cindex line wrap in output |
c906108c | 4063 | |
56caf160 | 4064 | @findex wrap_here |
c906108c SS |
4065 | Output that goes through @code{printf_filtered} or @code{fputs_filtered} |
4066 | or @code{fputs_demangled} needs only to have calls to @code{wrap_here} | |
4067 | added in places that would be good breaking points. The utility | |
4068 | routines will take care of actually wrapping if the line width is | |
4069 | exceeded. | |
4070 | ||
4071 | The argument to @code{wrap_here} is an indentation string which is | |
4072 | printed @emph{only} if the line breaks there. This argument is saved | |
4073 | away and used later. It must remain valid until the next call to | |
4074 | @code{wrap_here} or until a newline has been printed through the | |
4075 | @code{*_filtered} functions. Don't pass in a local variable and then | |
4076 | return! | |
4077 | ||
56caf160 | 4078 | It is usually best to call @code{wrap_here} after printing a comma or |
c906108c SS |
4079 | space. If you call it before printing a space, make sure that your |
4080 | indentation properly accounts for the leading space that will print if | |
4081 | the line wraps there. | |
4082 | ||
4083 | Any function or set of functions that produce filtered output must | |
4084 | finish by printing a newline, to flush the wrap buffer, before switching | |
56caf160 | 4085 | to unfiltered (@code{printf}) output. Symbol reading routines that |
c906108c SS |
4086 | print warnings are a good example. |
4087 | ||
25822942 | 4088 | @section @value{GDBN} Coding Standards |
56caf160 | 4089 | @cindex coding standards |
c906108c | 4090 | |
25822942 | 4091 | @value{GDBN} follows the GNU coding standards, as described in |
c906108c | 4092 | @file{etc/standards.texi}. This file is also available for anonymous |
af6c57ea AC |
4093 | FTP from GNU archive sites. @value{GDBN} takes a strict interpretation |
4094 | of the standard; in general, when the GNU standard recommends a practice | |
4095 | but does not require it, @value{GDBN} requires it. | |
c906108c | 4096 | |
56caf160 EZ |
4097 | @value{GDBN} follows an additional set of coding standards specific to |
4098 | @value{GDBN}, as described in the following sections. | |
c906108c | 4099 | |
af6c57ea AC |
4100 | |
4101 | @subsection ISO-C | |
4102 | ||
4103 | @value{GDBN} assumes an ISO-C compliant compiler. | |
4104 | ||
4105 | @value{GDBN} does not assume an ISO-C or POSIX compliant C library. | |
4106 | ||
4107 | ||
4108 | @subsection Memory Management | |
4109 | ||
4110 | @value{GDBN} does not use the functions @code{malloc}, @code{realloc}, | |
4111 | @code{calloc}, @code{free} and @code{asprintf}. | |
4112 | ||
4113 | @value{GDBN} uses the functions @code{xmalloc}, @code{xrealloc} and | |
4114 | @code{xcalloc} when allocating memory. Unlike @code{malloc} et.al.@: | |
4115 | these functions do not return when the memory pool is empty. Instead, | |
4116 | they unwind the stack using cleanups. These functions return | |
4117 | @code{NULL} when requested to allocate a chunk of memory of size zero. | |
4118 | ||
4119 | @emph{Pragmatics: By using these functions, the need to check every | |
4120 | memory allocation is removed. These functions provide portable | |
4121 | behavior.} | |
4122 | ||
4123 | @value{GDBN} does not use the function @code{free}. | |
4124 | ||
4125 | @value{GDBN} uses the function @code{xfree} to return memory to the | |
4126 | memory pool. Consistent with ISO-C, this function ignores a request to | |
4127 | free a @code{NULL} pointer. | |
4128 | ||
4129 | @emph{Pragmatics: On some systems @code{free} fails when passed a | |
4130 | @code{NULL} pointer.} | |
4131 | ||
4132 | @value{GDBN} can use the non-portable function @code{alloca} for the | |
4133 | allocation of small temporary values (such as strings). | |
4134 | ||
4135 | @emph{Pragmatics: This function is very non-portable. Some systems | |
4136 | restrict the memory being allocated to no more than a few kilobytes.} | |
4137 | ||
4138 | @value{GDBN} uses the string function @code{xstrdup} and the print | |
4139 | function @code{xasprintf}. | |
4140 | ||
4141 | @emph{Pragmatics: @code{asprintf} and @code{strdup} can fail. Print | |
4142 | functions such as @code{sprintf} are very prone to buffer overflow | |
4143 | errors.} | |
4144 | ||
4145 | ||
4146 | @subsection Compiler Warnings | |
56caf160 | 4147 | @cindex compiler warnings |
af6c57ea AC |
4148 | |
4149 | With few exceptions, developers should include the configuration option | |
4150 | @samp{--enable-gdb-build-warnings=,-Werror} when building @value{GDBN}. | |
4151 | The exceptions are listed in the file @file{gdb/MAINTAINERS}. | |
4152 | ||
4153 | This option causes @value{GDBN} (when built using GCC) to be compiled | |
4154 | with a carefully selected list of compiler warning flags. Any warnings | |
4155 | from those flags being treated as errors. | |
4156 | ||
4157 | The current list of warning flags includes: | |
4158 | ||
4159 | @table @samp | |
4160 | @item -Wimplicit | |
4161 | Since @value{GDBN} coding standard requires all functions to be declared | |
4162 | using a prototype, the flag has the side effect of ensuring that | |
4163 | prototyped functions are always visible with out resorting to | |
4164 | @samp{-Wstrict-prototypes}. | |
4165 | ||
4166 | @item -Wreturn-type | |
4167 | Such code often appears to work except on instruction set architectures | |
4168 | that use register windows. | |
4169 | ||
4170 | @item -Wcomment | |
4171 | ||
4172 | @item -Wtrigraphs | |
4173 | ||
4174 | @item -Wformat | |
4175 | Since @value{GDBN} uses the @code{format printf} attribute on all | |
4176 | @code{printf} like functions this checks not just @code{printf} calls | |
4177 | but also calls to functions such as @code{fprintf_unfiltered}. | |
4178 | ||
4179 | @item -Wparentheses | |
4180 | This warning includes uses of the assignment operator within an | |
4181 | @code{if} statement. | |
4182 | ||
4183 | @item -Wpointer-arith | |
4184 | ||
4185 | @item -Wuninitialized | |
4186 | @end table | |
4187 | ||
4188 | @emph{Pragmatics: Due to the way that @value{GDBN} is implemented most | |
4189 | functions have unused parameters. Consequently the warning | |
4190 | @samp{-Wunused-parameter} is precluded from the list. The macro | |
4191 | @code{ATTRIBUTE_UNUSED} is not used as it leads to false negatives --- | |
4192 | it is not an error to have @code{ATTRIBUTE_UNUSED} on a parameter that | |
4193 | is being used. The options @samp{-Wall} and @samp{-Wunused} are also | |
4194 | precluded because they both include @samp{-Wunused-parameter}.} | |
4195 | ||
4196 | @emph{Pragmatics: @value{GDBN} has not simply accepted the warnings | |
4197 | enabled by @samp{-Wall -Werror -W...}. Instead it is selecting warnings | |
4198 | when and where their benefits can be demonstrated.} | |
c906108c SS |
4199 | |
4200 | @subsection Formatting | |
4201 | ||
56caf160 | 4202 | @cindex source code formatting |
c906108c SS |
4203 | The standard GNU recommendations for formatting must be followed |
4204 | strictly. | |
4205 | ||
af6c57ea AC |
4206 | A function declaration should not have its name in column zero. A |
4207 | function definition should have its name in column zero. | |
4208 | ||
4209 | @example | |
4210 | /* Declaration */ | |
4211 | static void foo (void); | |
4212 | /* Definition */ | |
4213 | void | |
4214 | foo (void) | |
4215 | @{ | |
4216 | @} | |
4217 | @end example | |
4218 | ||
4219 | @emph{Pragmatics: This simplifies scripting. Function definitions can | |
4220 | be found using @samp{^function-name}.} | |
c906108c | 4221 | |
af6c57ea AC |
4222 | There must be a space between a function or macro name and the opening |
4223 | parenthesis of its argument list (except for macro definitions, as | |
4224 | required by C). There must not be a space after an open paren/bracket | |
4225 | or before a close paren/bracket. | |
c906108c SS |
4226 | |
4227 | While additional whitespace is generally helpful for reading, do not use | |
4228 | more than one blank line to separate blocks, and avoid adding whitespace | |
af6c57ea AC |
4229 | after the end of a program line (as of 1/99, some 600 lines had |
4230 | whitespace after the semicolon). Excess whitespace causes difficulties | |
4231 | for @code{diff} and @code{patch} utilities. | |
4232 | ||
4233 | Pointers are declared using the traditional K&R C style: | |
4234 | ||
4235 | @example | |
4236 | void *foo; | |
4237 | @end example | |
4238 | ||
4239 | @noindent | |
4240 | and not: | |
4241 | ||
4242 | @example | |
4243 | void * foo; | |
4244 | void* foo; | |
4245 | @end example | |
c906108c SS |
4246 | |
4247 | @subsection Comments | |
4248 | ||
56caf160 | 4249 | @cindex comment formatting |
c906108c SS |
4250 | The standard GNU requirements on comments must be followed strictly. |
4251 | ||
af6c57ea AC |
4252 | Block comments must appear in the following form, with no @code{/*}- or |
4253 | @code{*/}-only lines, and no leading @code{*}: | |
c906108c | 4254 | |
56caf160 | 4255 | @example |
c906108c SS |
4256 | /* Wait for control to return from inferior to debugger. If inferior |
4257 | gets a signal, we may decide to start it up again instead of | |
4258 | returning. That is why there is a loop in this function. When | |
4259 | this function actually returns it means the inferior should be left | |
25822942 | 4260 | stopped and @value{GDBN} should read more commands. */ |
c906108c SS |
4261 | @end example |
4262 | ||
4263 | (Note that this format is encouraged by Emacs; tabbing for a multi-line | |
56caf160 | 4264 | comment works correctly, and @kbd{M-q} fills the block consistently.) |
c906108c SS |
4265 | |
4266 | Put a blank line between the block comments preceding function or | |
4267 | variable definitions, and the definition itself. | |
4268 | ||
4269 | In general, put function-body comments on lines by themselves, rather | |
4270 | than trying to fit them into the 20 characters left at the end of a | |
4271 | line, since either the comment or the code will inevitably get longer | |
4272 | than will fit, and then somebody will have to move it anyhow. | |
4273 | ||
4274 | @subsection C Usage | |
4275 | ||
56caf160 | 4276 | @cindex C data types |
c906108c SS |
4277 | Code must not depend on the sizes of C data types, the format of the |
4278 | host's floating point numbers, the alignment of anything, or the order | |
4279 | of evaluation of expressions. | |
4280 | ||
56caf160 | 4281 | @cindex function usage |
c906108c | 4282 | Use functions freely. There are only a handful of compute-bound areas |
56caf160 EZ |
4283 | in @value{GDBN} that might be affected by the overhead of a function |
4284 | call, mainly in symbol reading. Most of @value{GDBN}'s performance is | |
4285 | limited by the target interface (whether serial line or system call). | |
c906108c SS |
4286 | |
4287 | However, use functions with moderation. A thousand one-line functions | |
4288 | are just as hard to understand as a single thousand-line function. | |
4289 | ||
af6c57ea AC |
4290 | @emph{Macros are bad, M'kay.} |
4291 | ||
4292 | @cindex types | |
c906108c | 4293 | |
af6c57ea AC |
4294 | Declarations like @samp{struct foo *} should be used in preference to |
4295 | declarations like @samp{typedef struct foo @{ @dots{} @} *foo_ptr}. | |
4296 | ||
4297 | ||
4298 | @subsection Function Prototypes | |
56caf160 | 4299 | @cindex function prototypes |
af6c57ea AC |
4300 | |
4301 | Prototypes must be used when both @emph{declaring} and @emph{defining} | |
4302 | a function. Prototypes for @value{GDBN} functions must include both the | |
4303 | argument type and name, with the name matching that used in the actual | |
4304 | function definition. | |
c906108c | 4305 | |
53a5351d JM |
4306 | All external functions should have a declaration in a header file that |
4307 | callers include, except for @code{_initialize_*} functions, which must | |
4308 | be external so that @file{init.c} construction works, but shouldn't be | |
4309 | visible to random source files. | |
c906108c | 4310 | |
af6c57ea AC |
4311 | Where a source file needs a forward declaration of a static function, |
4312 | that declaration must appear in a block near the top of the source file. | |
4313 | ||
4314 | ||
4315 | @subsection Internal Error Recovery | |
4316 | ||
4317 | During its execution, @value{GDBN} can encounter two types of errors. | |
4318 | User errors and internal errors. User errors include not only a user | |
4319 | entering an incorrect command but also problems arising from corrupt | |
4320 | object files and system errors when interacting with the target. | |
4321 | Internal errors include situtations where @value{GDBN} has detected, at | |
4322 | run time, a corrupt or erroneous situtation. | |
4323 | ||
4324 | When reporting an internal error, @value{GDBN} uses | |
4325 | @code{internal_error} and @code{gdb_assert}. | |
4326 | ||
4327 | @value{GDBN} must not call @code{abort} or @code{assert}. | |
4328 | ||
4329 | @emph{Pragmatics: There is no @code{internal_warning} function. Either | |
4330 | the code detected a user error, recovered from it and issued a | |
4331 | @code{warning} or the code failed to correctly recover from the user | |
4332 | error and issued an @code{internal_error}.} | |
4333 | ||
4334 | @subsection File Names | |
4335 | ||
4336 | Any file used when building the core of @value{GDBN} must be in lower | |
4337 | case. Any file used when building the core of @value{GDBN} must be 8.3 | |
4338 | unique. These requirements apply to both source and generated files. | |
4339 | ||
4340 | @emph{Pragmatics: The core of @value{GDBN} must be buildable on many | |
4341 | platforms including DJGPP and MacOS/HFS. Every time an unfriendly file | |
4342 | is introduced to the build process both @file{Makefile.in} and | |
4343 | @file{configure.in} need to be modified accordingly. Compare the | |
4344 | convoluted conversion process needed to transform @file{COPYING} into | |
4345 | @file{copying.c} with the conversion needed to transform | |
4346 | @file{version.in} into @file{version.c}.} | |
4347 | ||
4348 | Any file non 8.3 compliant file (that is not used when building the core | |
4349 | of @value{GDBN}) must be added to @file{gdb/config/djgpp/fnchange.lst}. | |
4350 | ||
4351 | @emph{Pragmatics: This is clearly a compromise.} | |
4352 | ||
4353 | When @value{GDBN} has a local version of a system header file (ex | |
4354 | @file{string.h}) the file name based on the POSIX header prefixed with | |
4355 | @file{gdb_} (@file{gdb_string.h}). | |
4356 | ||
4357 | For other files @samp{-} is used as the separator. | |
4358 | ||
4359 | ||
4360 | @subsection Include Files | |
4361 | ||
4362 | All @file{.c} files should include @file{defs.h} first. | |
4363 | ||
4364 | All @file{.c} files should explicitly include the headers for any | |
4365 | declarations they refer to. They should not rely on files being | |
4366 | included indirectly. | |
4367 | ||
4368 | With the exception of the global definitions supplied by @file{defs.h}, | |
4369 | a header file should explictily include the header declaring any | |
4370 | @code{typedefs} et.al.@: it refers to. | |
4371 | ||
4372 | @code{extern} declarations should never appear in @code{.c} files. | |
4373 | ||
4374 | All include files should be wrapped in: | |
4375 | ||
4376 | @example | |
4377 | #ifndef INCLUDE_FILE_NAME_H | |
4378 | #define INCLUDE_FILE_NAME_H | |
4379 | header body | |
4380 | #endif | |
4381 | @end example | |
4382 | ||
c906108c | 4383 | |
dab11f21 | 4384 | @subsection Clean Design and Portable Implementation |
c906108c | 4385 | |
56caf160 | 4386 | @cindex design |
c906108c | 4387 | In addition to getting the syntax right, there's the little question of |
25822942 | 4388 | semantics. Some things are done in certain ways in @value{GDBN} because long |
c906108c SS |
4389 | experience has shown that the more obvious ways caused various kinds of |
4390 | trouble. | |
4391 | ||
56caf160 | 4392 | @cindex assumptions about targets |
c906108c SS |
4393 | You can't assume the byte order of anything that comes from a target |
4394 | (including @var{value}s, object files, and instructions). Such things | |
56caf160 EZ |
4395 | must be byte-swapped using @code{SWAP_TARGET_AND_HOST} in |
4396 | @value{GDBN}, or one of the swap routines defined in @file{bfd.h}, | |
4397 | such as @code{bfd_get_32}. | |
c906108c SS |
4398 | |
4399 | You can't assume that you know what interface is being used to talk to | |
4400 | the target system. All references to the target must go through the | |
4401 | current @code{target_ops} vector. | |
4402 | ||
4403 | You can't assume that the host and target machines are the same machine | |
4404 | (except in the ``native'' support modules). In particular, you can't | |
4405 | assume that the target machine's header files will be available on the | |
4406 | host machine. Target code must bring along its own header files -- | |
4407 | written from scratch or explicitly donated by their owner, to avoid | |
4408 | copyright problems. | |
4409 | ||
56caf160 | 4410 | @cindex portability |
c906108c SS |
4411 | Insertion of new @code{#ifdef}'s will be frowned upon. It's much better |
4412 | to write the code portably than to conditionalize it for various | |
4413 | systems. | |
4414 | ||
56caf160 | 4415 | @cindex system dependencies |
c906108c SS |
4416 | New @code{#ifdef}'s which test for specific compilers or manufacturers |
4417 | or operating systems are unacceptable. All @code{#ifdef}'s should test | |
4418 | for features. The information about which configurations contain which | |
4419 | features should be segregated into the configuration files. Experience | |
4420 | has proven far too often that a feature unique to one particular system | |
4421 | often creeps into other systems; and that a conditional based on some | |
4422 | predefined macro for your current system will become worthless over | |
4423 | time, as new versions of your system come out that behave differently | |
4424 | with regard to this feature. | |
4425 | ||
4426 | Adding code that handles specific architectures, operating systems, | |
af6c57ea | 4427 | target interfaces, or hosts, is not acceptable in generic code. |
c906108c | 4428 | |
dab11f21 EZ |
4429 | @cindex portable file name handling |
4430 | @cindex file names, portability | |
4431 | One particularly notorious area where system dependencies tend to | |
4432 | creep in is handling of file names. The mainline @value{GDBN} code | |
4433 | assumes Posix semantics of file names: absolute file names begin with | |
4434 | a forward slash @file{/}, slashes are used to separate leading | |
4435 | directories, case-sensitive file names. These assumptions are not | |
4436 | necessarily true on non-Posix systems such as MS-Windows. To avoid | |
4437 | system-dependent code where you need to take apart or construct a file | |
4438 | name, use the following portable macros: | |
4439 | ||
4440 | @table @code | |
4441 | @findex HAVE_DOS_BASED_FILE_SYSTEM | |
4442 | @item HAVE_DOS_BASED_FILE_SYSTEM | |
4443 | This preprocessing symbol is defined to a non-zero value on hosts | |
4444 | whose filesystems belong to the MS-DOS/MS-Windows family. Use this | |
4445 | symbol to write conditional code which should only be compiled for | |
4446 | such hosts. | |
4447 | ||
4448 | @findex IS_DIR_SEPARATOR | |
4449 | @item IS_DIR_SEPARATOR (@var{c} | |
4450 | Evaluates to a non-zero value if @var{c} is a directory separator | |
4451 | character. On Unix and GNU/Linux systems, only a slash @file{/} is | |
4452 | such a character, but on Windows, both @file{/} and @file{\} will | |
4453 | pass. | |
4454 | ||
4455 | @findex IS_ABSOLUTE_PATH | |
4456 | @item IS_ABSOLUTE_PATH (@var{file}) | |
4457 | Evaluates to a non-zero value if @var{file} is an absolute file name. | |
4458 | For Unix and GNU/Linux hosts, a name which begins with a slash | |
4459 | @file{/} is absolute. On DOS and Windows, @file{d:/foo} and | |
4460 | @file{x:\bar} are also absolute file names. | |
4461 | ||
4462 | @findex FILENAME_CMP | |
4463 | @item FILENAME_CMP (@var{f1}, @var{f2}) | |
4464 | Calls a function which compares file names @var{f1} and @var{f2} as | |
4465 | appropriate for the underlying host filesystem. For Posix systems, | |
4466 | this simply calls @code{strcmp}; on case-insensitive filesystems it | |
4467 | will call @code{strcasecmp} instead. | |
4468 | ||
4469 | @findex DIRNAME_SEPARATOR | |
4470 | @item DIRNAME_SEPARATOR | |
4471 | Evaluates to a character which separates directories in | |
4472 | @code{PATH}-style lists, typically held in environment variables. | |
4473 | This character is @samp{:} on Unix, @samp{;} on DOS and Windows. | |
4474 | ||
4475 | @findex SLASH_STRING | |
4476 | @item SLASH_STRING | |
4477 | This evaluates to a constant string you should use to produce an | |
4478 | absolute filename from leading directories and the file's basename. | |
4479 | @code{SLASH_STRING} is @code{"/"} on most systems, but might be | |
4480 | @code{"\\"} for some Windows-based ports. | |
4481 | @end table | |
4482 | ||
4483 | In addition to using these macros, be sure to use portable library | |
4484 | functions whenever possible. For example, to extract a directory or a | |
4485 | basename part from a file name, use the @code{dirname} and | |
4486 | @code{basename} library functions (available in @code{libiberty} for | |
4487 | platforms which don't provide them), instead of searching for a slash | |
4488 | with @code{strrchr}. | |
4489 | ||
25822942 DB |
4490 | Another way to generalize @value{GDBN} along a particular interface is with an |
4491 | attribute struct. For example, @value{GDBN} has been generalized to handle | |
56caf160 EZ |
4492 | multiple kinds of remote interfaces---not by @code{#ifdef}s everywhere, but |
4493 | by defining the @code{target_ops} structure and having a current target (as | |
c906108c SS |
4494 | well as a stack of targets below it, for memory references). Whenever |
4495 | something needs to be done that depends on which remote interface we are | |
56caf160 EZ |
4496 | using, a flag in the current target_ops structure is tested (e.g., |
4497 | @code{target_has_stack}), or a function is called through a pointer in the | |
c906108c | 4498 | current target_ops structure. In this way, when a new remote interface |
56caf160 | 4499 | is added, only one module needs to be touched---the one that actually |
c906108c SS |
4500 | implements the new remote interface. Other examples of |
4501 | attribute-structs are BFD access to multiple kinds of object file | |
25822942 | 4502 | formats, or @value{GDBN}'s access to multiple source languages. |
c906108c | 4503 | |
56caf160 EZ |
4504 | Please avoid duplicating code. For example, in @value{GDBN} 3.x all |
4505 | the code interfacing between @code{ptrace} and the rest of | |
4506 | @value{GDBN} was duplicated in @file{*-dep.c}, and so changing | |
4507 | something was very painful. In @value{GDBN} 4.x, these have all been | |
4508 | consolidated into @file{infptrace.c}. @file{infptrace.c} can deal | |
4509 | with variations between systems the same way any system-independent | |
4510 | file would (hooks, @code{#if defined}, etc.), and machines which are | |
4511 | radically different don't need to use @file{infptrace.c} at all. | |
c906108c | 4512 | |
af6c57ea AC |
4513 | All debugging code must be controllable using the @samp{set debug |
4514 | @var{module}} command. Do not use @code{printf} to print trace | |
4515 | messages. Use @code{fprintf_unfiltered(gdb_stdlog, ...}. Do not use | |
4516 | @code{#ifdef DEBUG}. | |
4517 | ||
c906108c | 4518 | |
8487521e | 4519 | @node Porting GDB |
c906108c | 4520 | |
25822942 | 4521 | @chapter Porting @value{GDBN} |
56caf160 | 4522 | @cindex porting to new machines |
c906108c | 4523 | |
56caf160 EZ |
4524 | Most of the work in making @value{GDBN} compile on a new machine is in |
4525 | specifying the configuration of the machine. This is done in a | |
4526 | dizzying variety of header files and configuration scripts, which we | |
4527 | hope to make more sensible soon. Let's say your new host is called an | |
4528 | @var{xyz} (e.g., @samp{sun4}), and its full three-part configuration | |
4529 | name is @code{@var{arch}-@var{xvend}-@var{xos}} (e.g., | |
4530 | @samp{sparc-sun-sunos4}). In particular: | |
c906108c | 4531 | |
56caf160 EZ |
4532 | @itemize @bullet |
4533 | @item | |
c906108c SS |
4534 | In the top level directory, edit @file{config.sub} and add @var{arch}, |
4535 | @var{xvend}, and @var{xos} to the lists of supported architectures, | |
4536 | vendors, and operating systems near the bottom of the file. Also, add | |
4537 | @var{xyz} as an alias that maps to | |
4538 | @code{@var{arch}-@var{xvend}-@var{xos}}. You can test your changes by | |
4539 | running | |
4540 | ||
4541 | @example | |
4542 | ./config.sub @var{xyz} | |
4543 | @end example | |
56caf160 | 4544 | |
c906108c SS |
4545 | @noindent |
4546 | and | |
56caf160 | 4547 | |
c906108c SS |
4548 | @example |
4549 | ./config.sub @code{@var{arch}-@var{xvend}-@var{xos}} | |
4550 | @end example | |
56caf160 | 4551 | |
c906108c SS |
4552 | @noindent |
4553 | which should both respond with @code{@var{arch}-@var{xvend}-@var{xos}} | |
4554 | and no error messages. | |
4555 | ||
56caf160 | 4556 | @noindent |
c906108c SS |
4557 | You need to port BFD, if that hasn't been done already. Porting BFD is |
4558 | beyond the scope of this manual. | |
4559 | ||
56caf160 | 4560 | @item |
25822942 | 4561 | To configure @value{GDBN} itself, edit @file{gdb/configure.host} to recognize |
c906108c SS |
4562 | your system and set @code{gdb_host} to @var{xyz}, and (unless your |
4563 | desired target is already available) also edit @file{gdb/configure.tgt}, | |
4564 | setting @code{gdb_target} to something appropriate (for instance, | |
4565 | @var{xyz}). | |
4566 | ||
56caf160 | 4567 | @item |
25822942 | 4568 | Finally, you'll need to specify and define @value{GDBN}'s host-, native-, and |
c906108c SS |
4569 | target-dependent @file{.h} and @file{.c} files used for your |
4570 | configuration. | |
56caf160 | 4571 | @end itemize |
c906108c | 4572 | |
25822942 | 4573 | @section Configuring @value{GDBN} for Release |
c906108c | 4574 | |
56caf160 EZ |
4575 | @cindex preparing a release |
4576 | @cindex making a distribution tarball | |
c906108c SS |
4577 | From the top level directory (containing @file{gdb}, @file{bfd}, |
4578 | @file{libiberty}, and so on): | |
56caf160 | 4579 | |
c906108c SS |
4580 | @example |
4581 | make -f Makefile.in gdb.tar.gz | |
4582 | @end example | |
4583 | ||
56caf160 | 4584 | @noindent |
c906108c SS |
4585 | This will properly configure, clean, rebuild any files that are |
4586 | distributed pre-built (e.g. @file{c-exp.tab.c} or @file{refcard.ps}), | |
4587 | and will then make a tarfile. (If the top level directory has already | |
4588 | been configured, you can just do @code{make gdb.tar.gz} instead.) | |
4589 | ||
4590 | This procedure requires: | |
56caf160 | 4591 | |
c906108c | 4592 | @itemize @bullet |
56caf160 EZ |
4593 | |
4594 | @item | |
4595 | symbolic links; | |
4596 | ||
4597 | @item | |
4598 | @code{makeinfo} (texinfo2 level); | |
4599 | ||
4600 | @item | |
4601 | @TeX{}; | |
4602 | ||
4603 | @item | |
4604 | @code{dvips}; | |
4605 | ||
4606 | @item | |
4607 | @code{yacc} or @code{bison}. | |
c906108c | 4608 | @end itemize |
56caf160 | 4609 | |
c906108c SS |
4610 | @noindent |
4611 | @dots{} and the usual slew of utilities (@code{sed}, @code{tar}, etc.). | |
4612 | ||
4613 | @subheading TEMPORARY RELEASE PROCEDURE FOR DOCUMENTATION | |
4614 | ||
4615 | @file{gdb.texinfo} is currently marked up using the texinfo-2 macros, | |
4616 | which are not yet a default for anything (but we have to start using | |
4617 | them sometime). | |
4618 | ||
4619 | For making paper, the only thing this implies is the right generation of | |
4620 | @file{texinfo.tex} needs to be included in the distribution. | |
4621 | ||
4622 | For making info files, however, rather than duplicating the texinfo2 | |
4623 | distribution, generate @file{gdb-all.texinfo} locally, and include the | |
4624 | files @file{gdb.info*} in the distribution. Note the plural; | |
4625 | @code{makeinfo} will split the document into one overall file and five | |
4626 | or so included files. | |
4627 | ||
085dd6e6 JM |
4628 | @node Testsuite |
4629 | ||
4630 | @chapter Testsuite | |
56caf160 | 4631 | @cindex test suite |
085dd6e6 | 4632 | |
56caf160 EZ |
4633 | The testsuite is an important component of the @value{GDBN} package. |
4634 | While it is always worthwhile to encourage user testing, in practice | |
4635 | this is rarely sufficient; users typically use only a small subset of | |
4636 | the available commands, and it has proven all too common for a change | |
4637 | to cause a significant regression that went unnoticed for some time. | |
085dd6e6 | 4638 | |
56caf160 EZ |
4639 | The @value{GDBN} testsuite uses the DejaGNU testing framework. |
4640 | DejaGNU is built using @code{Tcl} and @code{expect}. The tests | |
4641 | themselves are calls to various @code{Tcl} procs; the framework runs all the | |
4642 | procs and summarizes the passes and fails. | |
085dd6e6 JM |
4643 | |
4644 | @section Using the Testsuite | |
4645 | ||
56caf160 | 4646 | @cindex running the test suite |
25822942 | 4647 | To run the testsuite, simply go to the @value{GDBN} object directory (or to the |
085dd6e6 JM |
4648 | testsuite's objdir) and type @code{make check}. This just sets up some |
4649 | environment variables and invokes DejaGNU's @code{runtest} script. While | |
4650 | the testsuite is running, you'll get mentions of which test file is in use, | |
4651 | and a mention of any unexpected passes or fails. When the testsuite is | |
4652 | finished, you'll get a summary that looks like this: | |
56caf160 | 4653 | |
085dd6e6 JM |
4654 | @example |
4655 | === gdb Summary === | |
4656 | ||
4657 | # of expected passes 6016 | |
4658 | # of unexpected failures 58 | |
4659 | # of unexpected successes 5 | |
4660 | # of expected failures 183 | |
4661 | # of unresolved testcases 3 | |
4662 | # of untested testcases 5 | |
4663 | @end example | |
56caf160 | 4664 | |
085dd6e6 JM |
4665 | The ideal test run consists of expected passes only; however, reality |
4666 | conspires to keep us from this ideal. Unexpected failures indicate | |
56caf160 EZ |
4667 | real problems, whether in @value{GDBN} or in the testsuite. Expected |
4668 | failures are still failures, but ones which have been decided are too | |
4669 | hard to deal with at the time; for instance, a test case might work | |
4670 | everywhere except on AIX, and there is no prospect of the AIX case | |
4671 | being fixed in the near future. Expected failures should not be added | |
4672 | lightly, since you may be masking serious bugs in @value{GDBN}. | |
4673 | Unexpected successes are expected fails that are passing for some | |
4674 | reason, while unresolved and untested cases often indicate some minor | |
4675 | catastrophe, such as the compiler being unable to deal with a test | |
4676 | program. | |
4677 | ||
4678 | When making any significant change to @value{GDBN}, you should run the | |
4679 | testsuite before and after the change, to confirm that there are no | |
4680 | regressions. Note that truly complete testing would require that you | |
4681 | run the testsuite with all supported configurations and a variety of | |
4682 | compilers; however this is more than really necessary. In many cases | |
4683 | testing with a single configuration is sufficient. Other useful | |
4684 | options are to test one big-endian (Sparc) and one little-endian (x86) | |
4685 | host, a cross config with a builtin simulator (powerpc-eabi, | |
4686 | mips-elf), or a 64-bit host (Alpha). | |
4687 | ||
4688 | If you add new functionality to @value{GDBN}, please consider adding | |
4689 | tests for it as well; this way future @value{GDBN} hackers can detect | |
4690 | and fix their changes that break the functionality you added. | |
4691 | Similarly, if you fix a bug that was not previously reported as a test | |
4692 | failure, please add a test case for it. Some cases are extremely | |
4693 | difficult to test, such as code that handles host OS failures or bugs | |
4694 | in particular versions of compilers, and it's OK not to try to write | |
4695 | tests for all of those. | |
085dd6e6 JM |
4696 | |
4697 | @section Testsuite Organization | |
4698 | ||
56caf160 | 4699 | @cindex test suite organization |
085dd6e6 JM |
4700 | The testsuite is entirely contained in @file{gdb/testsuite}. While the |
4701 | testsuite includes some makefiles and configury, these are very minimal, | |
4702 | and used for little besides cleaning up, since the tests themselves | |
25822942 | 4703 | handle the compilation of the programs that @value{GDBN} will run. The file |
085dd6e6 | 4704 | @file{testsuite/lib/gdb.exp} contains common utility procs useful for |
25822942 | 4705 | all @value{GDBN} tests, while the directory @file{testsuite/config} contains |
085dd6e6 JM |
4706 | configuration-specific files, typically used for special-purpose |
4707 | definitions of procs like @code{gdb_load} and @code{gdb_start}. | |
4708 | ||
4709 | The tests themselves are to be found in @file{testsuite/gdb.*} and | |
4710 | subdirectories of those. The names of the test files must always end | |
4711 | with @file{.exp}. DejaGNU collects the test files by wildcarding | |
4712 | in the test directories, so both subdirectories and individual files | |
4713 | get chosen and run in alphabetical order. | |
4714 | ||
4715 | The following table lists the main types of subdirectories and what they | |
4716 | are for. Since DejaGNU finds test files no matter where they are | |
4717 | located, and since each test file sets up its own compilation and | |
4718 | execution environment, this organization is simply for convenience and | |
4719 | intelligibility. | |
4720 | ||
56caf160 | 4721 | @table @file |
085dd6e6 | 4722 | @item gdb.base |
085dd6e6 | 4723 | This is the base testsuite. The tests in it should apply to all |
25822942 | 4724 | configurations of @value{GDBN} (but generic native-only tests may live here). |
085dd6e6 | 4725 | The test programs should be in the subset of C that is valid K&R, |
56caf160 | 4726 | ANSI/ISO, and C++ (@code{#ifdef}s are allowed if necessary, for instance |
085dd6e6 JM |
4727 | for prototypes). |
4728 | ||
4729 | @item gdb.@var{lang} | |
56caf160 | 4730 | Language-specific tests for any language @var{lang} besides C. Examples are |
085dd6e6 JM |
4731 | @file{gdb.c++} and @file{gdb.java}. |
4732 | ||
4733 | @item gdb.@var{platform} | |
085dd6e6 JM |
4734 | Non-portable tests. The tests are specific to a specific configuration |
4735 | (host or target), such as HP-UX or eCos. Example is @file{gdb.hp}, for | |
4736 | HP-UX. | |
4737 | ||
4738 | @item gdb.@var{compiler} | |
085dd6e6 JM |
4739 | Tests specific to a particular compiler. As of this writing (June |
4740 | 1999), there aren't currently any groups of tests in this category that | |
4741 | couldn't just as sensibly be made platform-specific, but one could | |
56caf160 EZ |
4742 | imagine a @file{gdb.gcc}, for tests of @value{GDBN}'s handling of GCC |
4743 | extensions. | |
085dd6e6 JM |
4744 | |
4745 | @item gdb.@var{subsystem} | |
25822942 | 4746 | Tests that exercise a specific @value{GDBN} subsystem in more depth. For |
085dd6e6 JM |
4747 | instance, @file{gdb.disasm} exercises various disassemblers, while |
4748 | @file{gdb.stabs} tests pathways through the stabs symbol reader. | |
085dd6e6 JM |
4749 | @end table |
4750 | ||
4751 | @section Writing Tests | |
56caf160 | 4752 | @cindex writing tests |
085dd6e6 | 4753 | |
25822942 | 4754 | In many areas, the @value{GDBN} tests are already quite comprehensive; you |
085dd6e6 JM |
4755 | should be able to copy existing tests to handle new cases. |
4756 | ||
4757 | You should try to use @code{gdb_test} whenever possible, since it | |
4758 | includes cases to handle all the unexpected errors that might happen. | |
4759 | However, it doesn't cost anything to add new test procedures; for | |
4760 | instance, @file{gdb.base/exprs.exp} defines a @code{test_expr} that | |
4761 | calls @code{gdb_test} multiple times. | |
4762 | ||
4763 | Only use @code{send_gdb} and @code{gdb_expect} when absolutely | |
25822942 | 4764 | necessary, such as when @value{GDBN} has several valid responses to a command. |
085dd6e6 JM |
4765 | |
4766 | The source language programs do @emph{not} need to be in a consistent | |
25822942 | 4767 | style. Since @value{GDBN} is used to debug programs written in many different |
085dd6e6 | 4768 | styles, it's worth having a mix of styles in the testsuite; for |
25822942 | 4769 | instance, some @value{GDBN} bugs involving the display of source lines would |
085dd6e6 JM |
4770 | never manifest themselves if the programs used GNU coding style |
4771 | uniformly. | |
4772 | ||
c906108c SS |
4773 | @node Hints |
4774 | ||
4775 | @chapter Hints | |
4776 | ||
4777 | Check the @file{README} file, it often has useful information that does not | |
4778 | appear anywhere else in the directory. | |
4779 | ||
4780 | @menu | |
25822942 | 4781 | * Getting Started:: Getting started working on @value{GDBN} |
33e16fad | 4782 | * Debugging GDB:: Debugging @value{GDBN} with itself |
c906108c SS |
4783 | @end menu |
4784 | ||
4785 | @node Getting Started,,, Hints | |
4786 | ||
4787 | @section Getting Started | |
4788 | ||
25822942 | 4789 | @value{GDBN} is a large and complicated program, and if you first starting to |
c906108c SS |
4790 | work on it, it can be hard to know where to start. Fortunately, if you |
4791 | know how to go about it, there are ways to figure out what is going on. | |
4792 | ||
25822942 DB |
4793 | This manual, the @value{GDBN} Internals manual, has information which applies |
4794 | generally to many parts of @value{GDBN}. | |
c906108c SS |
4795 | |
4796 | Information about particular functions or data structures are located in | |
4797 | comments with those functions or data structures. If you run across a | |
4798 | function or a global variable which does not have a comment correctly | |
25822942 | 4799 | explaining what is does, this can be thought of as a bug in @value{GDBN}; feel |
c906108c SS |
4800 | free to submit a bug report, with a suggested comment if you can figure |
4801 | out what the comment should say. If you find a comment which is | |
4802 | actually wrong, be especially sure to report that. | |
4803 | ||
4804 | Comments explaining the function of macros defined in host, target, or | |
4805 | native dependent files can be in several places. Sometimes they are | |
4806 | repeated every place the macro is defined. Sometimes they are where the | |
4807 | macro is used. Sometimes there is a header file which supplies a | |
4808 | default definition of the macro, and the comment is there. This manual | |
4809 | also documents all the available macros. | |
4810 | @c (@pxref{Host Conditionals}, @pxref{Target | |
4811 | @c Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete | |
4812 | @c Conditionals}) | |
4813 | ||
56caf160 EZ |
4814 | Start with the header files. Once you have some idea of how |
4815 | @value{GDBN}'s internal symbol tables are stored (see @file{symtab.h}, | |
4816 | @file{gdbtypes.h}), you will find it much easier to understand the | |
4817 | code which uses and creates those symbol tables. | |
c906108c SS |
4818 | |
4819 | You may wish to process the information you are getting somehow, to | |
4820 | enhance your understanding of it. Summarize it, translate it to another | |
25822942 | 4821 | language, add some (perhaps trivial or non-useful) feature to @value{GDBN}, use |
c906108c SS |
4822 | the code to predict what a test case would do and write the test case |
4823 | and verify your prediction, etc. If you are reading code and your eyes | |
4824 | are starting to glaze over, this is a sign you need to use a more active | |
4825 | approach. | |
4826 | ||
25822942 | 4827 | Once you have a part of @value{GDBN} to start with, you can find more |
c906108c SS |
4828 | specifically the part you are looking for by stepping through each |
4829 | function with the @code{next} command. Do not use @code{step} or you | |
4830 | will quickly get distracted; when the function you are stepping through | |
4831 | calls another function try only to get a big-picture understanding | |
4832 | (perhaps using the comment at the beginning of the function being | |
4833 | called) of what it does. This way you can identify which of the | |
4834 | functions being called by the function you are stepping through is the | |
4835 | one which you are interested in. You may need to examine the data | |
4836 | structures generated at each stage, with reference to the comments in | |
4837 | the header files explaining what the data structures are supposed to | |
4838 | look like. | |
4839 | ||
4840 | Of course, this same technique can be used if you are just reading the | |
4841 | code, rather than actually stepping through it. The same general | |
4842 | principle applies---when the code you are looking at calls something | |
4843 | else, just try to understand generally what the code being called does, | |
4844 | rather than worrying about all its details. | |
4845 | ||
56caf160 EZ |
4846 | @cindex command implementation |
4847 | A good place to start when tracking down some particular area is with | |
4848 | a command which invokes that feature. Suppose you want to know how | |
4849 | single-stepping works. As a @value{GDBN} user, you know that the | |
4850 | @code{step} command invokes single-stepping. The command is invoked | |
4851 | via command tables (see @file{command.h}); by convention the function | |
4852 | which actually performs the command is formed by taking the name of | |
4853 | the command and adding @samp{_command}, or in the case of an | |
4854 | @code{info} subcommand, @samp{_info}. For example, the @code{step} | |
4855 | command invokes the @code{step_command} function and the @code{info | |
4856 | display} command invokes @code{display_info}. When this convention is | |
4857 | not followed, you might have to use @code{grep} or @kbd{M-x | |
4858 | tags-search} in emacs, or run @value{GDBN} on itself and set a | |
4859 | breakpoint in @code{execute_command}. | |
4860 | ||
4861 | @cindex @code{bug-gdb} mailing list | |
c906108c SS |
4862 | If all of the above fail, it may be appropriate to ask for information |
4863 | on @code{bug-gdb}. But @emph{never} post a generic question like ``I was | |
4864 | wondering if anyone could give me some tips about understanding | |
25822942 | 4865 | @value{GDBN}''---if we had some magic secret we would put it in this manual. |
c906108c SS |
4866 | Suggestions for improving the manual are always welcome, of course. |
4867 | ||
33e16fad | 4868 | @node Debugging GDB,,,Hints |
c906108c | 4869 | |
25822942 | 4870 | @section Debugging @value{GDBN} with itself |
56caf160 | 4871 | @cindex debugging @value{GDBN} |
c906108c | 4872 | |
25822942 | 4873 | If @value{GDBN} is limping on your machine, this is the preferred way to get it |
c906108c SS |
4874 | fully functional. Be warned that in some ancient Unix systems, like |
4875 | Ultrix 4.2, a program can't be running in one process while it is being | |
56caf160 | 4876 | debugged in another. Rather than typing the command @kbd{@w{./gdb |
c906108c | 4877 | ./gdb}}, which works on Suns and such, you can copy @file{gdb} to |
56caf160 | 4878 | @file{gdb2} and then type @kbd{@w{./gdb ./gdb2}}. |
c906108c | 4879 | |
25822942 | 4880 | When you run @value{GDBN} in the @value{GDBN} source directory, it will read a |
c906108c SS |
4881 | @file{.gdbinit} file that sets up some simple things to make debugging |
4882 | gdb easier. The @code{info} command, when executed without a subcommand | |
25822942 | 4883 | in a @value{GDBN} being debugged by gdb, will pop you back up to the top level |
c906108c SS |
4884 | gdb. See @file{.gdbinit} for details. |
4885 | ||
4886 | If you use emacs, you will probably want to do a @code{make TAGS} after | |
4887 | you configure your distribution; this will put the machine dependent | |
4888 | routines for your local machine where they will be accessed first by | |
4889 | @kbd{M-.} | |
4890 | ||
25822942 | 4891 | Also, make sure that you've either compiled @value{GDBN} with your local cc, or |
c906108c SS |
4892 | have run @code{fixincludes} if you are compiling with gcc. |
4893 | ||
4894 | @section Submitting Patches | |
4895 | ||
56caf160 | 4896 | @cindex submitting patches |
c906108c | 4897 | Thanks for thinking of offering your changes back to the community of |
25822942 | 4898 | @value{GDBN} users. In general we like to get well designed enhancements. |
c906108c SS |
4899 | Thanks also for checking in advance about the best way to transfer the |
4900 | changes. | |
4901 | ||
25822942 DB |
4902 | The @value{GDBN} maintainers will only install ``cleanly designed'' patches. |
4903 | This manual summarizes what we believe to be clean design for @value{GDBN}. | |
c906108c SS |
4904 | |
4905 | If the maintainers don't have time to put the patch in when it arrives, | |
4906 | or if there is any question about a patch, it goes into a large queue | |
4907 | with everyone else's patches and bug reports. | |
4908 | ||
56caf160 | 4909 | @cindex legal papers for code contributions |
c906108c SS |
4910 | The legal issue is that to incorporate substantial changes requires a |
4911 | copyright assignment from you and/or your employer, granting ownership | |
4912 | of the changes to the Free Software Foundation. You can get the | |
9e0b60a8 JM |
4913 | standard documents for doing this by sending mail to @code{gnu@@gnu.org} |
4914 | and asking for it. We recommend that people write in "All programs | |
4915 | owned by the Free Software Foundation" as "NAME OF PROGRAM", so that | |
56caf160 EZ |
4916 | changes in many programs (not just @value{GDBN}, but GAS, Emacs, GCC, |
4917 | etc) can be | |
9e0b60a8 | 4918 | contributed with only one piece of legalese pushed through the |
be9c6c35 | 4919 | bureaucracy and filed with the FSF. We can't start merging changes until |
9e0b60a8 JM |
4920 | this paperwork is received by the FSF (their rules, which we follow |
4921 | since we maintain it for them). | |
c906108c SS |
4922 | |
4923 | Technically, the easiest way to receive changes is to receive each | |
56caf160 EZ |
4924 | feature as a small context diff or unidiff, suitable for @code{patch}. |
4925 | Each message sent to me should include the changes to C code and | |
4926 | header files for a single feature, plus @file{ChangeLog} entries for | |
4927 | each directory where files were modified, and diffs for any changes | |
4928 | needed to the manuals (@file{gdb/doc/gdb.texinfo} or | |
4929 | @file{gdb/doc/gdbint.texinfo}). If there are a lot of changes for a | |
4930 | single feature, they can be split down into multiple messages. | |
9e0b60a8 JM |
4931 | |
4932 | In this way, if we read and like the feature, we can add it to the | |
c906108c | 4933 | sources with a single patch command, do some testing, and check it in. |
56caf160 EZ |
4934 | If you leave out the @file{ChangeLog}, we have to write one. If you leave |
4935 | out the doc, we have to puzzle out what needs documenting. Etc., etc. | |
c906108c | 4936 | |
9e0b60a8 JM |
4937 | The reason to send each change in a separate message is that we will not |
4938 | install some of the changes. They'll be returned to you with questions | |
4939 | or comments. If we're doing our job correctly, the message back to you | |
c906108c | 4940 | will say what you have to fix in order to make the change acceptable. |
9e0b60a8 JM |
4941 | The reason to have separate messages for separate features is so that |
4942 | the acceptable changes can be installed while one or more changes are | |
4943 | being reworked. If multiple features are sent in a single message, we | |
4944 | tend to not put in the effort to sort out the acceptable changes from | |
4945 | the unacceptable, so none of the features get installed until all are | |
4946 | acceptable. | |
4947 | ||
4948 | If this sounds painful or authoritarian, well, it is. But we get a lot | |
4949 | of bug reports and a lot of patches, and many of them don't get | |
4950 | installed because we don't have the time to finish the job that the bug | |
c906108c SS |
4951 | reporter or the contributor could have done. Patches that arrive |
4952 | complete, working, and well designed, tend to get installed on the day | |
9e0b60a8 JM |
4953 | they arrive. The others go into a queue and get installed as time |
4954 | permits, which, since the maintainers have many demands to meet, may not | |
4955 | be for quite some time. | |
c906108c | 4956 | |
56caf160 EZ |
4957 | Please send patches directly to |
4958 | @email{gdb-patches@@sourceware.cygnus.com, the @value{GDBN} maintainers}. | |
c906108c SS |
4959 | |
4960 | @section Obsolete Conditionals | |
56caf160 | 4961 | @cindex obsolete code |
c906108c | 4962 | |
25822942 | 4963 | Fragments of old code in @value{GDBN} sometimes reference or set the following |
c906108c SS |
4964 | configuration macros. They should not be used by new code, and old uses |
4965 | should be removed as those parts of the debugger are otherwise touched. | |
4966 | ||
4967 | @table @code | |
c906108c SS |
4968 | @item STACK_END_ADDR |
4969 | This macro used to define where the end of the stack appeared, for use | |
4970 | in interpreting core file formats that don't record this address in the | |
25822942 DB |
4971 | core file itself. This information is now configured in BFD, and @value{GDBN} |
4972 | gets the info portably from there. The values in @value{GDBN}'s configuration | |
c906108c | 4973 | files should be moved into BFD configuration files (if needed there), |
25822942 | 4974 | and deleted from all of @value{GDBN}'s config files. |
c906108c SS |
4975 | |
4976 | Any @file{@var{foo}-xdep.c} file that references STACK_END_ADDR | |
4977 | is so old that it has never been converted to use BFD. Now that's old! | |
4978 | ||
4979 | @item PYRAMID_CONTROL_FRAME_DEBUGGING | |
4980 | pyr-xdep.c | |
4981 | @item PYRAMID_CORE | |
4982 | pyr-xdep.c | |
4983 | @item PYRAMID_PTRACE | |
4984 | pyr-xdep.c | |
4985 | ||
4986 | @item REG_STACK_SEGMENT | |
4987 | exec.c | |
4988 | ||
4989 | @end table | |
4990 | ||
56caf160 EZ |
4991 | @node Index |
4992 | @unnumbered Index | |
4993 | ||
4994 | @printindex cp | |
4995 | ||
449f3b6c AC |
4996 | @c TeX can handle the contents at the start but makeinfo 3.12 can not |
4997 | @ifinfo | |
c906108c | 4998 | @contents |
449f3b6c AC |
4999 | @end ifinfo |
5000 | @ifhtml | |
5001 | @contents | |
5002 | @end ifhtml | |
5003 | ||
c906108c | 5004 | @bye |