OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [insight/] [gdb/] [doc/] [gdbint.info-3] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 578 markom
This is gdbint.info, produced by makeinfo version 4.0 from
2
./gdbint.texinfo.
3
 
4
INFO-DIR-SECTION Programming & development tools.
5
START-INFO-DIR-ENTRY
6
START-INFO-DIR-ENTRY
7
* Gdb-Internals: (gdbint).      The GNU debugger's internals.
8
END-INFO-DIR-ENTRY
9
END-INFO-DIR-ENTRY
10
 
11
   This file documents the internals of the GNU debugger GDB.
12
Copyright 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001    Free
13
Software Foundation, Inc.  Contributed by Cygnus Solutions.  Written by
14
John Gilmore.  Second Edition by Stan Shebs.
15
 
16
   Permission is granted to copy, distribute and/or modify this document
17
under the terms of the GNU Free Documentation License, Version 1.1 or
18
any later version published by the Free Software Foundation; with the
19
Invariant Sections being "Algorithms" and "Porting GDB", with the
20
Front-Cover texts being "A GNU Manual," and with the Back-Cover Texts
21
as in (a) below.
22
 
23
   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
24
modify this GNU Manual, like GNU software.  Copies published by the Free
25
Software Foundation raise funds for GNU development."
26
 
27

28
File: gdbint.info,  Node: Target Architecture Definition,  Next: Target Vector Definition,  Prev: Host Definition,  Up: Top
29
 
30
Target Architecture Definition
31
******************************
32
 
33
   GDB's target architecture defines what sort of machine-language
34
programs GDB can work with, and how it works with them.
35
 
36
   The target architecture object is implemented as the C structure
37
`struct gdbarch *'.  The structure, and its methods, are generated
38
using the Bourn shell script `gdbarch.sh'.
39
 
40
Registers and Memory
41
====================
42
 
43
   GDB's model of the target machine is rather simple.  GDB assumes the
44
machine includes a bank of registers and a block of memory.  Each
45
register may have a different size.
46
 
47
   GDB does not have a magical way to match up with the compiler's idea
48
of which registers are which; however, it is critical that they do
49
match up accurately.  The only way to make this work is to get accurate
50
information about the order that the compiler uses, and to reflect that
51
in the `REGISTER_NAME' and related macros.
52
 
53
   GDB can handle big-endian, little-endian, and bi-endian
54
architectures.
55
 
56
Pointers Are Not Always Addresses
57
=================================
58
 
59
   On almost all 32-bit architectures, the representation of a pointer
60
is indistinguishable from the representation of some fixed-length number
61
whose value is the byte address of the object pointed to.  On such
62
machines, the words "pointer" and "address" can be used interchangeably.
63
However, architectures with smaller word sizes are often cramped for
64
address space, so they may choose a pointer representation that breaks
65
this identity, and allows a larger code address space.
66
 
67
   For example, the Mitsubishi D10V is a 16-bit VLIW processor whose
68
instructions are 32 bits long(1).  If the D10V used ordinary byte
69
addresses to refer to code locations, then the processor would only be
70
able to address 64kb of instructions.  However, since instructions must
71
be aligned on four-byte boundaries, the low two bits of any valid
72
instruction's byte address are always zero--byte addresses waste two
73
bits.  So instead of byte addresses, the D10V uses word addresses--byte
74
addresses shifted right two bits--to refer to code.  Thus, the D10V can
75
use 16-bit words to address 256kb of code space.
76
 
77
   However, this means that code pointers and data pointers have
78
different forms on the D10V.  The 16-bit word `0xC020' refers to byte
79
address `0xC020' when used as a data address, but refers to byte address
80
`0x30080' when used as a code address.
81
 
82
   (The D10V also uses separate code and data address spaces, which also
83
affects the correspondence between pointers and addresses, but we're
84
going to ignore that here; this example is already too long.)
85
 
86
   To cope with architectures like this--the D10V is not the only
87
one!--GDB tries to distinguish between "addresses", which are byte
88
numbers, and "pointers", which are the target's representation of an
89
address of a particular type of data.  In the example above, `0xC020'
90
is the pointer, which refers to one of the addresses `0xC020' or
91
`0x30080', depending on the type imposed upon it.  GDB provides
92
functions for turning a pointer into an address and vice versa, in the
93
appropriate way for the current architecture.
94
 
95
   Unfortunately, since addresses and pointers are identical on almost
96
all processors, this distinction tends to bit-rot pretty quickly.  Thus,
97
each time you port GDB to an architecture which does distinguish
98
between pointers and addresses, you'll probably need to clean up some
99
architecture-independent code.
100
 
101
   Here are functions which convert between pointers and addresses:
102
 
103
 - Function: CORE_ADDR extract_typed_address (void *BUF, struct type
104
          *TYPE)
105
     Treat the bytes at BUF as a pointer or reference of type TYPE, and
106
     return the address it represents, in a manner appropriate for the
107
     current architecture.  This yields an address GDB can use to read
108
     target memory, disassemble, etc.  Note that BUF refers to a buffer
109
     in GDB's memory, not the inferior's.
110
 
111
     For example, if the current architecture is the Intel x86, this
112
     function extracts a little-endian integer of the appropriate
113
     length from BUF and returns it.  However, if the current
114
     architecture is the D10V, this function will return a 16-bit
115
     integer extracted from BUF, multiplied by four if TYPE is a
116
     pointer to a function.
117
 
118
     If TYPE is not a pointer or reference type, then this function
119
     will signal an internal error.
120
 
121
 - Function: CORE_ADDR store_typed_address (void *BUF, struct type
122
          *TYPE, CORE_ADDR ADDR)
123
     Store the address ADDR in BUF, in the proper format for a pointer
124
     of type TYPE in the current architecture.  Note that BUF refers to
125
     a buffer in GDB's memory, not the inferior's.
126
 
127
     For example, if the current architecture is the Intel x86, this
128
     function stores ADDR unmodified as a little-endian integer of the
129
     appropriate length in BUF.  However, if the current architecture
130
     is the D10V, this function divides ADDR by four if TYPE is a
131
     pointer to a function, and then stores it in BUF.
132
 
133
     If TYPE is not a pointer or reference type, then this function
134
     will signal an internal error.
135
 
136
 - Function: CORE_ADDR value_as_pointer (value_ptr VAL)
137
     Assuming that VAL is a pointer, return the address it represents,
138
     as appropriate for the current architecture.
139
 
140
     This function actually works on integral values, as well as
141
     pointers.  For pointers, it performs architecture-specific
142
     conversions as described above for `extract_typed_address'.
143
 
144
 - Function: CORE_ADDR value_from_pointer (struct type *TYPE, CORE_ADDR
145
          ADDR)
146
     Create and return a value representing a pointer of type TYPE to
147
     the address ADDR, as appropriate for the current architecture.
148
     This function performs architecture-specific conversions as
149
     described above for `store_typed_address'.
150
 
151
   GDB also provides functions that do the same tasks, but assume that
152
pointers are simply byte addresses; they aren't sensitive to the
153
current architecture, beyond knowing the appropriate endianness.
154
 
155
 - Function: CORE_ADDR extract_address (void *ADDR, int len)
156
     Extract a LEN-byte number from ADDR in the appropriate endianness
157
     for the current architecture, and return it.  Note that ADDR
158
     refers to GDB's memory, not the inferior's.
159
 
160
     This function should only be used in architecture-specific code; it
161
     doesn't have enough information to turn bits into a true address
162
     in the appropriate way for the current architecture.  If you can,
163
     use `extract_typed_address' instead.
164
 
165
 - Function: void store_address (void *ADDR, int LEN, LONGEST VAL)
166
     Store VAL at ADDR as a LEN-byte integer, in the appropriate
167
     endianness for the current architecture.  Note that ADDR refers to
168
     a buffer in GDB's memory, not the inferior's.
169
 
170
     This function should only be used in architecture-specific code; it
171
     doesn't have enough information to turn a true address into bits
172
     in the appropriate way for the current architecture.  If you can,
173
     use `store_typed_address' instead.
174
 
175
   Here are some macros which architectures can define to indicate the
176
relationship between pointers and addresses.  These have default
177
definitions, appropriate for architectures on which all pointers are
178
simple byte addresses.
179
 
180
 - Target Macro: CORE_ADDR POINTER_TO_ADDRESS (struct type *TYPE, char
181
          *BUF)
182
     Assume that BUF holds a pointer of type TYPE, in the appropriate
183
     format for the current architecture.  Return the byte address the
184
     pointer refers to.
185
 
186
     This function may safely assume that TYPE is either a pointer or a
187
     C++ reference type.
188
 
189
 - Target Macro: void ADDRESS_TO_POINTER (struct type *TYPE, char *BUF,
190
          CORE_ADDR ADDR)
191
     Store in BUF a pointer of type TYPE representing the address ADDR,
192
     in the appropriate format for the current architecture.
193
 
194
     This function may safely assume that TYPE is either a pointer or a
195
     C++ reference type.
196
 
197
Using Different Register and Memory Data Representations
198
========================================================
199
 
200
   _Maintainer's note: The way GDB manipulates registers is undergoing
201
significant change.  Many of the macros and functions refered to in the
202
sections below are likely to be made obsolete.  See the file `TODO' for
203
more up-to-date information._
204
 
205
   Some architectures use one representation for a value when it lives
206
in a register, but use a different representation when it lives in
207
memory.  In GDB's terminology, the "raw" representation is the one used
208
in the target registers, and the "virtual" representation is the one
209
used in memory, and within GDB `struct value' objects.
210
 
211
   For almost all data types on almost all architectures, the virtual
212
and raw representations are identical, and no special handling is
213
needed.  However, they do occasionally differ.  For example:
214
 
215
   * The x86 architecture supports an 80-bit `long double' type.
216
     However, when we store those values in memory, they occupy twelve
217
     bytes: the floating-point number occupies the first ten, and the
218
     final two bytes are unused.  This keeps the values aligned on
219
     four-byte boundaries, allowing more efficient access.  Thus, the
220
     x86 80-bit floating-point type is the raw representation, and the
221
     twelve-byte loosely-packed arrangement is the virtual
222
     representation.
223
 
224
   * Some 64-bit MIPS targets present 32-bit registers to GDB as 64-bit
225
     registers, with garbage in their upper bits.  GDB ignores the top
226
     32 bits.  Thus, the 64-bit form, with garbage in the upper 32
227
     bits, is the raw representation, and the trimmed 32-bit
228
     representation is the virtual representation.
229
 
230
   In general, the raw representation is determined by the
231
architecture, or GDB's interface to the architecture, while the virtual
232
representation can be chosen for GDB's convenience.  GDB's register
233
file, `registers', holds the register contents in raw format, and the
234
GDB remote protocol transmits register values in raw format.
235
 
236
   Your architecture may define the following macros to request
237
conversions between the raw and virtual format:
238
 
239
 - Target Macro: int REGISTER_CONVERTIBLE (int REG)
240
     Return non-zero if register number REG's value needs different raw
241
     and virtual formats.
242
 
243
     You should not use `REGISTER_CONVERT_TO_VIRTUAL' for a register
244
     unless this macro returns a non-zero value for that register.
245
 
246
 - Target Macro: int REGISTER_RAW_SIZE (int REG)
247
     The size of register number REG's raw value.  This is the number
248
     of bytes the register will occupy in `registers', or in a GDB
249
     remote protocol packet.
250
 
251
 - Target Macro: int REGISTER_VIRTUAL_SIZE (int REG)
252
     The size of register number REG's value, in its virtual format.
253
     This is the size a `struct value''s buffer will have, holding that
254
     register's value.
255
 
256
 - Target Macro: struct type *REGISTER_VIRTUAL_TYPE (int REG)
257
     This is the type of the virtual representation of register number
258
     REG.  Note that there is no need for a macro giving a type for the
259
     register's raw form; once the register's value has been obtained,
260
     GDB always uses the virtual form.
261
 
262
 - Target Macro: void REGISTER_CONVERT_TO_VIRTUAL (int REG, struct type
263
          *TYPE, char *FROM, char *TO)
264
     Convert the value of register number REG to TYPE, which should
265
     always be `REGISTER_VIRTUAL_TYPE (REG)'.  The buffer at FROM holds
266
     the register's value in raw format; the macro should convert the
267
     value to virtual format, and place it at TO.
268
 
269
     Note that `REGISTER_CONVERT_TO_VIRTUAL' and
270
     `REGISTER_CONVERT_TO_RAW' take their REG and TYPE arguments in
271
     different orders.
272
 
273
     You should only use `REGISTER_CONVERT_TO_VIRTUAL' with registers
274
     for which the `REGISTER_CONVERTIBLE' macro returns a non-zero
275
     value.
276
 
277
 - Target Macro: void REGISTER_CONVERT_TO_RAW (struct type *TYPE, int
278
          REG, char *FROM, char *TO)
279
     Convert the value of register number REG to TYPE, which should
280
     always be `REGISTER_VIRTUAL_TYPE (REG)'.  The buffer at FROM holds
281
     the register's value in raw format; the macro should convert the
282
     value to virtual format, and place it at TO.
283
 
284
     Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW
285
     take their REG and TYPE arguments in different orders.
286
 
287
Frame Interpretation
288
====================
289
 
290
Inferior Call Setup
291
===================
292
 
293
Compiler Characteristics
294
========================
295
 
296
Target Conditionals
297
===================
298
 
299
   This section describes the macros that you can use to define the
300
target machine.
301
 
302
`ADDITIONAL_OPTIONS'
303
`ADDITIONAL_OPTION_CASES'
304
`ADDITIONAL_OPTION_HANDLER'
305
`ADDITIONAL_OPTION_HELP'
306
     These are a set of macros that allow the addition of additional
307
     command line options to GDB.  They are currently used only for the
308
     unsupported i960 Nindy target, and should not be used in any other
309
     configuration.
310
 
311
`ADDR_BITS_REMOVE (addr)'
312
     If a raw machine instruction address includes any bits that are not
313
     really part of the address, then define this macro to expand into
314
     an expression that zeroes those bits in ADDR.  This is only used
315
     for addresses of instructions, and even then not in all contexts.
316
 
317
     For example, the two low-order bits of the PC on the
318
     Hewlett-Packard PA 2.0 architecture contain the privilege level of
319
     the corresponding instruction.  Since instructions must always be
320
     aligned on four-byte boundaries, the processor masks out these
321
     bits to generate the actual address of the instruction.
322
     ADDR_BITS_REMOVE should filter out these bits with an expression
323
     such as `((addr) & ~3)'.
324
 
325
`ADDRESS_TO_POINTER (TYPE, BUF, ADDR)'
326
     Store in BUF a pointer of type TYPE representing the address ADDR,
327
     in the appropriate format for the current architecture.  This
328
     macro may safely assume that TYPE is either a pointer or a C++
329
     reference type.  *Note Pointers Are Not Always Addresses: Target
330
     Architecture Definition.
331
 
332
`BEFORE_MAIN_LOOP_HOOK'
333
     Define this to expand into any code that you want to execute
334
     before the main loop starts.  Although this is not, strictly
335
     speaking, a target conditional, that is how it is currently being
336
     used.  Note that if a configuration were to define it one way for
337
     a host and a different way for the target, GDB will probably not
338
     compile, let alone run correctly.  This macro is currently used
339
     only for the unsupported i960 Nindy target, and should not be used
340
     in any other configuration.
341
 
342
`BELIEVE_PCC_PROMOTION'
343
     Define if the compiler promotes a `short' or `char' parameter to
344
     an `int', but still reports the parameter as its original type,
345
     rather than the promoted type.
346
 
347
`BELIEVE_PCC_PROMOTION_TYPE'
348
     Define this if GDB should believe the type of a `short' argument
349
     when compiled by `pcc', but look within a full int space to get
350
     its value.  Only defined for Sun-3 at present.
351
 
352
`BITS_BIG_ENDIAN'
353
     Define this if the numbering of bits in the targets does *not*
354
     match the endianness of the target byte order.  A value of 1 means
355
     that the bits are numbered in a big-endian bit order, 0 means
356
     little-endian.
357
 
358
`BREAKPOINT'
359
     This is the character array initializer for the bit pattern to put
360
     into memory where a breakpoint is set.  Although it's common to
361
     use a trap instruction for a breakpoint, it's not required; for
362
     instance, the bit pattern could be an invalid instruction.  The
363
     breakpoint must be no longer than the shortest instruction of the
364
     architecture.
365
 
366
     `BREAKPOINT' has been deprecated in favor of `BREAKPOINT_FROM_PC'.
367
 
368
`BIG_BREAKPOINT'
369
`LITTLE_BREAKPOINT'
370
     Similar to BREAKPOINT, but used for bi-endian targets.
371
 
372
     `BIG_BREAKPOINT' and `LITTLE_BREAKPOINT' have been deprecated in
373
     favor of `BREAKPOINT_FROM_PC'.
374
 
375
`REMOTE_BREAKPOINT'
376
`LITTLE_REMOTE_BREAKPOINT'
377
`BIG_REMOTE_BREAKPOINT'
378
     Similar to BREAKPOINT, but used for remote targets.
379
 
380
     `BIG_REMOTE_BREAKPOINT' and `LITTLE_REMOTE_BREAKPOINT' have been
381
     deprecated in favor of `BREAKPOINT_FROM_PC'.
382
 
383
`BREAKPOINT_FROM_PC (PCPTR, LENPTR)'
384
     Use the program counter to determine the contents and size of a
385
     breakpoint instruction.  It returns a pointer to a string of bytes
386
     that encode a breakpoint instruction, stores the length of the
387
     string to *LENPTR, and adjusts pc (if necessary) to point to the
388
     actual memory location where the breakpoint should be inserted.
389
 
390
     Although it is common to use a trap instruction for a breakpoint,
391
     it's not required; for instance, the bit pattern could be an
392
     invalid instruction.  The breakpoint must be no longer than the
393
     shortest instruction of the architecture.
394
 
395
     Replaces all the other BREAKPOINT macros.
396
 
397
`MEMORY_INSERT_BREAKPOINT (ADDR, CONTENTS_CACHE)'
398
`MEMORY_REMOVE_BREAKPOINT (ADDR, CONTENTS_CACHE)'
399
     Insert or remove memory based breakpoints.  Reasonable defaults
400
     (`default_memory_insert_breakpoint' and
401
     `default_memory_remove_breakpoint' respectively) have been
402
     provided so that it is not necessary to define these for most
403
     architectures.  Architectures which may want to define
404
     `MEMORY_INSERT_BREAKPOINT' and `MEMORY_REMOVE_BREAKPOINT' will
405
     likely have instructions that are oddly sized or are not stored in
406
     a conventional manner.
407
 
408
     It may also be desirable (from an efficiency standpoint) to define
409
     custom breakpoint insertion and removal routines if
410
     `BREAKPOINT_FROM_PC' needs to read the target's memory for some
411
     reason.
412
 
413
`CALL_DUMMY_P'
414
     A C expresson that is non-zero when the target suports inferior
415
     function calls.
416
 
417
`CALL_DUMMY_WORDS'
418
     Pointer to an array of `LONGEST' words of data containing
419
     host-byte-ordered `REGISTER_BYTES' sized values that partially
420
     specify the sequence of instructions needed for an inferior
421
     function call.
422
 
423
     Should be deprecated in favor of a macro that uses
424
     target-byte-ordered data.
425
 
426
`SIZEOF_CALL_DUMMY_WORDS'
427
     The size of `CALL_DUMMY_WORDS'.  When `CALL_DUMMY_P' this must
428
     return a positive value.  See also `CALL_DUMMY_LENGTH'.
429
 
430
`CALL_DUMMY'
431
     A static initializer for `CALL_DUMMY_WORDS'.  Deprecated.
432
 
433
`CALL_DUMMY_LOCATION'
434
     See the file `inferior.h'.
435
 
436
`CALL_DUMMY_STACK_ADJUST'
437
     Stack adjustment needed when performing an inferior function call.
438
 
439
     Should be deprecated in favor of something like `STACK_ALIGN'.
440
 
441
`CALL_DUMMY_STACK_ADJUST_P'
442
     Predicate for use of `CALL_DUMMY_STACK_ADJUST'.
443
 
444
     Should be deprecated in favor of something like `STACK_ALIGN'.
445
 
446
`CANNOT_FETCH_REGISTER (REGNO)'
447
     A C expression that should be nonzero if REGNO cannot be fetched
448
     from an inferior process.  This is only relevant if
449
     `FETCH_INFERIOR_REGISTERS' is not defined.
450
 
451
`CANNOT_STORE_REGISTER (REGNO)'
452
     A C expression that should be nonzero if REGNO should not be
453
     written to the target.  This is often the case for program
454
     counters, status words, and other special registers.  If this is
455
     not defined, GDB will assume that all registers may be written.
456
 
457
`DO_DEFERRED_STORES'
458
`CLEAR_DEFERRED_STORES'
459
     Define this to execute any deferred stores of registers into the
460
     inferior, and to cancel any deferred stores.
461
 
462
     Currently only implemented correctly for native Sparc
463
     configurations?
464
 
465
`COERCE_FLOAT_TO_DOUBLE (FORMAL, ACTUAL)'
466
     If we are calling a function by hand, and the function was declared
467
     (according to the debug info) without a prototype, should we
468
     automatically promote `float's to `double's?  This macro must
469
     evaluate to non-zero if we should, or zero if we should leave the
470
     value alone.
471
 
472
     The argument ACTUAL is the type of the value we want to pass to
473
     the function.  The argument FORMAL is the type of this argument,
474
     as it appears in the function's definition.  Note that FORMAL may
475
     be zero if we have no debugging information for the function, or if
476
     we're passing more arguments than are officially declared (for
477
     example, varargs).  This macro is never invoked if the function
478
     definitely has a prototype.
479
 
480
     The default behavior is to promote only when we have no type
481
     information for the formal parameter.  This is different from the
482
     obvious behavior, which would be to promote whenever we have no
483
     prototype, just as the compiler does.  It's annoying, but some
484
     older targets rely on this.  If you want GDB to follow the typical
485
     compiler behavior--to always promote when there is no prototype in
486
     scope--your gdbarch `init' function can call
487
     `set_gdbarch_coerce_float_to_double' and select the
488
     `standard_coerce_float_to_double' function.
489
 
490
`CPLUS_MARKER'
491
     Define this to expand into the character that G++ uses to
492
     distinguish compiler-generated identifiers from
493
     programmer-specified identifiers.  By default, this expands into
494
     `'$''.  Most System V targets should define this to `'.''.
495
 
496
`DBX_PARM_SYMBOL_CLASS'
497
     Hook for the `SYMBOL_CLASS' of a parameter when decoding DBX symbol
498
     information.  In the i960, parameters can be stored as locals or as
499
     args, depending on the type of the debug record.
500
 
501
`DECR_PC_AFTER_BREAK'
502
     Define this to be the amount by which to decrement the PC after the
503
     program encounters a breakpoint.  This is often the number of
504
     bytes in `BREAKPOINT', though not always.  For most targets this
505
     value will be 0.
506
 
507
`DECR_PC_AFTER_HW_BREAK'
508
     Similarly, for hardware breakpoints.
509
 
510
`DISABLE_UNSETTABLE_BREAK (ADDR)'
511
     If defined, this should evaluate to 1 if ADDR is in a shared
512
     library in which breakpoints cannot be set and so should be
513
     disabled.
514
 
515
`DO_REGISTERS_INFO'
516
     If defined, use this to print the value of a register or all
517
     registers.
518
 
519
`DWARF_REG_TO_REGNUM'
520
     Convert DWARF register number into GDB regnum.  If not defined, no
521
     conversion will be performed.
522
 
523
`DWARF2_REG_TO_REGNUM'
524
     Convert DWARF2 register number into GDB regnum.  If not defined,
525
     no conversion will be performed.
526
 
527
`ECOFF_REG_TO_REGNUM'
528
     Convert ECOFF register number into GDB regnum.  If not defined, no
529
     conversion will be performed.
530
 
531
`END_OF_TEXT_DEFAULT'
532
     This is an expression that should designate the end of the text
533
     section.
534
 
535
`EXTRACT_RETURN_VALUE(TYPE, REGBUF, VALBUF)'
536
     Define this to extract a function's return value of type TYPE from
537
     the raw register state REGBUF and copy that, in virtual format,
538
     into VALBUF.
539
 
540
`EXTRACT_STRUCT_VALUE_ADDRESS(REGBUF)'
541
     When defined, extract from the array REGBUF (containing the raw
542
     register state) the `CORE_ADDR' at which a function should return
543
     its structure value.
544
 
545
     If not defined, `EXTRACT_RETURN_VALUE' is used.
546
 
547
`EXTRACT_STRUCT_VALUE_ADDRESS_P()'
548
     Predicate for `EXTRACT_STRUCT_VALUE_ADDRESS'.
549
 
550
`FLOAT_INFO'
551
     If defined, then the `info float' command will print information
552
     about the processor's floating point unit.
553
 
554
`FP_REGNUM'
555
     If the virtual frame pointer is kept in a register, then define
556
     this macro to be the number (greater than or equal to zero) of
557
     that register.
558
 
559
     This should only need to be defined if `TARGET_READ_FP' and
560
     `TARGET_WRITE_FP' are not defined.
561
 
562
`FRAMELESS_FUNCTION_INVOCATION(FI)'
563
     Define this to an expression that returns 1 if the function
564
     invocation represented by FI does not have a stack frame
565
     associated with it.  Otherwise return 0.
566
 
567
`FRAME_ARGS_ADDRESS_CORRECT'
568
     See `stack.c'.
569
 
570
`FRAME_CHAIN(FRAME)'
571
     Given FRAME, return a pointer to the calling frame.
572
 
573
`FRAME_CHAIN_COMBINE(CHAIN, FRAME)'
574
     Define this to take the frame chain pointer and the frame's nominal
575
     address and produce the nominal address of the caller's frame.
576
     Presently only defined for HP PA.
577
 
578
`FRAME_CHAIN_VALID(CHAIN, THISFRAME)'
579
     Define this to be an expression that returns zero if the given
580
     frame is an outermost frame, with no caller, and nonzero
581
     otherwise.  Several common definitions are available:
582
 
583
        * `file_frame_chain_valid' is nonzero if the chain pointer is
584
          nonzero and given frame's PC is not inside the startup file
585
          (such as `crt0.o').
586
 
587
        * `func_frame_chain_valid' is nonzero if the chain pointer is
588
          nonzero and the given frame's PC is not in `main' or a known
589
          entry point function (such as `_start').
590
 
591
        * `generic_file_frame_chain_valid' and
592
          `generic_func_frame_chain_valid' are equivalent
593
          implementations for targets using generic dummy frames.
594
 
595
`FRAME_INIT_SAVED_REGS(FRAME)'
596
     See `frame.h'.  Determines the address of all registers in the
597
     current stack frame storing each in `frame->saved_regs'.  Space for
598
     `frame->saved_regs' shall be allocated by `FRAME_INIT_SAVED_REGS'
599
     using either `frame_saved_regs_zalloc' or `frame_obstack_alloc'.
600
 
601
     `FRAME_FIND_SAVED_REGS' and `EXTRA_FRAME_INFO' are deprecated.
602
 
603
`FRAME_NUM_ARGS (FI)'
604
     For the frame described by FI return the number of arguments that
605
     are being passed.  If the number of arguments is not known, return
606
     `-1'.
607
 
608
`FRAME_SAVED_PC(FRAME)'
609
     Given FRAME, return the pc saved there.  This is the return
610
     address.
611
 
612
`FUNCTION_EPILOGUE_SIZE'
613
     For some COFF targets, the `x_sym.x_misc.x_fsize' field of the
614
     function end symbol is 0.  For such targets, you must define
615
     `FUNCTION_EPILOGUE_SIZE' to expand into the standard size of a
616
     function's epilogue.
617
 
618
`FUNCTION_START_OFFSET'
619
     An integer, giving the offset in bytes from a function's address
620
     (as used in the values of symbols, function pointers, etc.), and
621
     the function's first genuine instruction.
622
 
623
     This is zero on almost all machines: the function's address is
624
     usually the address of its first instruction.  However, on the
625
     VAX, for example, each function starts with two bytes containing a
626
     bitmask indicating which registers to save upon entry to the
627
     function.  The VAX `call' instructions check this value, and save
628
     the appropriate registers automatically.  Thus, since the offset
629
     from the function's address to its first instruction is two bytes,
630
     `FUNCTION_START_OFFSET' would be 2 on the VAX.
631
 
632
`GCC_COMPILED_FLAG_SYMBOL'
633
`GCC2_COMPILED_FLAG_SYMBOL'
634
     If defined, these are the names of the symbols that GDB will look
635
     for to detect that GCC compiled the file.  The default symbols are
636
     `gcc_compiled.' and `gcc2_compiled.', respectively.  (Currently
637
     only defined for the Delta 68.)
638
 
639
`GDB_MULTI_ARCH'
640
     If defined and non-zero, enables suport for multiple architectures
641
     within GDB.
642
 
643
     This support can be enabled at two levels.  At level one, only
644
     definitions for previously undefined macros are provided; at level
645
     two, a multi-arch definition of all architecture dependant macros
646
     will be defined.
647
 
648
`GDB_TARGET_IS_HPPA'
649
     This determines whether horrible kludge code in `dbxread.c' and
650
     `partial-stab.h' is used to mangle multiple-symbol-table files from
651
     HPPA's.  This should all be ripped out, and a scheme like
652
     `elfread.c' used instead.
653
 
654
`GET_LONGJMP_TARGET'
655
     For most machines, this is a target-dependent parameter.  On the
656
     DECstation and the Iris, this is a native-dependent parameter,
657
     since trhe header file `setjmp.h' is needed to define it.
658
 
659
     This macro determines the target PC address that `longjmp' will
660
     jump to, assuming that we have just stopped at a `longjmp'
661
     breakpoint.  It takes a `CORE_ADDR *' as argument, and stores the
662
     target PC value through this pointer.  It examines the current
663
     state of the machine as needed.
664
 
665
`GET_SAVED_REGISTER'
666
     Define this if you need to supply your own definition for the
667
     function `get_saved_register'.
668
 
669
`HAVE_REGISTER_WINDOWS'
670
     Define this if the target has register windows.
671
 
672
`REGISTER_IN_WINDOW_P (REGNUM)'
673
     Define this to be an expression that is 1 if the given register is
674
     in the window.
675
 
676
`IBM6000_TARGET'
677
     Shows that we are configured for an IBM RS/6000 target.  This
678
     conditional should be eliminated (FIXME) and replaced by
679
     feature-specific macros.  It was introduced in a haste and we are
680
     repenting at leisure.
681
 
682
`I386_USE_GENERIC_WATCHPOINTS'
683
     An x86-based target can define this to use the generic x86
684
     watchpoint support; see *Note I386_USE_GENERIC_WATCHPOINTS:
685
     Algorithms.
686
 
687
`SYMBOLS_CAN_START_WITH_DOLLAR'
688
     Some systems have routines whose names start with `$'.  Giving this
689
     macro a non-zero value tells GDB's expression parser to check for
690
     such routines when parsing tokens that begin with `$'.
691
 
692
     On HP-UX, certain system routines (millicode) have names beginning
693
     with `$' or `$$'.  For example, `$$dyncall' is a millicode routine
694
     that handles inter-space procedure calls on PA-RISC.
695
 
696
`IEEE_FLOAT'
697
     Define this if the target system uses IEEE-format floating point
698
     numbers.
699
 
700
`INIT_EXTRA_FRAME_INFO (FROMLEAF, FRAME)'
701
     If additional information about the frame is required this should
702
     be stored in `frame->extra_info'.  Space for `frame->extra_info'
703
     is allocated using `frame_obstack_alloc'.
704
 
705
`INIT_FRAME_PC (FROMLEAF, PREV)'
706
     This is a C statement that sets the pc of the frame pointed to by
707
     PREV.  [By default...]
708
 
709
`INNER_THAN (LHS, RHS)'
710
     Returns non-zero if stack address LHS is inner than (nearer to the
711
     stack top) stack address RHS. Define this as `lhs < rhs' if the
712
     target's stack grows downward in memory, or `lhs > rsh' if the
713
     stack grows upward.
714
 
715
`IN_SIGTRAMP (PC, NAME)'
716
     Define this to return non-zero if the given PC and/or NAME
717
     indicates that the current function is a `sigtramp'.
718
 
719
`SIGTRAMP_START (PC)'
720
`SIGTRAMP_END (PC)'
721
     Define these to be the start and end address of the `sigtramp' for
722
     the given PC.  On machines where the address is just a compile time
723
     constant, the macro expansion will typically just ignore the
724
     supplied PC.
725
 
726
`IN_SOLIB_CALL_TRAMPOLINE (PC, NAME)'
727
     Define this to evaluate to nonzero if the program is stopped in the
728
     trampoline that connects to a shared library.
729
 
730
`IN_SOLIB_RETURN_TRAMPOLINE (PC, NAME)'
731
     Define this to evaluate to nonzero if the program is stopped in the
732
     trampoline that returns from a shared library.
733
 
734
`IN_SOLIB_DYNSYM_RESOLVE_CODE (PC)'
735
     Define this to evaluate to nonzero if the program is stopped in the
736
     dynamic linker.
737
 
738
`SKIP_SOLIB_RESOLVER (PC)'
739
     Define this to evaluate to the (nonzero) address at which execution
740
     should continue to get past the dynamic linker's symbol resolution
741
     function.  A zero value indicates that it is not important or
742
     necessary to set a breakpoint to get through the dynamic linker
743
     and that single stepping will suffice.
744
 
745
`IS_TRAPPED_INTERNALVAR (NAME)'
746
     This is an ugly hook to allow the specification of special actions
747
     that should occur as a side-effect of setting the value of a
748
     variable internal to GDB.  Currently only used by the h8500.  Note
749
     that this could be either a host or target conditional.
750
 
751
`NEED_TEXT_START_END'
752
     Define this if GDB should determine the start and end addresses of
753
     the text section.  (Seems dubious.)
754
 
755
`NO_HIF_SUPPORT'
756
     (Specific to the a29k.)
757
 
758
`POINTER_TO_ADDRESS (TYPE, BUF)'
759
     Assume that BUF holds a pointer of type TYPE, in the appropriate
760
     format for the current architecture.  Return the byte address the
761
     pointer refers to.  *Note Pointers Are Not Always Addresses:
762
     Target Architecture Definition.
763
 
764
`REGISTER_CONVERTIBLE (REG)'
765
     Return non-zero if REG uses different raw and virtual formats.
766
     *Note Using Different Register and Memory Data Representations:
767
     Target Architecture Definition.
768
 
769
`REGISTER_RAW_SIZE (REG)'
770
     Return the raw size of REG.  *Note Using Different Register and
771
     Memory Data Representations: Target Architecture Definition.
772
 
773
`REGISTER_VIRTUAL_SIZE (REG)'
774
     Return the virtual size of REG.  *Note Using Different Register
775
     and Memory Data Representations: Target Architecture Definition.
776
 
777
`REGISTER_VIRTUAL_TYPE (REG)'
778
     Return the virtual type of REG.  *Note Using Different Register
779
     and Memory Data Representations: Target Architecture Definition.
780
 
781
`REGISTER_CONVERT_TO_VIRTUAL(REG, TYPE, FROM, TO)'
782
     Convert the value of register REG from its raw form to its virtual
783
     form.  *Note Using Different Register and Memory Data
784
     Representations: Target Architecture Definition.
785
 
786
`REGISTER_CONVERT_TO_RAW(TYPE, REG, FROM, TO)'
787
     Convert the value of register REG from its virtual form to its raw
788
     form.  *Note Using Different Register and Memory Data
789
     Representations: Target Architecture Definition.
790
 
791
`RETURN_VALUE_ON_STACK(TYPE)'
792
     Return non-zero if values of type TYPE are returned on the stack,
793
     using the "struct convention" (i.e., the caller provides a pointer
794
     to a buffer in which the callee should store the return value).
795
     This controls how the `finish' command finds a function's return
796
     value, and whether an inferior function call reserves space on the
797
     stack for the return value.
798
 
799
     The full logic GDB uses here is kind of odd.
800
 
801
        * If the type being returned by value is not a structure,
802
          union, or array, and `RETURN_VALUE_ON_STACK' returns zero,
803
          then GDB concludes the value is not returned using the struct
804
          convention.
805
 
806
        * Otherwise, GDB calls `USE_STRUCT_CONVENTION' (see below).  If
807
          that returns non-zero, GDB assumes the struct convention is
808
          in use.
809
 
810
     In other words, to indicate that a given type is returned by value
811
     using the struct convention, that type must be either a struct,
812
     union, array, or something `RETURN_VALUE_ON_STACK' likes, _and_
813
     something that `USE_STRUCT_CONVENTION' likes.
814
 
815
     Note that, in C and C++, arrays are never returned by value.  In
816
     those languages, these predicates will always see a pointer type,
817
     never an array type.  All the references above to arrays being
818
     returned by value apply only to other languages.
819
 
820
`SOFTWARE_SINGLE_STEP_P()'
821
     Define this as 1 if the target does not have a hardware single-step
822
     mechanism.  The macro `SOFTWARE_SINGLE_STEP' must also be defined.
823
 
824
`SOFTWARE_SINGLE_STEP(SIGNAL, INSERT_BREAPOINTS_P)'
825
     A function that inserts or removes (depending on
826
     INSERT_BREAPOINTS_P) breakpoints at each possible destinations of
827
     the next instruction. See `sparc-tdep.c' and `rs6000-tdep.c' for
828
     examples.
829
 
830
`SOFUN_ADDRESS_MAYBE_MISSING'
831
     Somebody clever observed that, the more actual addresses you have
832
     in the debug information, the more time the linker has to spend
833
     relocating them.  So whenever there's some other way the debugger
834
     could find the address it needs, you should omit it from the debug
835
     info, to make linking faster.
836
 
837
     `SOFUN_ADDRESS_MAYBE_MISSING' indicates that a particular set of
838
     hacks of this sort are in use, affecting `N_SO' and `N_FUN'
839
     entries in stabs-format debugging information.  `N_SO' stabs mark
840
     the beginning and ending addresses of compilation units in the text
841
     segment.  `N_FUN' stabs mark the starts and ends of functions.
842
 
843
     `SOFUN_ADDRESS_MAYBE_MISSING' means two things:
844
 
845
        * `N_FUN' stabs have an address of zero.  Instead, you should
846
          find the addresses where the function starts by taking the
847
          function name from the stab, and then looking that up in the
848
          minsyms (the linker/assembler symbol table).  In other words,
849
          the stab has the name, and the linker/assembler symbol table
850
          is the only place that carries the address.
851
 
852
        * `N_SO' stabs have an address of zero, too.  You just look at
853
          the `N_FUN' stabs that appear before and after the `N_SO'
854
          stab, and guess the starting and ending addresses of the
855
          compilation unit from them.
856
 
857
`PCC_SOL_BROKEN'
858
     (Used only in the Convex target.)
859
 
860
`PC_IN_CALL_DUMMY'
861
     See `inferior.h'.
862
 
863
`PC_LOAD_SEGMENT'
864
     If defined, print information about the load segment for the
865
     program counter.  (Defined only for the RS/6000.)
866
 
867
`PC_REGNUM'
868
     If the program counter is kept in a register, then define this
869
     macro to be the number (greater than or equal to zero) of that
870
     register.
871
 
872
     This should only need to be defined if `TARGET_READ_PC' and
873
     `TARGET_WRITE_PC' are not defined.
874
 
875
`NPC_REGNUM'
876
     The number of the "next program counter" register, if defined.
877
 
878
`NNPC_REGNUM'
879
     The number of the "next next program counter" register, if defined.
880
     Currently, this is only defined for the Motorola 88K.
881
 
882
`PARM_BOUNDARY'
883
     If non-zero, round arguments to a boundary of this many bits before
884
     pushing them on the stack.
885
 
886
`PRINT_REGISTER_HOOK (REGNO)'
887
     If defined, this must be a function that prints the contents of the
888
     given register to standard output.
889
 
890
`PRINT_TYPELESS_INTEGER'
891
     This is an obscure substitute for `print_longest' that seems to
892
     have been defined for the Convex target.
893
 
894
`PROCESS_LINENUMBER_HOOK'
895
     A hook defined for XCOFF reading.
896
 
897
`PROLOGUE_FIRSTLINE_OVERLAP'
898
     (Only used in unsupported Convex configuration.)
899
 
900
`PS_REGNUM'
901
     If defined, this is the number of the processor status register.
902
     (This definition is only used in generic code when parsing "$ps".)
903
 
904
`POP_FRAME'
905
     Used in `call_function_by_hand' to remove an artificial stack
906
     frame and in `return_command' to remove a real stack frame.
907
 
908
`PUSH_ARGUMENTS (NARGS, ARGS, SP, STRUCT_RETURN, STRUCT_ADDR)'
909
     Define this to push arguments onto the stack for inferior function
910
     call.  Returns the updated stack pointer value.
911
 
912
`PUSH_DUMMY_FRAME'
913
     Used in `call_function_by_hand' to create an artificial stack
914
     frame.
915
 
916
`REGISTER_BYTES'
917
     The total amount of space needed to store GDB's copy of the
918
     machine's register state.
919
 
920
`REGISTER_NAME(I)'
921
     Return the name of register I as a string.  May return `NULL' or
922
     `NUL' to indicate that register I is not valid.
923
 
924
`REGISTER_NAMES'
925
     Deprecated in favor of `REGISTER_NAME'.
926
 
927
`REG_STRUCT_HAS_ADDR (GCC_P, TYPE)'
928
     Define this to return 1 if the given type will be passed by pointer
929
     rather than directly.
930
 
931
`SAVE_DUMMY_FRAME_TOS (SP)'
932
     Used in `call_function_by_hand' to notify the target dependent code
933
     of the top-of-stack value that will be passed to the the inferior
934
     code.  This is the value of the `SP' after both the dummy frame
935
     and space for parameters/results have been allocated on the stack.
936
 
937
`SDB_REG_TO_REGNUM'
938
     Define this to convert sdb register numbers into GDB regnums.  If
939
     not defined, no conversion will be done.
940
 
941
`SHIFT_INST_REGS'
942
     (Only used for m88k targets.)
943
 
944
`SKIP_PERMANENT_BREAKPOINT'
945
     Advance the inferior's PC past a permanent breakpoint.  GDB
946
     normally steps over a breakpoint by removing it, stepping one
947
     instruction, and re-inserting the breakpoint.  However, permanent
948
     breakpoints are hardwired into the inferior, and can't be removed,
949
     so this strategy doesn't work.  Calling
950
     `SKIP_PERMANENT_BREAKPOINT' adjusts the processor's state so that
951
     execution will resume just after the breakpoint.  This macro does
952
     the right thing even when the breakpoint is in the delay slot of a
953
     branch or jump.
954
 
955
`SKIP_PROLOGUE (PC)'
956
     A C expression that returns the address of the "real" code beyond
957
     the function entry prologue found at PC.
958
 
959
`SKIP_PROLOGUE_FRAMELESS_P'
960
     A C expression that should behave similarly, but that can stop as
961
     soon as the function is known to have a frame.  If not defined,
962
     `SKIP_PROLOGUE' will be used instead.
963
 
964
`SKIP_TRAMPOLINE_CODE (PC)'
965
     If the target machine has trampoline code that sits between
966
     callers and the functions being called, then define this macro to
967
     return a new PC that is at the start of the real function.
968
 
969
`SP_REGNUM'
970
     If the stack-pointer is kept in a register, then define this macro
971
     to be the number (greater than or equal to zero) of that register.
972
 
973
     This should only need to be defined if `TARGET_WRITE_SP' and
974
     `TARGET_WRITE_SP' are not defined.
975
 
976
`STAB_REG_TO_REGNUM'
977
     Define this to convert stab register numbers (as gotten from `r'
978
     declarations) into GDB regnums.  If not defined, no conversion
979
     will be done.
980
 
981
`STACK_ALIGN (ADDR)'
982
     Define this to adjust the address to the alignment required for the
983
     processor's stack.
984
 
985
`STEP_SKIPS_DELAY (ADDR)'
986
     Define this to return true if the address is of an instruction
987
     with a delay slot.  If a breakpoint has been placed in the
988
     instruction's delay slot, GDB will single-step over that
989
     instruction before resuming normally.  Currently only defined for
990
     the Mips.
991
 
992
`STORE_RETURN_VALUE (TYPE, VALBUF)'
993
     A C expression that stores a function return value of type TYPE,
994
     where VALBUF is the address of the value to be stored.
995
 
996
`SUN_FIXED_LBRAC_BUG'
997
     (Used only for Sun-3 and Sun-4 targets.)
998
 
999
`SYMBOL_RELOADING_DEFAULT'
1000
     The default value of the "symbol-reloading" variable.  (Never
1001
     defined in current sources.)
1002
 
1003
`TARGET_BYTE_ORDER_DEFAULT'
1004
     The ordering of bytes in the target.  This must be either
1005
     `BIG_ENDIAN' or `LITTLE_ENDIAN'.  This macro replaces
1006
     `TARGET_BYTE_ORDER' which is deprecated.
1007
 
1008
`TARGET_BYTE_ORDER_SELECTABLE_P'
1009
     Non-zero if the target has both `BIG_ENDIAN' and `LITTLE_ENDIAN'
1010
     variants.  This macro replaces `TARGET_BYTE_ORDER_SELECTABLE'
1011
     which is deprecated.
1012
 
1013
`TARGET_CHAR_BIT'
1014
     Number of bits in a char; defaults to 8.
1015
 
1016
`TARGET_COMPLEX_BIT'
1017
     Number of bits in a complex number; defaults to `2 *
1018
     TARGET_FLOAT_BIT'.
1019
 
1020
     At present this macro is not used.
1021
 
1022
`TARGET_DOUBLE_BIT'
1023
     Number of bits in a double float; defaults to `8 *
1024
     TARGET_CHAR_BIT'.
1025
 
1026
`TARGET_DOUBLE_COMPLEX_BIT'
1027
     Number of bits in a double complex; defaults to `2 *
1028
     TARGET_DOUBLE_BIT'.
1029
 
1030
     At present this macro is not used.
1031
 
1032
`TARGET_FLOAT_BIT'
1033
     Number of bits in a float; defaults to `4 * TARGET_CHAR_BIT'.
1034
 
1035
`TARGET_INT_BIT'
1036
     Number of bits in an integer; defaults to `4 * TARGET_CHAR_BIT'.
1037
 
1038
`TARGET_LONG_BIT'
1039
     Number of bits in a long integer; defaults to `4 *
1040
     TARGET_CHAR_BIT'.
1041
 
1042
`TARGET_LONG_DOUBLE_BIT'
1043
     Number of bits in a long double float; defaults to `2 *
1044
     TARGET_DOUBLE_BIT'.
1045
 
1046
`TARGET_LONG_LONG_BIT'
1047
     Number of bits in a long long integer; defaults to `2 *
1048
     TARGET_LONG_BIT'.
1049
 
1050
`TARGET_PTR_BIT'
1051
     Number of bits in a pointer; defaults to `TARGET_INT_BIT'.
1052
 
1053
`TARGET_SHORT_BIT'
1054
     Number of bits in a short integer; defaults to `2 *
1055
     TARGET_CHAR_BIT'.
1056
 
1057
`TARGET_READ_PC'
1058
`TARGET_WRITE_PC (VAL, PID)'
1059
`TARGET_READ_SP'
1060
`TARGET_WRITE_SP'
1061
`TARGET_READ_FP'
1062
`TARGET_WRITE_FP'
1063
     These change the behavior of `read_pc', `write_pc', `read_sp',
1064
     `write_sp', `read_fp' and `write_fp'.  For most targets, these may
1065
     be left undefined.  GDB will call the read and write register
1066
     functions with the relevant `_REGNUM' argument.
1067
 
1068
     These macros are useful when a target keeps one of these registers
1069
     in a hard to get at place; for example, part in a segment register
1070
     and part in an ordinary register.
1071
 
1072
`TARGET_VIRTUAL_FRAME_POINTER(PC, REGP, OFFSETP)'
1073
     Returns a `(register, offset)' pair representing the virtual frame
1074
     pointer in use at the code address PC.  If virtual frame pointers
1075
     are not used, a default definition simply returns `FP_REGNUM',
1076
     with an offset of zero.
1077
 
1078
`TARGET_HAS_HARDWARE_WATCHPOINTS'
1079
     If non-zero, the target has support for hardware-assisted
1080
     watchpoints.  *Note watchpoints: Algorithms, for more details and
1081
     other related macros.
1082
 
1083
`USE_STRUCT_CONVENTION (GCC_P, TYPE)'
1084
     If defined, this must be an expression that is nonzero if a value
1085
     of the given TYPE being returned from a function must have space
1086
     allocated for it on the stack.  GCC_P is true if the function
1087
     being considered is known to have been compiled by GCC; this is
1088
     helpful for systems where GCC is known to use different calling
1089
     convention than other compilers.
1090
 
1091
`VARIABLES_INSIDE_BLOCK (DESC, GCC_P)'
1092
     For dbx-style debugging information, if the compiler puts variable
1093
     declarations inside LBRAC/RBRAC blocks, this should be defined to
1094
     be nonzero.  DESC is the value of `n_desc' from the `N_RBRAC'
1095
     symbol, and GCC_P is true if GDB has noticed the presence of
1096
     either the `GCC_COMPILED_SYMBOL' or the `GCC2_COMPILED_SYMBOL'.
1097
     By default, this is 0.
1098
 
1099
`OS9K_VARIABLES_INSIDE_BLOCK (DESC, GCC_P)'
1100
     Similarly, for OS/9000.  Defaults to 1.
1101
 
1102
   Motorola M68K target conditionals.
1103
 
1104
`BPT_VECTOR'
1105
     Define this to be the 4-bit location of the breakpoint trap
1106
     vector.  If not defined, it will default to `0xf'.
1107
 
1108
`REMOTE_BPT_VECTOR'
1109
     Defaults to `1'.
1110
 
1111
Adding a New Target
1112
===================
1113
 
1114
   The following files add a target to GDB:
1115
 
1116
`gdb/config/ARCH/TTT.mt'
1117
     Contains a Makefile fragment specific to this target.  Specifies
1118
     what object files are needed for target TTT, by defining
1119
     `TDEPFILES=...' and `TDEPLIBS=...'.  Also specifies the header
1120
     file which describes TTT, by defining `TM_FILE= tm-TTT.h'.
1121
 
1122
     You can also define `TM_CFLAGS', `TM_CLIBS', `TM_CDEPS', but these
1123
     are now deprecated, replaced by autoconf, and may go away in
1124
     future versions of GDB.
1125
 
1126
`gdb/TTT-tdep.c'
1127
     Contains any miscellaneous code required for this target machine.
1128
     On some machines it doesn't exist at all.  Sometimes the macros in
1129
     `tm-TTT.h' become very complicated, so they are implemented as
1130
     functions here instead, and the macro is simply defined to call the
1131
     function.  This is vastly preferable, since it is easier to
1132
     understand and debug.
1133
 
1134
`gdb/ARCH-tdep.c'
1135
`gdb/ARCH-tdep.h'
1136
     This often exists to describe the basic layout of the target
1137
     machine's processor chip (registers, stack, etc.).  If used, it is
1138
     included by `TTT-tdep.h'.  It can be shared among many targets
1139
     that use the same processor.
1140
 
1141
`gdb/config/ARCH/tm-TTT.h'
1142
     (`tm.h' is a link to this file, created by `configure').  Contains
1143
     macro definitions about the target machine's registers, stack frame
1144
     format and instructions.
1145
 
1146
     New targets do not need this file and should not create it.
1147
 
1148
`gdb/config/ARCH/tm-ARCH.h'
1149
     This often exists to describe the basic layout of the target
1150
     machine's processor chip (registers, stack, etc.).  If used, it is
1151
     included by `tm-TTT.h'.  It can be shared among many targets that
1152
     use the same processor.
1153
 
1154
     New targets do not need this file and should not create it.
1155
 
1156
   If you are adding a new operating system for an existing CPU chip,
1157
add a `config/tm-OS.h' file that describes the operating system
1158
facilities that are unusual (extra symbol table info; the breakpoint
1159
instruction needed; etc.).  Then write a `ARCH/tm-OS.h' that just
1160
`#include's `tm-ARCH.h' and `config/tm-OS.h'.
1161
 
1162
   ---------- Footnotes ----------
1163
 
1164
   (1) Some D10V instructions are actually pairs of 16-bit
1165
sub-instructions.  However, since you can't jump into the middle of
1166
such a pair, code addresses can only refer to full 32 bit instructions,
1167
which is what matters in this explanation.
1168
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.