1 |
106 |
markom |
This is gdbint.info, produced by Makeinfo version 3.12f from
|
2 |
|
|
./gdbint.texinfo.
|
3 |
|
|
|
4 |
|
|
START-INFO-DIR-ENTRY
|
5 |
|
|
* Gdb-Internals: (gdbint). The GNU debugger's internals.
|
6 |
|
|
END-INFO-DIR-ENTRY
|
7 |
|
|
|
8 |
|
|
This file documents the internals of the GNU debugger GDB.
|
9 |
|
|
|
10 |
|
|
Copyright 1990-1999 Free Software Foundation, Inc. Contributed by
|
11 |
|
|
Cygnus Solutions. Written by John Gilmore. Second Edition by Stan
|
12 |
|
|
Shebs.
|
13 |
|
|
|
14 |
|
|
Permission is granted to make and distribute verbatim copies of this
|
15 |
|
|
manual provided the copyright notice and this permission notice are
|
16 |
|
|
preserved on all copies.
|
17 |
|
|
|
18 |
|
|
Permission is granted to copy or distribute modified versions of this
|
19 |
|
|
manual under the terms of the GPL (for which purpose this text may be
|
20 |
|
|
regarded as a program in the language TeX).
|
21 |
|
|
|
22 |
|
|
|
23 |
|
|
File: gdbint.info, Node: Target Architecture Definition, Next: Target Vector Definition, Prev: Host Definition, Up: Top
|
24 |
|
|
|
25 |
|
|
Target Architecture Definition
|
26 |
|
|
******************************
|
27 |
|
|
|
28 |
|
|
GDB's target architecture defines what sort of machine-language
|
29 |
|
|
programs GDB can work with, and how it works with them.
|
30 |
|
|
|
31 |
|
|
At present, the target architecture definition consists of a number
|
32 |
|
|
of C macros.
|
33 |
|
|
|
34 |
|
|
Registers and Memory
|
35 |
|
|
====================
|
36 |
|
|
|
37 |
|
|
GDB's model of the target machine is rather simple. GDB assumes the
|
38 |
|
|
machine includes a bank of registers and a block of memory. Each
|
39 |
|
|
register may have a different size.
|
40 |
|
|
|
41 |
|
|
GDB does not have a magical way to match up with the compiler's idea
|
42 |
|
|
of which registers are which; however, it is critical that they do
|
43 |
|
|
match up accurately. The only way to make this work is to get accurate
|
44 |
|
|
information about the order that the compiler uses, and to reflect that
|
45 |
|
|
in the `REGISTER_NAME' and related macros.
|
46 |
|
|
|
47 |
|
|
GDB can handle big-endian, little-endian, and bi-endian
|
48 |
|
|
architectures.
|
49 |
|
|
|
50 |
|
|
Using Different Register and Memory Data Representations
|
51 |
|
|
========================================================
|
52 |
|
|
|
53 |
|
|
Some architectures use one representation for a value when it lives
|
54 |
|
|
in a register, but use a different representation when it lives in
|
55 |
|
|
memory. In GDB's terminology, the "raw" representation is the one used
|
56 |
|
|
in the target registers, and the "virtual" representation is the one
|
57 |
|
|
used in memory, and within GDB `struct value' objects.
|
58 |
|
|
|
59 |
|
|
For almost all data types on almost all architectures, the virtual
|
60 |
|
|
and raw representations are identical, and no special handling is
|
61 |
|
|
needed. However, they do occasionally differ. For example:
|
62 |
|
|
|
63 |
|
|
* The x86 architecture supports an 80-bit long double type.
|
64 |
|
|
However, when we store those values in memory, they occupy twelve
|
65 |
|
|
bytes: the floating-point number occupies the first ten, and the
|
66 |
|
|
final two bytes are unused. This keeps the values aligned on
|
67 |
|
|
four-byte boundaries, allowing more efficient access. Thus, the
|
68 |
|
|
x86 80-bit floating-point type is the raw representation, and the
|
69 |
|
|
twelve-byte loosely-packed arrangement is the virtual
|
70 |
|
|
representation.
|
71 |
|
|
|
72 |
|
|
* Some 64-bit MIPS targets present 32-bit registers to GDB as 64-bit
|
73 |
|
|
registers, with garbage in their upper bits. GDB ignores the top
|
74 |
|
|
32 bits. Thus, the 64-bit form, with garbage in the upper 32
|
75 |
|
|
bits, is the raw representation, and the trimmed 32-bit
|
76 |
|
|
representation is the virtual representation.
|
77 |
|
|
|
78 |
|
|
|
79 |
|
|
In general, the raw representation is determined by the
|
80 |
|
|
architecture, or GDB's interface to the architecture, while the virtual
|
81 |
|
|
representation can be chosen for GDB's convenience. GDB's register
|
82 |
|
|
file, `registers', holds the register contents in raw format, and the
|
83 |
|
|
GDB remote protocol transmits register values in raw format.
|
84 |
|
|
|
85 |
|
|
Your architecture may define the following macros to request raw /
|
86 |
|
|
virtual conversions:
|
87 |
|
|
|
88 |
|
|
- Target Macro: int REGISTER_CONVERTIBLE (int REG)
|
89 |
|
|
Return non-zero if register number REG's value needs different raw
|
90 |
|
|
and virtual formats.
|
91 |
|
|
|
92 |
|
|
- Target Macro: int REGISTER_RAW_SIZE (int REG)
|
93 |
|
|
The size of register number REG's raw value. This is the number
|
94 |
|
|
of bytes the register will occupy in `registers', or in a GDB
|
95 |
|
|
remote protocol packet.
|
96 |
|
|
|
97 |
|
|
- Target Macro: int REGISTER_VIRTUAL_SIZE (int REG)
|
98 |
|
|
The size of register number REG's value, in its virtual format.
|
99 |
|
|
This is the size a `struct value''s buffer will have, holding that
|
100 |
|
|
register's value.
|
101 |
|
|
|
102 |
|
|
- Target Macro: struct type *REGISTER_VIRTUAL_TYPE (int REG)
|
103 |
|
|
This is the type of the virtual representation of register number
|
104 |
|
|
REG. Note that there is no need for a macro giving a type for the
|
105 |
|
|
register's raw form; once the register's value has been obtained,
|
106 |
|
|
GDB always uses the virtual form.
|
107 |
|
|
|
108 |
|
|
- Target Macro: void REGISTER_CONVERT_TO_VIRTUAL (int REG, struct type
|
109 |
|
|
*TYPE, char *FROM, char *TO)
|
110 |
|
|
Convert the value of register number REG to TYPE, which should
|
111 |
|
|
always be `REGISTER_VIRTUAL_TYPE (REG)'. The buffer at FROM holds
|
112 |
|
|
the register's value in raw format; the macro should convert the
|
113 |
|
|
value to virtual format, and place it at TO.
|
114 |
|
|
|
115 |
|
|
Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW
|
116 |
|
|
take their REG and TYPE arguments in different orders.
|
117 |
|
|
|
118 |
|
|
- Target Macro: void REGISTER_CONVERT_TO_RAW (struct type *TYPE, int
|
119 |
|
|
REG, char *FROM, char *TO)
|
120 |
|
|
Convert the value of register number REG to TYPE, which should
|
121 |
|
|
always be `REGISTER_VIRTUAL_TYPE (REG)'. The buffer at FROM holds
|
122 |
|
|
the register's value in raw format; the macro should convert the
|
123 |
|
|
value to virtual format, and place it at TO.
|
124 |
|
|
|
125 |
|
|
Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW
|
126 |
|
|
take their REG and TYPE arguments in different orders.
|
127 |
|
|
|
128 |
|
|
Frame Interpretation
|
129 |
|
|
====================
|
130 |
|
|
|
131 |
|
|
Inferior Call Setup
|
132 |
|
|
===================
|
133 |
|
|
|
134 |
|
|
Compiler Characteristics
|
135 |
|
|
========================
|
136 |
|
|
|
137 |
|
|
Target Conditionals
|
138 |
|
|
===================
|
139 |
|
|
|
140 |
|
|
This section describes the macros that you can use to define the
|
141 |
|
|
target machine.
|
142 |
|
|
|
143 |
|
|
`ADDITIONAL_OPTIONS'
|
144 |
|
|
|
145 |
|
|
`ADDITIONAL_OPTION_CASES'
|
146 |
|
|
|
147 |
|
|
`ADDITIONAL_OPTION_HANDLER'
|
148 |
|
|
|
149 |
|
|
`ADDITIONAL_OPTION_HELP'
|
150 |
|
|
These are a set of macros that allow the addition of additional
|
151 |
|
|
command line options to GDB. They are currently used only for the
|
152 |
|
|
unsupported i960 Nindy target, and should not be used in any other
|
153 |
|
|
configuration.
|
154 |
|
|
|
155 |
|
|
`ADDR_BITS_REMOVE (addr)'
|
156 |
|
|
If a raw machine instruction address includes any bits that are not
|
157 |
|
|
really part of the address, then define this macro to expand into
|
158 |
|
|
an expression that zeros those bits in ADDR. This is only used for
|
159 |
|
|
addresses of instructions, and even then not in all contexts.
|
160 |
|
|
|
161 |
|
|
For example, the two low-order bits of the PC on the
|
162 |
|
|
Hewlett-Packard PA 2.0 architecture contain the privilege level of
|
163 |
|
|
the corresponding instruction. Since instructions must always be
|
164 |
|
|
aligned on four-byte boundaries, the processor masks out these
|
165 |
|
|
bits to generate the actual address of the instruction.
|
166 |
|
|
ADDR_BITS_REMOVE should filter out these bits with an expression
|
167 |
|
|
such as `((addr) & ~3)'.
|
168 |
|
|
|
169 |
|
|
`BEFORE_MAIN_LOOP_HOOK'
|
170 |
|
|
Define this to expand into any code that you want to execute
|
171 |
|
|
before the main loop starts. Although this is not, strictly
|
172 |
|
|
speaking, a target conditional, that is how it is currently being
|
173 |
|
|
used. Note that if a configuration were to define it one way for
|
174 |
|
|
a host and a different way for the target, GDB will probably not
|
175 |
|
|
compile, let alone run correctly. This is currently used only for
|
176 |
|
|
the unsupported i960 Nindy target, and should not be used in any
|
177 |
|
|
other configuration.
|
178 |
|
|
|
179 |
|
|
`BELIEVE_PCC_PROMOTION'
|
180 |
|
|
Define if the compiler promotes a short or char parameter to an
|
181 |
|
|
int, but still reports the parameter as its original type, rather
|
182 |
|
|
than the promoted type.
|
183 |
|
|
|
184 |
|
|
`BELIEVE_PCC_PROMOTION_TYPE'
|
185 |
|
|
Define this if GDB should believe the type of a short argument when
|
186 |
|
|
compiled by pcc, but look within a full int space to get its value.
|
187 |
|
|
Only defined for Sun-3 at present.
|
188 |
|
|
|
189 |
|
|
`BITS_BIG_ENDIAN'
|
190 |
|
|
Define this if the numbering of bits in the targets does *not*
|
191 |
|
|
match the endianness of the target byte order. A value of 1 means
|
192 |
|
|
that the bits are numbered in a big-endian order, 0 means
|
193 |
|
|
little-endian.
|
194 |
|
|
|
195 |
|
|
`BREAKPOINT'
|
196 |
|
|
This is the character array initializer for the bit pattern to put
|
197 |
|
|
into memory where a breakpoint is set. Although it's common to
|
198 |
|
|
use a trap instruction for a breakpoint, it's not required; for
|
199 |
|
|
instance, the bit pattern could be an invalid instruction. The
|
200 |
|
|
breakpoint must be no longer than the shortest instruction of the
|
201 |
|
|
architecture.
|
202 |
|
|
|
203 |
|
|
BREAKPOINT has been deprecated in favour of BREAKPOINT_FROM_PC.
|
204 |
|
|
|
205 |
|
|
`BIG_BREAKPOINT'
|
206 |
|
|
|
207 |
|
|
`LITTLE_BREAKPOINT'
|
208 |
|
|
Similar to BREAKPOINT, but used for bi-endian targets.
|
209 |
|
|
|
210 |
|
|
BIG_BREAKPOINT and LITTLE_BREAKPOINT have been deprecated in
|
211 |
|
|
favour of BREAKPOINT_FROM_PC.
|
212 |
|
|
|
213 |
|
|
`REMOTE_BREAKPOINT'
|
214 |
|
|
|
215 |
|
|
`LITTLE_REMOTE_BREAKPOINT'
|
216 |
|
|
|
217 |
|
|
`BIG_REMOTE_BREAKPOINT'
|
218 |
|
|
Similar to BREAKPOINT, but used for remote targets.
|
219 |
|
|
|
220 |
|
|
BIG_REMOTE_BREAKPOINT and LITTLE_REMOTE_BREAKPOINT have been
|
221 |
|
|
deprecated in favour of BREAKPOINT_FROM_PC.
|
222 |
|
|
|
223 |
|
|
`BREAKPOINT_FROM_PC (pcptr, lenptr)'
|
224 |
|
|
Use the program counter to determine the contents and size of a
|
225 |
|
|
breakpoint instruction. It returns a pointer to a string of bytes
|
226 |
|
|
that encode a breakpoint instruction, stores the length of the
|
227 |
|
|
string to *lenptr, and adjusts pc (if necessary) to point to the
|
228 |
|
|
actual memory location where the breakpoint should be inserted.
|
229 |
|
|
|
230 |
|
|
Although it is common to use a trap instruction for a breakpoint,
|
231 |
|
|
it's not required; for instance, the bit pattern could be an
|
232 |
|
|
invalid instruction. The breakpoint must be no longer than the
|
233 |
|
|
shortest instruction of the architecture.
|
234 |
|
|
|
235 |
|
|
Replaces all the other BREAKPOINT macros.
|
236 |
|
|
|
237 |
|
|
`MEMORY_INSERT_BREAKPOINT (addr, contents_cache)'
|
238 |
|
|
|
239 |
|
|
`MEMORY_REMOVE_BREAKPOINT (addr, contents_cache)'
|
240 |
|
|
Insert or remove memory based breakpoints. Reasonable defaults
|
241 |
|
|
(`default_memory_insert_breakpoint' and
|
242 |
|
|
`default_memory_remove_breakpoint' respectively) have been
|
243 |
|
|
provided so that it is not necessary to define these for most
|
244 |
|
|
architectures. Architectures which may want to define
|
245 |
|
|
MEMORY_INSERT_BREAKPOINT and MEMORY_REMOVE_BREAKPOINT will likely
|
246 |
|
|
have instructions that are oddly sized or are not stored in a
|
247 |
|
|
conventional manner.
|
248 |
|
|
|
249 |
|
|
It may also be desirable (from an efficiency standpoint) to define
|
250 |
|
|
custom breakpoint insertion and removal routines if
|
251 |
|
|
BREAKPOINT_FROM_PC needs to read the target's memory for some
|
252 |
|
|
reason.
|
253 |
|
|
|
254 |
|
|
`CALL_DUMMY_P'
|
255 |
|
|
A C expresson that is non-zero when the target suports inferior
|
256 |
|
|
function calls.
|
257 |
|
|
|
258 |
|
|
`CALL_DUMMY_WORDS'
|
259 |
|
|
Pointer to an array of LONGEST words of data containing
|
260 |
|
|
host-byte-ordered REGISTER_BYTES sized values that partially
|
261 |
|
|
specify the sequence of instructions needed for an inferior
|
262 |
|
|
function call.
|
263 |
|
|
|
264 |
|
|
Should be deprecated in favour of a macro that uses
|
265 |
|
|
target-byte-ordered data.
|
266 |
|
|
|
267 |
|
|
`SIZEOF_CALL_DUMMY_WORDS'
|
268 |
|
|
The size of CALL_DUMMY_WORDS. When CALL_DUMMY_P this must return
|
269 |
|
|
a positive value. See also CALL_DUMMY_LENGTH.
|
270 |
|
|
|
271 |
|
|
`CALL_DUMMY'
|
272 |
|
|
A static initializer for CALL_DUMMY_WORDS. Deprecated.
|
273 |
|
|
|
274 |
|
|
`CALL_DUMMY_LOCATION'
|
275 |
|
|
inferior.h
|
276 |
|
|
|
277 |
|
|
`CALL_DUMMY_STACK_ADJUST'
|
278 |
|
|
Stack adjustment needed when performing an inferior function call.
|
279 |
|
|
|
280 |
|
|
Should be deprecated in favor of something like STACK_ALIGN.
|
281 |
|
|
|
282 |
|
|
`CALL_DUMMY_STACK_ADJUST_P'
|
283 |
|
|
Predicate for use of CALL_DUMMY_STACK_ADJUST.
|
284 |
|
|
|
285 |
|
|
Should be deprecated in favor of something like STACK_ALIGN.
|
286 |
|
|
|
287 |
|
|
`CANNOT_FETCH_REGISTER (regno)'
|
288 |
|
|
A C expression that should be nonzero if REGNO cannot be fetched
|
289 |
|
|
from an inferior process. This is only relevant if
|
290 |
|
|
`FETCH_INFERIOR_REGISTERS' is not defined.
|
291 |
|
|
|
292 |
|
|
`CANNOT_STORE_REGISTER (regno)'
|
293 |
|
|
A C expression that should be nonzero if REGNO should not be
|
294 |
|
|
written to the target. This is often the case for program
|
295 |
|
|
counters, status words, and other special registers. If this is
|
296 |
|
|
not defined, GDB will assume that all registers may be written.
|
297 |
|
|
|
298 |
|
|
`DO_DEFERRED_STORES'
|
299 |
|
|
|
300 |
|
|
`CLEAR_DEFERRED_STORES'
|
301 |
|
|
Define this to execute any deferred stores of registers into the
|
302 |
|
|
inferior, and to cancel any deferred stores.
|
303 |
|
|
|
304 |
|
|
Currently only implemented correctly for native Sparc
|
305 |
|
|
configurations?
|
306 |
|
|
|
307 |
|
|
`COERCE_FLOAT_TO_DOUBLE (FORMAL, ACTUAL)'
|
308 |
|
|
If we are calling a function by hand, and the function was declared
|
309 |
|
|
(according to the debug info) without a prototype, should we
|
310 |
|
|
automatically promote floats to doubles? This macro must evaluate
|
311 |
|
|
to non-zero if we should, or zero if we should leave the value
|
312 |
|
|
alone.
|
313 |
|
|
|
314 |
|
|
The argument ACTUAL is the type of the value we want to pass to
|
315 |
|
|
the function. The argument FORMAL is the type of this argument,
|
316 |
|
|
as it appears in the function's definition. Note that FORMAL may
|
317 |
|
|
be zero if we have no debugging information for the function, or if
|
318 |
|
|
we're passing more arguments than are officially declared (for
|
319 |
|
|
example, varargs). This macro is never invoked if the function
|
320 |
|
|
definitely has a prototype.
|
321 |
|
|
|
322 |
|
|
The default behavior is to promote only when we have no type
|
323 |
|
|
information for the formal parameter. This is different from the
|
324 |
|
|
obvious behavior, which would be to promote whenever we have no
|
325 |
|
|
prototype, just as the compiler does. It's annoying, but some
|
326 |
|
|
older targets rely on this. If you want GDB to follow the typical
|
327 |
|
|
compiler behavior -- to always promote when there is no prototype
|
328 |
|
|
in scope -- your gdbarch init function can call
|
329 |
|
|
`set_gdbarch_coerce_float_to_double' and select the
|
330 |
|
|
`standard_coerce_float_to_double' function.
|
331 |
|
|
|
332 |
|
|
`CPLUS_MARKER'
|
333 |
|
|
Define this to expand into the character that G++ uses to
|
334 |
|
|
distinguish compiler-generated identifiers from
|
335 |
|
|
programmer-specified identifiers. By default, this expands into
|
336 |
|
|
`'$''. Most System V targets should define this to `'.''.
|
337 |
|
|
|
338 |
|
|
`DBX_PARM_SYMBOL_CLASS'
|
339 |
|
|
Hook for the `SYMBOL_CLASS' of a parameter when decoding DBX symbol
|
340 |
|
|
information. In the i960, parameters can be stored as locals or as
|
341 |
|
|
args, depending on the type of the debug record.
|
342 |
|
|
|
343 |
|
|
`DECR_PC_AFTER_BREAK'
|
344 |
|
|
Define this to be the amount by which to decrement the PC after the
|
345 |
|
|
program encounters a breakpoint. This is often the number of
|
346 |
|
|
bytes in BREAKPOINT, though not always. For most targets this
|
347 |
|
|
value will be 0.
|
348 |
|
|
|
349 |
|
|
`DECR_PC_AFTER_HW_BREAK'
|
350 |
|
|
Similarly, for hardware breakpoints.
|
351 |
|
|
|
352 |
|
|
`DISABLE_UNSETTABLE_BREAK addr'
|
353 |
|
|
If defined, this should evaluate to 1 if ADDR is in a shared
|
354 |
|
|
library in which breakpoints cannot be set and so should be
|
355 |
|
|
disabled.
|
356 |
|
|
|
357 |
|
|
`DO_REGISTERS_INFO'
|
358 |
|
|
If defined, use this to print the value of a register or all
|
359 |
|
|
registers.
|
360 |
|
|
|
361 |
|
|
`END_OF_TEXT_DEFAULT'
|
362 |
|
|
This is an expression that should designate the end of the text
|
363 |
|
|
section (? FIXME ?)
|
364 |
|
|
|
365 |
|
|
`EXTRACT_RETURN_VALUE(type,regbuf,valbuf)'
|
366 |
|
|
Define this to extract a function's return value of type TYPE from
|
367 |
|
|
the raw register state REGBUF and copy that, in virtual format,
|
368 |
|
|
into VALBUF.
|
369 |
|
|
|
370 |
|
|
`EXTRACT_STRUCT_VALUE_ADDRESS(regbuf)'
|
371 |
|
|
When EXTRACT_STRUCT_VALUE_ADDRESS_P this is used to to extract
|
372 |
|
|
from an array REGBUF (containing the raw register state) the
|
373 |
|
|
address in which a function should return its structure value, as a
|
374 |
|
|
CORE_ADDR (or an expression that can be used as one).
|
375 |
|
|
|
376 |
|
|
`EXTRACT_STRUCT_VALUE_ADDRESS_P'
|
377 |
|
|
Predicate for EXTRACT_STRUCT_VALUE_ADDRESS.
|
378 |
|
|
|
379 |
|
|
`FLOAT_INFO'
|
380 |
|
|
If defined, then the `info float' command will print information
|
381 |
|
|
about the processor's floating point unit.
|
382 |
|
|
|
383 |
|
|
`FP_REGNUM'
|
384 |
|
|
If the virtual frame pointer is kept in a register, then define
|
385 |
|
|
this macro to be the number (greater than or equal to zero) of
|
386 |
|
|
that register.
|
387 |
|
|
|
388 |
|
|
This should only need to be defined if `TARGET_READ_FP' and
|
389 |
|
|
`TARGET_WRITE_FP' are not defined.
|
390 |
|
|
|
391 |
|
|
`FRAMELESS_FUNCTION_INVOCATION(fi)'
|
392 |
|
|
Define this to an expression that returns 1 if the function
|
393 |
|
|
invocation represented by FI does not have a stack frame
|
394 |
|
|
associated with it. Otherwise return 0.
|
395 |
|
|
|
396 |
|
|
`FRAME_ARGS_ADDRESS_CORRECT'
|
397 |
|
|
stack.c
|
398 |
|
|
|
399 |
|
|
`FRAME_CHAIN(frame)'
|
400 |
|
|
Given FRAME, return a pointer to the calling frame.
|
401 |
|
|
|
402 |
|
|
`FRAME_CHAIN_COMBINE(chain,frame)'
|
403 |
|
|
Define this to take the frame chain pointer and the frame's nominal
|
404 |
|
|
address and produce the nominal address of the caller's frame.
|
405 |
|
|
Presently only defined for HP PA.
|
406 |
|
|
|
407 |
|
|
`FRAME_CHAIN_VALID(chain,thisframe)'
|
408 |
|
|
Define this to be an expression that returns zero if the given
|
409 |
|
|
frame is an outermost frame, with no caller, and nonzero
|
410 |
|
|
otherwise. Several common definitions are available.
|
411 |
|
|
|
412 |
|
|
`file_frame_chain_valid' is nonzero if the chain pointer is nonzero
|
413 |
|
|
and given frame's PC is not inside the startup file (such as
|
414 |
|
|
`crt0.o'). `func_frame_chain_valid' is nonzero if the chain
|
415 |
|
|
pointer is nonzero and the given frame's PC is not in `main()' or a
|
416 |
|
|
known entry point function (such as `_start()').
|
417 |
|
|
`generic_file_frame_chain_valid' and
|
418 |
|
|
`generic_func_frame_chain_valid' are equivalent implementations for
|
419 |
|
|
targets using generic dummy frames.
|
420 |
|
|
|
421 |
|
|
`FRAME_INIT_SAVED_REGS(frame)'
|
422 |
|
|
See `frame.h'. Determines the address of all registers in the
|
423 |
|
|
current stack frame storing each in `frame->saved_regs'. Space for
|
424 |
|
|
`frame->saved_regs' shall be allocated by `FRAME_INIT_SAVED_REGS'
|
425 |
|
|
using either `frame_saved_regs_zalloc' or `frame_obstack_alloc'.
|
426 |
|
|
|
427 |
|
|
FRAME_FIND_SAVED_REGS and EXTRA_FRAME_INFO are deprecated.
|
428 |
|
|
|
429 |
|
|
`FRAME_NUM_ARGS (fi)'
|
430 |
|
|
For the frame described by FI return the number of arguments that
|
431 |
|
|
are being passed. If the number of arguments is not known, return
|
432 |
|
|
`-1'.
|
433 |
|
|
|
434 |
|
|
`FRAME_SAVED_PC(frame)'
|
435 |
|
|
Given FRAME, return the pc saved there. That is, the return
|
436 |
|
|
address.
|
437 |
|
|
|
438 |
|
|
`FUNCTION_EPILOGUE_SIZE'
|
439 |
|
|
For some COFF targets, the `x_sym.x_misc.x_fsize' field of the
|
440 |
|
|
function end symbol is 0. For such targets, you must define
|
441 |
|
|
`FUNCTION_EPILOGUE_SIZE' to expand into the standard size of a
|
442 |
|
|
function's epilogue.
|
443 |
|
|
|
444 |
|
|
`FUNCTION_START_OFFSET'
|
445 |
|
|
An integer, giving the offset in bytes from a function's address
|
446 |
|
|
(as used in the values of symbols, function pointers, etc.), and
|
447 |
|
|
the function's first genuine instruction.
|
448 |
|
|
|
449 |
|
|
This is zero on almost all machines: the function's address is
|
450 |
|
|
usually the address of its first instruction. However, on the
|
451 |
|
|
VAX, for example, each function starts with two bytes containing a
|
452 |
|
|
bitmask indicating which registers to save upon entry to the
|
453 |
|
|
function. The VAX `call' instructions check this value, and save
|
454 |
|
|
the appropriate registers automatically. Thus, since the offset
|
455 |
|
|
from the function's address to its first instruction is two bytes,
|
456 |
|
|
`FUNCTION_START_OFFSET' would be 2 on the VAX.
|
457 |
|
|
|
458 |
|
|
`GCC_COMPILED_FLAG_SYMBOL'
|
459 |
|
|
|
460 |
|
|
`GCC2_COMPILED_FLAG_SYMBOL'
|
461 |
|
|
If defined, these are the names of the symbols that GDB will look
|
462 |
|
|
for to detect that GCC compiled the file. The default symbols are
|
463 |
|
|
`gcc_compiled.' and `gcc2_compiled.', respectively. (Currently
|
464 |
|
|
only defined for the Delta 68.)
|
465 |
|
|
|
466 |
|
|
`GDB_MULTI_ARCH'
|
467 |
|
|
If defined and non-zero, enables suport for multiple architectures
|
468 |
|
|
within GDB.
|
469 |
|
|
|
470 |
|
|
The support can be enabled at two levels. At level one, only
|
471 |
|
|
definitions for previously undefined macros are provided; at level
|
472 |
|
|
two, a multi-arch definition of all architecture dependant macros
|
473 |
|
|
will be defined.
|
474 |
|
|
|
475 |
|
|
`GDB_TARGET_IS_HPPA'
|
476 |
|
|
This determines whether horrible kludge code in dbxread.c and
|
477 |
|
|
partial-stab.h is used to mangle multiple-symbol-table files from
|
478 |
|
|
HPPA's. This should all be ripped out, and a scheme like elfread.c
|
479 |
|
|
used.
|
480 |
|
|
|
481 |
|
|
`GET_LONGJMP_TARGET'
|
482 |
|
|
For most machines, this is a target-dependent parameter. On the
|
483 |
|
|
DECstation and the Iris, this is a native-dependent parameter,
|
484 |
|
|
since is needed to define it.
|
485 |
|
|
|
486 |
|
|
This macro determines the target PC address that longjmp() will
|
487 |
|
|
jump to, assuming that we have just stopped at a longjmp
|
488 |
|
|
breakpoint. It takes a CORE_ADDR * as argument, and stores the
|
489 |
|
|
target PC value through this pointer. It examines the current
|
490 |
|
|
state of the machine as needed.
|
491 |
|
|
|
492 |
|
|
`GET_SAVED_REGISTER'
|
493 |
|
|
Define this if you need to supply your own definition for the
|
494 |
|
|
function `get_saved_register'.
|
495 |
|
|
|
496 |
|
|
`HAVE_REGISTER_WINDOWS'
|
497 |
|
|
Define this if the target has register windows.
|
498 |
|
|
|
499 |
|
|
`REGISTER_IN_WINDOW_P (regnum)'
|
500 |
|
|
Define this to be an expression that is 1 if the given register is
|
501 |
|
|
in the window.
|
502 |
|
|
|
503 |
|
|
`IBM6000_TARGET'
|
504 |
|
|
Shows that we are configured for an IBM RS/6000 target. This
|
505 |
|
|
conditional should be eliminated (FIXME) and replaced by
|
506 |
|
|
feature-specific macros. It was introduced in haste and we are
|
507 |
|
|
repenting at leisure.
|
508 |
|
|
|
509 |
|
|
`SYMBOLS_CAN_START_WITH_DOLLAR'
|
510 |
|
|
Some systems have routines whose names start with `$'. Giving this
|
511 |
|
|
macro a non-zero value tells GDB's expression parser to check for
|
512 |
|
|
such routines when parsing tokens that begin with `$'.
|
513 |
|
|
|
514 |
|
|
On HP-UX, certain system routines (millicode) have names beginning
|
515 |
|
|
with `$' or `$$'. For example, `$$dyncall' is a millicode routine
|
516 |
|
|
that handles inter-space procedure calls on PA-RISC.
|
517 |
|
|
|
518 |
|
|
`IEEE_FLOAT'
|
519 |
|
|
Define this if the target system uses IEEE-format floating point
|
520 |
|
|
numbers.
|
521 |
|
|
|
522 |
|
|
`INIT_EXTRA_FRAME_INFO (fromleaf, frame)'
|
523 |
|
|
If additional information about the frame is required this should
|
524 |
|
|
be stored in `frame->extra_info'. Space for `frame->extra_info'
|
525 |
|
|
is allocated using `frame_obstack_alloc'.
|
526 |
|
|
|
527 |
|
|
`INIT_FRAME_PC (fromleaf, prev)'
|
528 |
|
|
This is a C statement that sets the pc of the frame pointed to by
|
529 |
|
|
PREV. [By default...]
|
530 |
|
|
|
531 |
|
|
`INNER_THAN (lhs,rhs)'
|
532 |
|
|
Returns non-zero if stack address LHS is inner than (nearer to the
|
533 |
|
|
stack top) stack address RHS. Define this as `lhs < rhs' if the
|
534 |
|
|
target's stack grows downward in memory, or `lhs > rsh' if the
|
535 |
|
|
stack grows upward.
|
536 |
|
|
|
537 |
|
|
`IN_SIGTRAMP (pc, name)'
|
538 |
|
|
Define this to return true if the given PC and/or NAME indicates
|
539 |
|
|
that the current function is a sigtramp.
|
540 |
|
|
|
541 |
|
|
`SIGTRAMP_START (pc)'
|
542 |
|
|
|
543 |
|
|
`SIGTRAMP_END (pc)'
|
544 |
|
|
Define these to be the start and end address of the sigtramp for
|
545 |
|
|
the given PC. On machines where the address is just a compile time
|
546 |
|
|
constant, the macro expansion will typically just ignore the
|
547 |
|
|
supplied PC.
|
548 |
|
|
|
549 |
|
|
`IN_SOLIB_CALL_TRAMPOLINE pc name'
|
550 |
|
|
Define this to evaluate to nonzero if the program is stopped in the
|
551 |
|
|
trampoline that connects to a shared library.
|
552 |
|
|
|
553 |
|
|
`IN_SOLIB_RETURN_TRAMPOLINE pc name'
|
554 |
|
|
Define this to evaluate to nonzero if the program is stopped in the
|
555 |
|
|
trampoline that returns from a shared library.
|
556 |
|
|
|
557 |
|
|
`IN_SOLIB_DYNSYM_RESOLVE_CODE pc'
|
558 |
|
|
Define this to evaluate to nonzero if the program is stopped in the
|
559 |
|
|
dynamic linker.
|
560 |
|
|
|
561 |
|
|
`SKIP_SOLIB_RESOLVER pc'
|
562 |
|
|
Define this to evaluate to the (nonzero) address at which execution
|
563 |
|
|
should continue to get past the dynamic linker's symbol resolution
|
564 |
|
|
function. A zero value indicates that it is not important or
|
565 |
|
|
necessary to set a breakpoint to get through the dynamic linker
|
566 |
|
|
and that single stepping will suffice.
|
567 |
|
|
|
568 |
|
|
`IS_TRAPPED_INTERNALVAR (name)'
|
569 |
|
|
This is an ugly hook to allow the specification of special actions
|
570 |
|
|
that should occur as a side-effect of setting the value of a
|
571 |
|
|
variable internal to GDB. Currently only used by the h8500. Note
|
572 |
|
|
that this could be either a host or target conditional.
|
573 |
|
|
|
574 |
|
|
`NEED_TEXT_START_END'
|
575 |
|
|
Define this if GDB should determine the start and end addresses of
|
576 |
|
|
the text section. (Seems dubious.)
|
577 |
|
|
|
578 |
|
|
`NO_HIF_SUPPORT'
|
579 |
|
|
(Specific to the a29k.)
|
580 |
|
|
|
581 |
|
|
`REGISTER_CONVERTIBLE (REG)'
|
582 |
|
|
Return non-zero if REG uses different raw and virtual formats.
|
583 |
|
|
*Note Using Different Register and Memory Data Representations:
|
584 |
|
|
Target Architecture Definition.
|
585 |
|
|
|
586 |
|
|
`REGISTER_RAW_SIZE (REG)'
|
587 |
|
|
Return the raw size of REG. *Note Using Different Register and
|
588 |
|
|
Memory Data Representations: Target Architecture Definition.
|
589 |
|
|
|
590 |
|
|
`REGISTER_VIRTUAL_SIZE (REG)'
|
591 |
|
|
Return the virtual size of REG. *Note Using Different Register
|
592 |
|
|
and Memory Data Representations: Target Architecture Definition.
|
593 |
|
|
|
594 |
|
|
`REGISTER_VIRTUAL_TYPE (REG)'
|
595 |
|
|
Return the virtual type of REG. *Note Using Different Register
|
596 |
|
|
and Memory Data Representations: Target Architecture Definition.
|
597 |
|
|
|
598 |
|
|
`REGISTER_CONVERT_TO_VIRTUAL(REG, TYPE, FROM, TO)'
|
599 |
|
|
Convert the value of register REG from its raw form to its virtual
|
600 |
|
|
form. *Note Using Different Register and Memory Data
|
601 |
|
|
Representations: Target Architecture Definition.
|
602 |
|
|
|
603 |
|
|
`REGISTER_CONVERT_TO_RAW(TYPE, REG, FROM, TO)'
|
604 |
|
|
Convert the value of register REG from its virtual form to its raw
|
605 |
|
|
form. *Note Using Different Register and Memory Data
|
606 |
|
|
Representations: Target Architecture Definition.
|
607 |
|
|
|
608 |
|
|
`SOFTWARE_SINGLE_STEP_P'
|
609 |
|
|
Define this as 1 if the target does not have a hardware single-step
|
610 |
|
|
mechanism. The macro `SOFTWARE_SINGLE_STEP' must also be defined.
|
611 |
|
|
|
612 |
|
|
`SOFTWARE_SINGLE_STEP(signal,insert_breapoints_p)'
|
613 |
|
|
A function that inserts or removes (dependant on
|
614 |
|
|
INSERT_BREAPOINTS_P) breakpoints at each possible destinations of
|
615 |
|
|
the next instruction. See `sparc-tdep.c' and `rs6000-tdep.c' for
|
616 |
|
|
examples.
|
617 |
|
|
|
618 |
|
|
`SOFUN_ADDRESS_MAYBE_MISSING'
|
619 |
|
|
Somebody clever observed that, the more actual addresses you have
|
620 |
|
|
in the debug information, the more time the linker has to spend
|
621 |
|
|
relocating them. So whenever there's some other way the debugger
|
622 |
|
|
could find the address it needs, you should omit it from the debug
|
623 |
|
|
info, to make linking faster.
|
624 |
|
|
|
625 |
|
|
`SOFUN_ADDRESS_MAYBE_MISSING' indicates that a particular set of
|
626 |
|
|
hacks of this sort are in use, affecting `N_SO' and `N_FUN'
|
627 |
|
|
entries in stabs-format debugging information. `N_SO' stabs mark
|
628 |
|
|
the beginning and ending addresses of compilation units in the text
|
629 |
|
|
segment. `N_FUN' stabs mark the starts and ends of functions.
|
630 |
|
|
|
631 |
|
|
`SOFUN_ADDRESS_MAYBE_MISSING' means two things:
|
632 |
|
|
* `N_FUN' stabs have an address of zero. Instead, you should
|
633 |
|
|
find the addresses where the function starts by taking the
|
634 |
|
|
function name from the stab, and then looking that up in the
|
635 |
|
|
minsyms (the linker/ assembler symbol table). In other
|
636 |
|
|
words, the stab has the name, and the linker / assembler
|
637 |
|
|
symbol table is the only place that carries the address.
|
638 |
|
|
|
639 |
|
|
* `N_SO' stabs have an address of zero, too. You just look at
|
640 |
|
|
the `N_FUN' stabs that appear before and after the `N_SO'
|
641 |
|
|
stab, and guess the starting and ending addresses of the
|
642 |
|
|
compilation unit from them.
|
643 |
|
|
|
644 |
|
|
|
645 |
|
|
`PCC_SOL_BROKEN'
|
646 |
|
|
(Used only in the Convex target.)
|
647 |
|
|
|
648 |
|
|
`PC_IN_CALL_DUMMY'
|
649 |
|
|
inferior.h
|
650 |
|
|
|
651 |
|
|
`PC_LOAD_SEGMENT'
|
652 |
|
|
If defined, print information about the load segment for the
|
653 |
|
|
program counter. (Defined only for the RS/6000.)
|
654 |
|
|
|
655 |
|
|
`PC_REGNUM'
|
656 |
|
|
If the program counter is kept in a register, then define this
|
657 |
|
|
macro to be the number (greater than or equal to zero) of that
|
658 |
|
|
register.
|
659 |
|
|
|
660 |
|
|
This should only need to be defined if `TARGET_READ_PC' and
|
661 |
|
|
`TARGET_WRITE_PC' are not defined.
|
662 |
|
|
|
663 |
|
|
`NPC_REGNUM'
|
664 |
|
|
The number of the "next program counter" register, if defined.
|
665 |
|
|
|
666 |
|
|
`NNPC_REGNUM'
|
667 |
|
|
The number of the "next next program counter" register, if defined.
|
668 |
|
|
Currently, this is only defined for the Motorola 88K.
|
669 |
|
|
|
670 |
|
|
`PARM_BOUNDARY'
|
671 |
|
|
If non-zero, round arguments to a boundary of this many bits before
|
672 |
|
|
pushing them on the stack.
|
673 |
|
|
|
674 |
|
|
`PRINT_REGISTER_HOOK (regno)'
|
675 |
|
|
If defined, this must be a function that prints the contents of the
|
676 |
|
|
given register to standard output.
|
677 |
|
|
|
678 |
|
|
`PRINT_TYPELESS_INTEGER'
|
679 |
|
|
This is an obscure substitute for `print_longest' that seems to
|
680 |
|
|
have been defined for the Convex target.
|
681 |
|
|
|
682 |
|
|
`PROCESS_LINENUMBER_HOOK'
|
683 |
|
|
A hook defined for XCOFF reading.
|
684 |
|
|
|
685 |
|
|
`PROLOGUE_FIRSTLINE_OVERLAP'
|
686 |
|
|
(Only used in unsupported Convex configuration.)
|
687 |
|
|
|
688 |
|
|
`PS_REGNUM'
|
689 |
|
|
If defined, this is the number of the processor status register.
|
690 |
|
|
(This definition is only used in generic code when parsing "$ps".)
|
691 |
|
|
|
692 |
|
|
`POP_FRAME'
|
693 |
|
|
Used in `call_function_by_hand' to remove an artificial stack
|
694 |
|
|
frame.
|
695 |
|
|
|
696 |
|
|
`PUSH_ARGUMENTS (nargs, args, sp, struct_return, struct_addr)'
|
697 |
|
|
Define this to push arguments onto the stack for inferior function
|
698 |
|
|
call. Return the updated stack pointer value.
|
699 |
|
|
|
700 |
|
|
`PUSH_DUMMY_FRAME'
|
701 |
|
|
Used in `call_function_by_hand' to create an artificial stack
|
702 |
|
|
frame.
|
703 |
|
|
|
704 |
|
|
`REGISTER_BYTES'
|
705 |
|
|
The total amount of space needed to store GDB's copy of the
|
706 |
|
|
machine's register state.
|
707 |
|
|
|
708 |
|
|
`REGISTER_NAME(i)'
|
709 |
|
|
Return the name of register I as a string. May return NULL or NUL
|
710 |
|
|
to indicate that register I is not valid.
|
711 |
|
|
|
712 |
|
|
`REGISTER_NAMES'
|
713 |
|
|
Deprecated in favor of REGISTER_NAME.
|
714 |
|
|
|
715 |
|
|
`REG_STRUCT_HAS_ADDR (gcc_p, type)'
|
716 |
|
|
Define this to return 1 if the given type will be passed by pointer
|
717 |
|
|
rather than directly.
|
718 |
|
|
|
719 |
|
|
`SAVE_DUMMY_FRAME_TOS (sp)'
|
720 |
|
|
Used in `call_function_by_hand' to notify the target dependent code
|
721 |
|
|
of the top-of-stack value that will be passed to the the inferior
|
722 |
|
|
code. This is the value of the SP after both the dummy frame and
|
723 |
|
|
space for parameters/results have been allocated on the stack.
|
724 |
|
|
|
725 |
|
|
`SDB_REG_TO_REGNUM'
|
726 |
|
|
Define this to convert sdb register numbers into GDB regnums. If
|
727 |
|
|
not defined, no conversion will be done.
|
728 |
|
|
|
729 |
|
|
`SHIFT_INST_REGS'
|
730 |
|
|
(Only used for m88k targets.)
|
731 |
|
|
|
732 |
|
|
`SKIP_PERMANENT_BREAKPOINT'
|
733 |
|
|
Advance the inferior's PC past a permanent breakpoint. GDB
|
734 |
|
|
normally steps over a breakpoint by removing it, stepping one
|
735 |
|
|
instruction, and re-inserting the breakpoint. However, permanent
|
736 |
|
|
breakpoints are hardwired into the inferior, and can't be removed,
|
737 |
|
|
so this strategy doesn't work. Calling SKIP_PERMANENT_BREAKPOINT
|
738 |
|
|
adjusts the processor's state so that execution will resume just
|
739 |
|
|
after the breakpoint. This macro does the right thing even when
|
740 |
|
|
the breakpoint is in the delay slot of a branch or jump.
|
741 |
|
|
|
742 |
|
|
`SKIP_PROLOGUE (pc)'
|
743 |
|
|
A C expression that returns the address of the "real" code beyond
|
744 |
|
|
the function entry prologue found at PC.
|
745 |
|
|
|
746 |
|
|
`SKIP_PROLOGUE_FRAMELESS_P'
|
747 |
|
|
A C expression that should behave similarly, but that can stop as
|
748 |
|
|
soon as the function is known to have a frame. If not defined,
|
749 |
|
|
`SKIP_PROLOGUE' will be used instead.
|
750 |
|
|
|
751 |
|
|
`SKIP_TRAMPOLINE_CODE (pc)'
|
752 |
|
|
If the target machine has trampoline code that sits between
|
753 |
|
|
callers and the functions being called, then define this macro to
|
754 |
|
|
return a new PC that is at the start of the real function.
|
755 |
|
|
|
756 |
|
|
`SP_REGNUM'
|
757 |
|
|
If the stack-pointer is kept in a register, then define this macro
|
758 |
|
|
to be the number (greater than or equal to zero) of that register.
|
759 |
|
|
|
760 |
|
|
This should only need to be defined if `TARGET_WRITE_SP' and
|
761 |
|
|
`TARGET_WRITE_SP' are not defined.
|
762 |
|
|
|
763 |
|
|
`STAB_REG_TO_REGNUM'
|
764 |
|
|
Define this to convert stab register numbers (as gotten from `r'
|
765 |
|
|
declarations) into GDB regnums. If not defined, no conversion
|
766 |
|
|
will be done.
|
767 |
|
|
|
768 |
|
|
`STACK_ALIGN (addr)'
|
769 |
|
|
Define this to adjust the address to the alignment required for the
|
770 |
|
|
processor's stack.
|
771 |
|
|
|
772 |
|
|
`STEP_SKIPS_DELAY (addr)'
|
773 |
|
|
Define this to return true if the address is of an instruction
|
774 |
|
|
with a delay slot. If a breakpoint has been placed in the
|
775 |
|
|
instruction's delay slot, GDB will single-step over that
|
776 |
|
|
instruction before resuming normally. Currently only defined for
|
777 |
|
|
the Mips.
|
778 |
|
|
|
779 |
|
|
`STORE_RETURN_VALUE (type, valbuf)'
|
780 |
|
|
A C expression that stores a function return value of type TYPE,
|
781 |
|
|
where VALBUF is the address of the value to be stored.
|
782 |
|
|
|
783 |
|
|
`SUN_FIXED_LBRAC_BUG'
|
784 |
|
|
(Used only for Sun-3 and Sun-4 targets.)
|
785 |
|
|
|
786 |
|
|
`SYMBOL_RELOADING_DEFAULT'
|
787 |
|
|
The default value of the `symbol-reloading' variable. (Never
|
788 |
|
|
defined in current sources.)
|
789 |
|
|
|
790 |
|
|
`TARGET_BYTE_ORDER_DEFAULT'
|
791 |
|
|
The ordering of bytes in the target. This must be either
|
792 |
|
|
`BIG_ENDIAN' or `LITTLE_ENDIAN'. This macro replaces
|
793 |
|
|
TARGET_BYTE_ORDER which is deprecated.
|
794 |
|
|
|
795 |
|
|
`TARGET_BYTE_ORDER_SELECTABLE_P'
|
796 |
|
|
Non-zero if the target has both `BIG_ENDIAN' and `LITTLE_ENDIAN'
|
797 |
|
|
variants. This macro replaces TARGET_BYTE_ORDER_SELECTABLE which
|
798 |
|
|
is deprecated.
|
799 |
|
|
|
800 |
|
|
`TARGET_CHAR_BIT'
|
801 |
|
|
Number of bits in a char; defaults to 8.
|
802 |
|
|
|
803 |
|
|
`TARGET_COMPLEX_BIT'
|
804 |
|
|
Number of bits in a complex number; defaults to `2 *
|
805 |
|
|
TARGET_FLOAT_BIT'.
|
806 |
|
|
|
807 |
|
|
At present this macro is not used.
|
808 |
|
|
|
809 |
|
|
`TARGET_DOUBLE_BIT'
|
810 |
|
|
Number of bits in a double float; defaults to `8 *
|
811 |
|
|
TARGET_CHAR_BIT'.
|
812 |
|
|
|
813 |
|
|
`TARGET_DOUBLE_COMPLEX_BIT'
|
814 |
|
|
Number of bits in a double complex; defaults to `2 *
|
815 |
|
|
TARGET_DOUBLE_BIT'.
|
816 |
|
|
|
817 |
|
|
At present this macro is not used.
|
818 |
|
|
|
819 |
|
|
`TARGET_FLOAT_BIT'
|
820 |
|
|
Number of bits in a float; defaults to `4 * TARGET_CHAR_BIT'.
|
821 |
|
|
|
822 |
|
|
`TARGET_INT_BIT'
|
823 |
|
|
Number of bits in an integer; defaults to `4 * TARGET_CHAR_BIT'.
|
824 |
|
|
|
825 |
|
|
`TARGET_LONG_BIT'
|
826 |
|
|
Number of bits in a long integer; defaults to `4 *
|
827 |
|
|
TARGET_CHAR_BIT'.
|
828 |
|
|
|
829 |
|
|
`TARGET_LONG_DOUBLE_BIT'
|
830 |
|
|
Number of bits in a long double float; defaults to `2 *
|
831 |
|
|
TARGET_DOUBLE_BIT'.
|
832 |
|
|
|
833 |
|
|
`TARGET_LONG_LONG_BIT'
|
834 |
|
|
Number of bits in a long long integer; defaults to `2 *
|
835 |
|
|
TARGET_LONG_BIT'.
|
836 |
|
|
|
837 |
|
|
`TARGET_PTR_BIT'
|
838 |
|
|
Number of bits in a pointer; defaults to `TARGET_INT_BIT'.
|
839 |
|
|
|
840 |
|
|
`TARGET_SHORT_BIT'
|
841 |
|
|
Number of bits in a short integer; defaults to `2 *
|
842 |
|
|
TARGET_CHAR_BIT'.
|
843 |
|
|
|
844 |
|
|
`TARGET_READ_PC'
|
845 |
|
|
|
846 |
|
|
`TARGET_WRITE_PC (val, pid)'
|
847 |
|
|
|
848 |
|
|
`TARGET_READ_SP'
|
849 |
|
|
|
850 |
|
|
`TARGET_WRITE_SP'
|
851 |
|
|
|
852 |
|
|
`TARGET_READ_FP'
|
853 |
|
|
|
854 |
|
|
`TARGET_WRITE_FP'
|
855 |
|
|
These change the behavior of `read_pc', `write_pc', `read_sp',
|
856 |
|
|
`write_sp', `read_fp' and `write_fp'. For most targets, these may
|
857 |
|
|
be left undefined. GDB will call the read and write register
|
858 |
|
|
functions with the relevant `_REGNUM' argument.
|
859 |
|
|
|
860 |
|
|
These macros are useful when a target keeps one of these registers
|
861 |
|
|
in a hard to get at place; for example, part in a segment register
|
862 |
|
|
and part in an ordinary register.
|
863 |
|
|
|
864 |
|
|
`TARGET_VIRTUAL_FRAME_POINTER(pc,regp,offsetp)'
|
865 |
|
|
Returns a `(register, offset)' pair representing the virtual frame
|
866 |
|
|
pointer in use at the code address `"pc"'. If virtual frame
|
867 |
|
|
pointers are not used, a default definition simply returns
|
868 |
|
|
`FP_REGNUM', with an offset of zero.
|
869 |
|
|
|
870 |
|
|
`USE_STRUCT_CONVENTION (gcc_p, type)'
|
871 |
|
|
If defined, this must be an expression that is nonzero if a value
|
872 |
|
|
of the given TYPE being returned from a function must have space
|
873 |
|
|
allocated for it on the stack. GCC_P is true if the function
|
874 |
|
|
being considered is known to have been compiled by GCC; this is
|
875 |
|
|
helpful for systems where GCC is known to use different calling
|
876 |
|
|
convention than other compilers.
|
877 |
|
|
|
878 |
|
|
`VARIABLES_INSIDE_BLOCK (desc, gcc_p)'
|
879 |
|
|
For dbx-style debugging information, if the compiler puts variable
|
880 |
|
|
declarations inside LBRAC/RBRAC blocks, this should be defined to
|
881 |
|
|
be nonzero. DESC is the value of `n_desc' from the `N_RBRAC'
|
882 |
|
|
symbol, and GCC_P is true if GDB has noticed the presence of
|
883 |
|
|
either the `GCC_COMPILED_SYMBOL' or the `GCC2_COMPILED_SYMBOL'.
|
884 |
|
|
By default, this is 0.
|
885 |
|
|
|
886 |
|
|
`OS9K_VARIABLES_INSIDE_BLOCK (desc, gcc_p)'
|
887 |
|
|
Similarly, for OS/9000. Defaults to 1.
|
888 |
|
|
|
889 |
|
|
Motorola M68K target conditionals.
|
890 |
|
|
|
891 |
|
|
`BPT_VECTOR'
|
892 |
|
|
Define this to be the 4-bit location of the breakpoint trap
|
893 |
|
|
vector. If not defined, it will default to `0xf'.
|
894 |
|
|
|
895 |
|
|
`REMOTE_BPT_VECTOR'
|
896 |
|
|
Defaults to `1'.
|
897 |
|
|
|
898 |
|
|
Adding a New Target
|
899 |
|
|
===================
|
900 |
|
|
|
901 |
|
|
The following files define a target to GDB:
|
902 |
|
|
|
903 |
|
|
`gdb/config/ARCH/TTT.mt'
|
904 |
|
|
Contains a Makefile fragment specific to this target. Specifies
|
905 |
|
|
what object files are needed for target TTT, by defining
|
906 |
|
|
`TDEPFILES=...' and `TDEPLIBS=...'. Also specifies the header
|
907 |
|
|
file which describes TTT, by defining `TM_FILE= tm-TTT.h'.
|
908 |
|
|
|
909 |
|
|
You can also define `TM_CFLAGS', `TM_CLIBS', `TM_CDEPS', but these
|
910 |
|
|
are now deprecated, replaced by autoconf, and may go away in
|
911 |
|
|
future versions of GDB.
|
912 |
|
|
|
913 |
|
|
`gdb/config/ARCH/tm-TTT.h'
|
914 |
|
|
(`tm.h' is a link to this file, created by configure). Contains
|
915 |
|
|
macro definitions about the target machine's registers, stack frame
|
916 |
|
|
format and instructions.
|
917 |
|
|
|
918 |
|
|
`gdb/TTT-tdep.c'
|
919 |
|
|
Contains any miscellaneous code required for this target machine.
|
920 |
|
|
On some machines it doesn't exist at all. Sometimes the macros in
|
921 |
|
|
`tm-TTT.h' become very complicated, so they are implemented as
|
922 |
|
|
functions here instead, and the macro is simply defined to call the
|
923 |
|
|
function. This is vastly preferable, since it is easier to
|
924 |
|
|
understand and debug.
|
925 |
|
|
|
926 |
|
|
`gdb/config/ARCH/tm-ARCH.h'
|
927 |
|
|
This often exists to describe the basic layout of the target
|
928 |
|
|
machine's processor chip (registers, stack, etc). If used, it is
|
929 |
|
|
included by `tm-TTT.h'. It can be shared among many targets that
|
930 |
|
|
use the same processor.
|
931 |
|
|
|
932 |
|
|
`gdb/ARCH-tdep.c'
|
933 |
|
|
Similarly, there are often common subroutines that are shared by
|
934 |
|
|
all target machines that use this particular architecture.
|
935 |
|
|
|
936 |
|
|
If you are adding a new operating system for an existing CPU chip,
|
937 |
|
|
add a `config/tm-OS.h' file that describes the operating system
|
938 |
|
|
facilities that are unusual (extra symbol table info; the breakpoint
|
939 |
|
|
instruction needed; etc). Then write a `ARCH/tm-OS.h' that just
|
940 |
|
|
`#include's `tm-ARCH.h' and `config/tm-OS.h'.
|
941 |
|
|
|
942 |
|
|
|
943 |
|
|
File: gdbint.info, Node: Target Vector Definition, Next: Native Debugging, Prev: Target Architecture Definition, Up: Top
|
944 |
|
|
|
945 |
|
|
Target Vector Definition
|
946 |
|
|
************************
|
947 |
|
|
|
948 |
|
|
The target vector defines the interface between GDB's abstract
|
949 |
|
|
handling of target systems, and the nitty-gritty code that actually
|
950 |
|
|
exercises control over a process or a serial port. GDB includes some
|
951 |
|
|
30-40 different target vectors; however, each configuration of GDB
|
952 |
|
|
includes only a few of them.
|
953 |
|
|
|
954 |
|
|
File Targets
|
955 |
|
|
============
|
956 |
|
|
|
957 |
|
|
Both executables and core files have target vectors.
|
958 |
|
|
|
959 |
|
|
Standard Protocol and Remote Stubs
|
960 |
|
|
==================================
|
961 |
|
|
|
962 |
|
|
GDB's file `remote.c' talks a serial protocol to code that runs in
|
963 |
|
|
the target system. GDB provides several sample "stubs" that can be
|
964 |
|
|
integrated into target programs or operating systems for this purpose;
|
965 |
|
|
they are named `*-stub.c'.
|
966 |
|
|
|
967 |
|
|
The GDB user's manual describes how to put such a stub into your
|
968 |
|
|
target code. What follows is a discussion of integrating the SPARC
|
969 |
|
|
stub into a complicated operating system (rather than a simple
|
970 |
|
|
program), by Stu Grossman, the author of this stub.
|
971 |
|
|
|
972 |
|
|
The trap handling code in the stub assumes the following upon entry
|
973 |
|
|
to trap_low:
|
974 |
|
|
|
975 |
|
|
1. %l1 and %l2 contain pc and npc respectively at the time of the trap
|
976 |
|
|
|
977 |
|
|
2. traps are disabled
|
978 |
|
|
|
979 |
|
|
3. you are in the correct trap window
|
980 |
|
|
|
981 |
|
|
|
982 |
|
|
As long as your trap handler can guarantee those conditions, then
|
983 |
|
|
there is no reason why you shouldn't be able to `share' traps with the
|
984 |
|
|
stub. The stub has no requirement that it be jumped to directly from
|
985 |
|
|
the hardware trap vector. That is why it calls `exceptionHandler()',
|
986 |
|
|
which is provided by the external environment. For instance, this could
|
987 |
|
|
setup the hardware traps to actually execute code which calls the stub
|
988 |
|
|
first, and then transfers to its own trap handler.
|
989 |
|
|
|
990 |
|
|
For the most point, there probably won't be much of an issue with
|
991 |
|
|
`sharing' traps, as the traps we use are usually not used by the kernel,
|
992 |
|
|
and often indicate unrecoverable error conditions. Anyway, this is all
|
993 |
|
|
controlled by a table, and is trivial to modify. The most important
|
994 |
|
|
trap for us is for `ta 1'. Without that, we can't single step or do
|
995 |
|
|
breakpoints. Everything else is unnecessary for the proper operation
|
996 |
|
|
of the debugger/stub.
|
997 |
|
|
|
998 |
|
|
From reading the stub, it's probably not obvious how breakpoints
|
999 |
|
|
work. They are simply done by deposit/examine operations from GDB.
|
1000 |
|
|
|
1001 |
|
|
ROM Monitor Interface
|
1002 |
|
|
=====================
|
1003 |
|
|
|
1004 |
|
|
Custom Protocols
|
1005 |
|
|
================
|
1006 |
|
|
|
1007 |
|
|
Transport Layer
|
1008 |
|
|
===============
|
1009 |
|
|
|
1010 |
|
|
Builtin Simulator
|
1011 |
|
|
=================
|
1012 |
|
|
|
1013 |
|
|
|
1014 |
|
|
File: gdbint.info, Node: Native Debugging, Next: Support Libraries, Prev: Target Vector Definition, Up: Top
|
1015 |
|
|
|
1016 |
|
|
Native Debugging
|
1017 |
|
|
****************
|
1018 |
|
|
|
1019 |
|
|
Several files control GDB's configuration for native support:
|
1020 |
|
|
|
1021 |
|
|
`gdb/config/ARCH/XYZ.mh'
|
1022 |
|
|
Specifies Makefile fragments needed when hosting _or native_ on
|
1023 |
|
|
machine XYZ. In particular, this lists the required
|
1024 |
|
|
native-dependent object files, by defining `NATDEPFILES=...'.
|
1025 |
|
|
Also specifies the header file which describes native support on
|
1026 |
|
|
XYZ, by defining `NAT_FILE= nm-XYZ.h'. You can also define
|
1027 |
|
|
`NAT_CFLAGS', `NAT_ADD_FILES', `NAT_CLIBS', `NAT_CDEPS', etc.; see
|
1028 |
|
|
`Makefile.in'.
|
1029 |
|
|
|
1030 |
|
|
`gdb/config/ARCH/nm-XYZ.h'
|
1031 |
|
|
(`nm.h' is a link to this file, created by configure). Contains C
|
1032 |
|
|
macro definitions describing the native system environment, such as
|
1033 |
|
|
child process control and core file support.
|
1034 |
|
|
|
1035 |
|
|
`gdb/XYZ-nat.c'
|
1036 |
|
|
Contains any miscellaneous C code required for this native support
|
1037 |
|
|
of this machine. On some machines it doesn't exist at all.
|
1038 |
|
|
|
1039 |
|
|
There are some "generic" versions of routines that can be used by
|
1040 |
|
|
various systems. These can be customized in various ways by macros
|
1041 |
|
|
defined in your `nm-XYZ.h' file. If these routines work for the XYZ
|
1042 |
|
|
host, you can just include the generic file's name (with `.o', not
|
1043 |
|
|
`.c') in `NATDEPFILES'.
|
1044 |
|
|
|
1045 |
|
|
Otherwise, if your machine needs custom support routines, you will
|
1046 |
|
|
need to write routines that perform the same functions as the generic
|
1047 |
|
|
file. Put them into `XYZ-nat.c', and put `XYZ-nat.o' into
|
1048 |
|
|
`NATDEPFILES'.
|
1049 |
|
|
|
1050 |
|
|
`inftarg.c'
|
1051 |
|
|
This contains the _target_ops vector_ that supports Unix child
|
1052 |
|
|
processes on systems which use ptrace and wait to control the
|
1053 |
|
|
child.
|
1054 |
|
|
|
1055 |
|
|
`procfs.c'
|
1056 |
|
|
This contains the _target_ops vector_ that supports Unix child
|
1057 |
|
|
processes on systems which use /proc to control the child.
|
1058 |
|
|
|
1059 |
|
|
`fork-child.c'
|
1060 |
|
|
This does the low-level grunge that uses Unix system calls to do a
|
1061 |
|
|
"fork and exec" to start up a child process.
|
1062 |
|
|
|
1063 |
|
|
`infptrace.c'
|
1064 |
|
|
This is the low level interface to inferior processes for systems
|
1065 |
|
|
using the Unix `ptrace' call in a vanilla way.
|
1066 |
|
|
|
1067 |
|
|
Native core file Support
|
1068 |
|
|
========================
|
1069 |
|
|
|
1070 |
|
|
`core-aout.c::fetch_core_registers()'
|
1071 |
|
|
Support for reading registers out of a core file. This routine
|
1072 |
|
|
calls `register_addr()', see below. Now that BFD is used to read
|
1073 |
|
|
core files, virtually all machines should use `core-aout.c', and
|
1074 |
|
|
should just provide `fetch_core_registers' in `XYZ-nat.c' (or
|
1075 |
|
|
`REGISTER_U_ADDR' in `nm-XYZ.h').
|
1076 |
|
|
|
1077 |
|
|
`core-aout.c::register_addr()'
|
1078 |
|
|
If your `nm-XYZ.h' file defines the macro `REGISTER_U_ADDR(addr,
|
1079 |
|
|
blockend, regno)', it should be defined to set `addr' to the
|
1080 |
|
|
offset within the `user' struct of GDB register number `regno'.
|
1081 |
|
|
`blockend' is the offset within the "upage" of `u.u_ar0'. If
|
1082 |
|
|
`REGISTER_U_ADDR' is defined, `core-aout.c' will define the
|
1083 |
|
|
`register_addr()' function and use the macro in it. If you do not
|
1084 |
|
|
define `REGISTER_U_ADDR', but you are using the standard
|
1085 |
|
|
`fetch_core_registers()', you will need to define your own version
|
1086 |
|
|
of `register_addr()', put it into your `XYZ-nat.c' file, and be
|
1087 |
|
|
sure `XYZ-nat.o' is in the `NATDEPFILES' list. If you have your
|
1088 |
|
|
own `fetch_core_registers()', you may not need a separate
|
1089 |
|
|
`register_addr()'. Many custom `fetch_core_registers()'
|
1090 |
|
|
implementations simply locate the registers themselves.
|
1091 |
|
|
|
1092 |
|
|
When making GDB run native on a new operating system, to make it
|
1093 |
|
|
possible to debug core files, you will need to either write specific
|
1094 |
|
|
code for parsing your OS's core files, or customize `bfd/trad-core.c'.
|
1095 |
|
|
First, use whatever `#include' files your machine uses to define the
|
1096 |
|
|
struct of registers that is accessible (possibly in the u-area) in a
|
1097 |
|
|
core file (rather than `machine/reg.h'), and an include file that
|
1098 |
|
|
defines whatever header exists on a core file (e.g. the u-area or a
|
1099 |
|
|
`struct core'). Then modify `trad_unix_core_file_p()' to use these
|
1100 |
|
|
values to set up the section information for the data segment, stack
|
1101 |
|
|
segment, any other segments in the core file (perhaps shared library
|
1102 |
|
|
contents or control information), "registers" segment, and if there are
|
1103 |
|
|
two discontiguous sets of registers (e.g. integer and float), the
|
1104 |
|
|
"reg2" segment. This section information basically delimits areas in
|
1105 |
|
|
the core file in a standard way, which the section-reading routines in
|
1106 |
|
|
BFD know how to seek around in.
|
1107 |
|
|
|
1108 |
|
|
Then back in GDB, you need a matching routine called
|
1109 |
|
|
`fetch_core_registers()'. If you can use the generic one, it's in
|
1110 |
|
|
`core-aout.c'; if not, it's in your `XYZ-nat.c' file. It will be
|
1111 |
|
|
passed a char pointer to the entire "registers" segment, its length,
|
1112 |
|
|
and a zero; or a char pointer to the entire "regs2" segment, its
|
1113 |
|
|
length, and a 2. The routine should suck out the supplied register
|
1114 |
|
|
values and install them into GDB's "registers" array.
|
1115 |
|
|
|
1116 |
|
|
If your system uses `/proc' to control processes, and uses ELF
|
1117 |
|
|
format core files, then you may be able to use the same routines for
|
1118 |
|
|
reading the registers out of processes and out of core files.
|
1119 |
|
|
|
1120 |
|
|
ptrace
|
1121 |
|
|
======
|
1122 |
|
|
|
1123 |
|
|
/proc
|
1124 |
|
|
=====
|
1125 |
|
|
|
1126 |
|
|
win32
|
1127 |
|
|
=====
|
1128 |
|
|
|
1129 |
|
|
shared libraries
|
1130 |
|
|
================
|
1131 |
|
|
|
1132 |
|
|
Native Conditionals
|
1133 |
|
|
===================
|
1134 |
|
|
|
1135 |
|
|
When GDB is configured and compiled, various macros are defined or
|
1136 |
|
|
left undefined, to control compilation when the host and target systems
|
1137 |
|
|
are the same. These macros should be defined (or left undefined) in
|
1138 |
|
|
`nm-SYSTEM.h'.
|
1139 |
|
|
|
1140 |
|
|
`ATTACH_DETACH'
|
1141 |
|
|
If defined, then GDB will include support for the `attach' and
|
1142 |
|
|
`detach' commands.
|
1143 |
|
|
|
1144 |
|
|
`CHILD_PREPARE_TO_STORE'
|
1145 |
|
|
If the machine stores all registers at once in the child process,
|
1146 |
|
|
then define this to ensure that all values are correct. This
|
1147 |
|
|
usually entails a read from the child.
|
1148 |
|
|
|
1149 |
|
|
[Note that this is incorrectly defined in `xm-SYSTEM.h' files
|
1150 |
|
|
currently.]
|
1151 |
|
|
|
1152 |
|
|
`FETCH_INFERIOR_REGISTERS'
|
1153 |
|
|
Define this if the native-dependent code will provide its own
|
1154 |
|
|
routines `fetch_inferior_registers' and `store_inferior_registers'
|
1155 |
|
|
in `HOST-nat.c'. If this symbol is _not_ defined, and
|
1156 |
|
|
`infptrace.c' is included in this configuration, the default
|
1157 |
|
|
routines in `infptrace.c' are used for these functions.
|
1158 |
|
|
|
1159 |
|
|
`FILES_INFO_HOOK'
|
1160 |
|
|
(Only defined for Convex.)
|
1161 |
|
|
|
1162 |
|
|
`FP0_REGNUM'
|
1163 |
|
|
This macro is normally defined to be the number of the first
|
1164 |
|
|
floating point register, if the machine has such registers. As
|
1165 |
|
|
such, it would appear only in target-specific code. However,
|
1166 |
|
|
/proc support uses this to decide whether floats are in use on
|
1167 |
|
|
this target.
|
1168 |
|
|
|
1169 |
|
|
`GET_LONGJMP_TARGET'
|
1170 |
|
|
For most machines, this is a target-dependent parameter. On the
|
1171 |
|
|
DECstation and the Iris, this is a native-dependent parameter,
|
1172 |
|
|
since is needed to define it.
|
1173 |
|
|
|
1174 |
|
|
This macro determines the target PC address that longjmp() will
|
1175 |
|
|
jump to, assuming that we have just stopped at a longjmp
|
1176 |
|
|
breakpoint. It takes a CORE_ADDR * as argument, and stores the
|
1177 |
|
|
target PC value through this pointer. It examines the current
|
1178 |
|
|
state of the machine as needed.
|
1179 |
|
|
|
1180 |
|
|
`KERNEL_U_ADDR'
|
1181 |
|
|
Define this to the address of the `u' structure (the "user
|
1182 |
|
|
struct", also known as the "u-page") in kernel virtual memory. GDB
|
1183 |
|
|
needs to know this so that it can subtract this address from
|
1184 |
|
|
absolute addresses in the upage, that are obtained via ptrace or
|
1185 |
|
|
from core files. On systems that don't need this value, set it to
|
1186 |
|
|
zero.
|
1187 |
|
|
|
1188 |
|
|
`KERNEL_U_ADDR_BSD'
|
1189 |
|
|
Define this to cause GDB to determine the address of `u' at
|
1190 |
|
|
runtime, by using Berkeley-style `nlist' on the kernel's image in
|
1191 |
|
|
the root directory.
|
1192 |
|
|
|
1193 |
|
|
`KERNEL_U_ADDR_HPUX'
|
1194 |
|
|
Define this to cause GDB to determine the address of `u' at
|
1195 |
|
|
runtime, by using HP-style `nlist' on the kernel's image in the
|
1196 |
|
|
root directory.
|
1197 |
|
|
|
1198 |
|
|
`ONE_PROCESS_WRITETEXT'
|
1199 |
|
|
Define this to be able to, when a breakpoint insertion fails, warn
|
1200 |
|
|
the user that another process may be running with the same
|
1201 |
|
|
executable.
|
1202 |
|
|
|
1203 |
|
|
`PREPARE_TO_PROCEED SELECT_IT'
|
1204 |
|
|
This (ugly) macro allows a native configuration to customize the
|
1205 |
|
|
way the `proceed' function in `infrun.c' deals with switching
|
1206 |
|
|
between threads.
|
1207 |
|
|
|
1208 |
|
|
In a multi-threaded task we may select another thread and then
|
1209 |
|
|
continue or step. But if the old thread was stopped at a
|
1210 |
|
|
breakpoint, it will immediately cause another breakpoint stop
|
1211 |
|
|
without any execution (i.e. it will report a breakpoint hit
|
1212 |
|
|
incorrectly). So GDB must step over it first.
|
1213 |
|
|
|
1214 |
|
|
If defined, `PREPARE_TO_PROCEED' should check the current thread
|
1215 |
|
|
against the thread that reported the most recent event. If a
|
1216 |
|
|
step-over is required, it returns TRUE. If SELECT_IT is non-zero,
|
1217 |
|
|
it should reselect the old thread.
|
1218 |
|
|
|
1219 |
|
|
`PROC_NAME_FMT'
|
1220 |
|
|
Defines the format for the name of a `/proc' device. Should be
|
1221 |
|
|
defined in `nm.h' _only_ in order to override the default
|
1222 |
|
|
definition in `procfs.c'.
|
1223 |
|
|
|
1224 |
|
|
`PTRACE_FP_BUG'
|
1225 |
|
|
mach386-xdep.c
|
1226 |
|
|
|
1227 |
|
|
`PTRACE_ARG3_TYPE'
|
1228 |
|
|
The type of the third argument to the `ptrace' system call, if it
|
1229 |
|
|
exists and is different from `int'.
|
1230 |
|
|
|
1231 |
|
|
`REGISTER_U_ADDR'
|
1232 |
|
|
Defines the offset of the registers in the "u area".
|
1233 |
|
|
|
1234 |
|
|
`SHELL_COMMAND_CONCAT'
|
1235 |
|
|
If defined, is a string to prefix on the shell command used to
|
1236 |
|
|
start the inferior.
|
1237 |
|
|
|
1238 |
|
|
`SHELL_FILE'
|
1239 |
|
|
If defined, this is the name of the shell to use to run the
|
1240 |
|
|
inferior. Defaults to `"/bin/sh"'.
|
1241 |
|
|
|
1242 |
|
|
`SOLIB_ADD (filename, from_tty, targ)'
|
1243 |
|
|
Define this to expand into an expression that will cause the
|
1244 |
|
|
symbols in FILENAME to be added to GDB's symbol table.
|
1245 |
|
|
|
1246 |
|
|
`SOLIB_CREATE_INFERIOR_HOOK'
|
1247 |
|
|
Define this to expand into any shared-library-relocation code that
|
1248 |
|
|
you want to be run just after the child process has been forked.
|
1249 |
|
|
|
1250 |
|
|
`START_INFERIOR_TRAPS_EXPECTED'
|
1251 |
|
|
When starting an inferior, GDB normally expects to trap twice;
|
1252 |
|
|
once when the shell execs, and once when the program itself execs.
|
1253 |
|
|
If the actual number of traps is something other than 2, then
|
1254 |
|
|
define this macro to expand into the number expected.
|
1255 |
|
|
|
1256 |
|
|
`SVR4_SHARED_LIBS'
|
1257 |
|
|
Define this to indicate that SVR4-style shared libraries are in
|
1258 |
|
|
use.
|
1259 |
|
|
|
1260 |
|
|
`USE_PROC_FS'
|
1261 |
|
|
This determines whether small routines in `*-tdep.c', which
|
1262 |
|
|
translate register values between GDB's internal representation
|
1263 |
|
|
and the /proc representation, are compiled.
|
1264 |
|
|
|
1265 |
|
|
`U_REGS_OFFSET'
|
1266 |
|
|
This is the offset of the registers in the upage. It need only be
|
1267 |
|
|
defined if the generic ptrace register access routines in
|
1268 |
|
|
`infptrace.c' are being used (that is, `infptrace.c' is configured
|
1269 |
|
|
in, and `FETCH_INFERIOR_REGISTERS' is not defined). If the
|
1270 |
|
|
default value from `infptrace.c' is good enough, leave it
|
1271 |
|
|
undefined.
|
1272 |
|
|
|
1273 |
|
|
The default value means that u.u_ar0 _points to_ the location of
|
1274 |
|
|
the registers. I'm guessing that `#define U_REGS_OFFSET 0' means
|
1275 |
|
|
that u.u_ar0 _is_ the location of the registers.
|
1276 |
|
|
|
1277 |
|
|
`CLEAR_SOLIB'
|
1278 |
|
|
objfiles.c
|
1279 |
|
|
|
1280 |
|
|
`DEBUG_PTRACE'
|
1281 |
|
|
Define this to debug ptrace calls.
|
1282 |
|
|
|