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

Subversion Repositories or1k

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

Go to most recent revision | 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: Symbol Handling,  Next: Language Support,  Prev: User Interface,  Up: Top
29
 
30
Symbol Handling
31
***************
32
 
33
   Symbols are a key part of GDB's operation.  Symbols include
34
variables, functions, and types.
35
 
36
Symbol Reading
37
==============
38
 
39
   GDB reads symbols from "symbol files".  The usual symbol file is the
40
file containing the program which GDB is debugging.  GDB can be
41
directed to use a different file for symbols (with the `symbol-file'
42
command), and it can also read more symbols via the `add-file' and
43
`load' commands, or while reading symbols from shared libraries.
44
 
45
   Symbol files are initially opened by code in `symfile.c' using the
46
BFD library (*note Support Libraries::).  BFD identifies the type of
47
the file by examining its header.  `find_sym_fns' then uses this
48
identification to locate a set of symbol-reading functions.
49
 
50
   Symbol-reading modules identify themselves to GDB by calling
51
`add_symtab_fns' during their module initialization.  The argument to
52
`add_symtab_fns' is a `struct sym_fns' which contains the name (or name
53
prefix) of the symbol format, the length of the prefix, and pointers to
54
four functions.  These functions are called at various times to process
55
symbol files whose identification matches the specified prefix.
56
 
57
   The functions supplied by each module are:
58
 
59
`XYZ_symfile_init(struct sym_fns *sf)'
60
     Called from `symbol_file_add' when we are about to read a new
61
     symbol file.  This function should clean up any internal state
62
     (possibly resulting from half-read previous files, for example)
63
     and prepare to read a new symbol file.  Note that the symbol file
64
     which we are reading might be a new "main" symbol file, or might
65
     be a secondary symbol file whose symbols are being added to the
66
     existing symbol table.
67
 
68
     The argument to `XYZ_symfile_init' is a newly allocated `struct
69
     sym_fns' whose `bfd' field contains the BFD for the new symbol
70
     file being read.  Its `private' field has been zeroed, and can be
71
     modified as desired.  Typically, a struct of private information
72
     will be `malloc''d, and a pointer to it will be placed in the
73
     `private' field.
74
 
75
     There is no result from `XYZ_symfile_init', but it can call
76
     `error' if it detects an unavoidable problem.
77
 
78
`XYZ_new_init()'
79
     Called from `symbol_file_add' when discarding existing symbols.
80
     This function needs only handle the symbol-reading module's
81
     internal state; the symbol table data structures visible to the
82
     rest of GDB will be discarded by `symbol_file_add'.  It has no
83
     arguments and no result.  It may be called after
84
     `XYZ_symfile_init', if a new symbol table is being read, or may be
85
     called alone if all symbols are simply being discarded.
86
 
87
`XYZ_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)'
88
     Called from `symbol_file_add' to actually read the symbols from a
89
     symbol-file into a set of psymtabs or symtabs.
90
 
91
     `sf' points to the `struct sym_fns' originally passed to
92
     `XYZ_sym_init' for possible initialization.  `addr' is the offset
93
     between the file's specified start address and its true address in
94
     memory.  `mainline' is 1 if this is the main symbol table being
95
     read, and 0 if a secondary symbol file (e.g. shared library or
96
     dynamically loaded file) is being read.
97
 
98
   In addition, if a symbol-reading module creates psymtabs when
99
XYZ_symfile_read is called, these psymtabs will contain a pointer to a
100
function `XYZ_psymtab_to_symtab', which can be called from any point in
101
the GDB symbol-handling code.
102
 
103
`XYZ_psymtab_to_symtab (struct partial_symtab *pst)'
104
     Called from `psymtab_to_symtab' (or the `PSYMTAB_TO_SYMTAB' macro)
105
     if the psymtab has not already been read in and had its
106
     `pst->symtab' pointer set.  The argument is the psymtab to be
107
     fleshed-out into a symtab.  Upon return, `pst->readin' should have
108
     been set to 1, and `pst->symtab' should contain a pointer to the
109
     new corresponding symtab, or zero if there were no symbols in that
110
     part of the symbol file.
111
 
112
Partial Symbol Tables
113
=====================
114
 
115
   GDB has three types of symbol tables:
116
 
117
   * Full symbol tables ("symtabs").  These contain the main
118
     information about symbols and addresses.
119
 
120
   * Partial symbol tables ("psymtabs").  These contain enough
121
     information to know when to read the corresponding part of the full
122
     symbol table.
123
 
124
   * Minimal symbol tables ("msymtabs").  These contain information
125
     gleaned from non-debugging symbols.
126
 
127
   This section describes partial symbol tables.
128
 
129
   A psymtab is constructed by doing a very quick pass over an
130
executable file's debugging information.  Small amounts of information
131
are extracted--enough to identify which parts of the symbol table will
132
need to be re-read and fully digested later, when the user needs the
133
information.  The speed of this pass causes GDB to start up very
134
quickly.  Later, as the detailed rereading occurs, it occurs in small
135
pieces, at various times, and the delay therefrom is mostly invisible to
136
the user.
137
 
138
   The symbols that show up in a file's psymtab should be, roughly,
139
those visible to the debugger's user when the program is not running
140
code from that file.  These include external symbols and types, static
141
symbols and types, and `enum' values declared at file scope.
142
 
143
   The psymtab also contains the range of instruction addresses that the
144
full symbol table would represent.
145
 
146
   The idea is that there are only two ways for the user (or much of the
147
code in the debugger) to reference a symbol:
148
 
149
   * By its address (e.g. execution stops at some address which is
150
     inside a function in this file).  The address will be noticed to
151
     be in the range of this psymtab, and the full symtab will be read
152
     in.  `find_pc_function', `find_pc_line', and other `find_pc_...'
153
     functions handle this.
154
 
155
   * By its name (e.g. the user asks to print a variable, or set a
156
     breakpoint on a function).  Global names and file-scope names will
157
     be found in the psymtab, which will cause the symtab to be pulled
158
     in.  Local names will have to be qualified by a global name, or a
159
     file-scope name, in which case we will have already read in the
160
     symtab as we evaluated the qualifier.  Or, a local symbol can be
161
     referenced when we are "in" a local scope, in which case the first
162
     case applies.  `lookup_symbol' does most of the work here.
163
 
164
   The only reason that psymtabs exist is to cause a symtab to be read
165
in at the right moment.  Any symbol that can be elided from a psymtab,
166
while still causing that to happen, should not appear in it.  Since
167
psymtabs don't have the idea of scope, you can't put local symbols in
168
them anyway.  Psymtabs don't have the idea of the type of a symbol,
169
either, so types need not appear, unless they will be referenced by
170
name.
171
 
172
   It is a bug for GDB to behave one way when only a psymtab has been
173
read, and another way if the corresponding symtab has been read in.
174
Such bugs are typically caused by a psymtab that does not contain all
175
the visible symbols, or which has the wrong instruction address ranges.
176
 
177
   The psymtab for a particular section of a symbol file (objfile)
178
could be thrown away after the symtab has been read in.  The symtab
179
should always be searched before the psymtab, so the psymtab will never
180
be used (in a bug-free environment).  Currently, psymtabs are allocated
181
on an obstack, and all the psymbols themselves are allocated in a pair
182
of large arrays on an obstack, so there is little to be gained by
183
trying to free them unless you want to do a lot more work.
184
 
185
Types
186
=====
187
 
188
Fundamental Types (e.g., `FT_VOID', `FT_BOOLEAN').
189
--------------------------------------------------
190
 
191
   These are the fundamental types that GDB uses internally.
192
Fundamental types from the various debugging formats (stabs, ELF, etc)
193
are mapped into one of these.  They are basically a union of all
194
fundamental types that GDB knows about for all the languages that GDB
195
knows about.
196
 
197
Type Codes (e.g., `TYPE_CODE_PTR', `TYPE_CODE_ARRAY').
198
------------------------------------------------------
199
 
200
   Each time GDB builds an internal type, it marks it with one of these
201
types.  The type may be a fundamental type, such as `TYPE_CODE_INT', or
202
a derived type, such as `TYPE_CODE_PTR' which is a pointer to another
203
type.  Typically, several `FT_*' types map to one `TYPE_CODE_*' type,
204
and are distinguished by other members of the type struct, such as
205
whether the type is signed or unsigned, and how many bits it uses.
206
 
207
Builtin Types (e.g., `builtin_type_void', `builtin_type_char').
208
---------------------------------------------------------------
209
 
210
   These are instances of type structs that roughly correspond to
211
fundamental types and are created as global types for GDB to use for
212
various ugly historical reasons.  We eventually want to eliminate
213
these.  Note for example that `builtin_type_int' initialized in
214
`gdbtypes.c' is basically the same as a `TYPE_CODE_INT' type that is
215
initialized in `c-lang.c' for an `FT_INTEGER' fundamental type.  The
216
difference is that the `builtin_type' is not associated with any
217
particular objfile, and only one instance exists, while `c-lang.c'
218
builds as many `TYPE_CODE_INT' types as needed, with each one
219
associated with some particular objfile.
220
 
221
Object File Formats
222
===================
223
 
224
a.out
225
-----
226
 
227
   The `a.out' format is the original file format for Unix.  It
228
consists of three sections: `text', `data', and `bss', which are for
229
program code, initialized data, and uninitialized data, respectively.
230
 
231
   The `a.out' format is so simple that it doesn't have any reserved
232
place for debugging information.  (Hey, the original Unix hackers used
233
`adb', which is a machine-language debugger!)  The only debugging
234
format for `a.out' is stabs, which is encoded as a set of normal
235
symbols with distinctive attributes.
236
 
237
   The basic `a.out' reader is in `dbxread.c'.
238
 
239
COFF
240
----
241
 
242
   The COFF format was introduced with System V Release 3 (SVR3) Unix.
243
COFF files may have multiple sections, each prefixed by a header.  The
244
number of sections is limited.
245
 
246
   The COFF specification includes support for debugging.  Although this
247
was a step forward, the debugging information was woefully limited.  For
248
instance, it was not possible to represent code that came from an
249
included file.
250
 
251
   The COFF reader is in `coffread.c'.
252
 
253
ECOFF
254
-----
255
 
256
   ECOFF is an extended COFF originally introduced for Mips and Alpha
257
workstations.
258
 
259
   The basic ECOFF reader is in `mipsread.c'.
260
 
261
XCOFF
262
-----
263
 
264
   The IBM RS/6000 running AIX uses an object file format called XCOFF.
265
The COFF sections, symbols, and line numbers are used, but debugging
266
symbols are `dbx'-style stabs whose strings are located in the `.debug'
267
section (rather than the string table).  For more information, see
268
*Note Top: (stabs)Top.
269
 
270
   The shared library scheme has a clean interface for figuring out what
271
shared libraries are in use, but the catch is that everything which
272
refers to addresses (symbol tables and breakpoints at least) needs to be
273
relocated for both shared libraries and the main executable.  At least
274
using the standard mechanism this can only be done once the program has
275
been run (or the core file has been read).
276
 
277
PE
278
--
279
 
280
   Windows 95 and NT use the PE ("Portable Executable") format for their
281
executables.  PE is basically COFF with additional headers.
282
 
283
   While BFD includes special PE support, GDB needs only the basic COFF
284
reader.
285
 
286
ELF
287
---
288
 
289
   The ELF format came with System V Release 4 (SVR4) Unix.  ELF is
290
similar to COFF in being organized into a number of sections, but it
291
removes many of COFF's limitations.
292
 
293
   The basic ELF reader is in `elfread.c'.
294
 
295
SOM
296
---
297
 
298
   SOM is HP's object file and debug format (not to be confused with
299
IBM's SOM, which is a cross-language ABI).
300
 
301
   The SOM reader is in `hpread.c'.
302
 
303
Other File Formats
304
------------------
305
 
306
   Other file formats that have been supported by GDB include Netware
307
Loadable Modules (`nlmread.c').
308
 
309
Debugging File Formats
310
======================
311
 
312
   This section describes characteristics of debugging information that
313
are independent of the object file format.
314
 
315
stabs
316
-----
317
 
318
   `stabs' started out as special symbols within the `a.out' format.
319
Since then, it has been encapsulated into other file formats, such as
320
COFF and ELF.
321
 
322
   While `dbxread.c' does some of the basic stab processing, including
323
for encapsulated versions, `stabsread.c' does the real work.
324
 
325
COFF
326
----
327
 
328
   The basic COFF definition includes debugging information.  The level
329
of support is minimal and non-extensible, and is not often used.
330
 
331
Mips debug (Third Eye)
332
----------------------
333
 
334
   ECOFF includes a definition of a special debug format.
335
 
336
   The file `mdebugread.c' implements reading for this format.
337
 
338
DWARF 1
339
-------
340
 
341
   DWARF 1 is a debugging format that was originally designed to be
342
used with ELF in SVR4 systems.
343
 
344
   The DWARF 1 reader is in `dwarfread.c'.
345
 
346
DWARF 2
347
-------
348
 
349
   DWARF 2 is an improved but incompatible version of DWARF 1.
350
 
351
   The DWARF 2 reader is in `dwarf2read.c'.
352
 
353
SOM
354
---
355
 
356
   Like COFF, the SOM definition includes debugging information.
357
 
358
Adding a New Symbol Reader to GDB
359
=================================
360
 
361
   If you are using an existing object file format (`a.out', COFF, ELF,
362
etc), there is probably little to be done.
363
 
364
   If you need to add a new object file format, you must first add it to
365
BFD.  This is beyond the scope of this document.
366
 
367
   You must then arrange for the BFD code to provide access to the
368
debugging symbols.  Generally GDB will have to call swapping routines
369
from BFD and a few other BFD internal routines to locate the debugging
370
information.  As much as possible, GDB should not depend on the BFD
371
internal data structures.
372
 
373
   For some targets (e.g., COFF), there is a special transfer vector
374
used to call swapping routines, since the external data structures on
375
various platforms have different sizes and layouts.  Specialized
376
routines that will only ever be implemented by one object file format
377
may be called directly.  This interface should be described in a file
378
`bfd/libXYZ.h', which is included by GDB.
379
 
380

381
File: gdbint.info,  Node: Language Support,  Next: Host Definition,  Prev: Symbol Handling,  Up: Top
382
 
383
Language Support
384
****************
385
 
386
   GDB's language support is mainly driven by the symbol reader,
387
although it is possible for the user to set the source language
388
manually.
389
 
390
   GDB chooses the source language by looking at the extension of the
391
file recorded in the debug info; `.c' means C, `.f' means Fortran, etc.
392
It may also use a special-purpose language identifier if the debug
393
format supports it, like with DWARF.
394
 
395
Adding a Source Language to GDB
396
===============================
397
 
398
   To add other languages to GDB's expression parser, follow the
399
following steps:
400
 
401
_Create the expression parser._
402
     This should reside in a file `LANG-exp.y'.  Routines for building
403
     parsed expressions into a `union exp_element' list are in
404
     `parse.c'.
405
 
406
     Since we can't depend upon everyone having Bison, and YACC produces
407
     parsers that define a bunch of global names, the following lines
408
     *must* be included at the top of the YACC parser, to prevent the
409
     various parsers from defining the same global names:
410
 
411
          #define yyparse         LANG_parse
412
          #define yylex           LANG_lex
413
          #define yyerror         LANG_error
414
          #define yylval          LANG_lval
415
          #define yychar          LANG_char
416
          #define yydebug         LANG_debug
417
          #define yypact          LANG_pact
418
          #define yyr1            LANG_r1
419
          #define yyr2            LANG_r2
420
          #define yydef           LANG_def
421
          #define yychk           LANG_chk
422
          #define yypgo           LANG_pgo
423
          #define yyact           LANG_act
424
          #define yyexca          LANG_exca
425
          #define yyerrflag       LANG_errflag
426
          #define yynerrs         LANG_nerrs
427
 
428
     At the bottom of your parser, define a `struct language_defn' and
429
     initialize it with the right values for your language.  Define an
430
     `initialize_LANG' routine and have it call
431
     `add_language(LANG_language_defn)' to tell the rest of GDB that
432
     your language exists.  You'll need some other supporting variables
433
     and functions, which will be used via pointers from your
434
     `LANG_language_defn'.  See the declaration of `struct
435
     language_defn' in `language.h', and the other `*-exp.y' files, for
436
     more information.
437
 
438
_Add any evaluation routines, if necessary_
439
     If you need new opcodes (that represent the operations of the
440
     language), add them to the enumerated type in `expression.h'.  Add
441
     support code for these operations in the `evaluate_subexp' function
442
     defined in the file `eval.c'.  Add cases for new opcodes in two
443
     functions from `parse.c': `prefixify_subexp' and
444
     `length_of_subexp'.  These compute the number of `exp_element's
445
     that a given operation takes up.
446
 
447
_Update some existing code_
448
     Add an enumerated identifier for your language to the enumerated
449
     type `enum language' in `defs.h'.
450
 
451
     Update the routines in `language.c' so your language is included.
452
     These routines include type predicates and such, which (in some
453
     cases) are language dependent.  If your language does not appear
454
     in the switch statement, an error is reported.
455
 
456
     Also included in `language.c' is the code that updates the variable
457
     `current_language', and the routines that translate the
458
     `language_LANG' enumerated identifier into a printable string.
459
 
460
     Update the function `_initialize_language' to include your
461
     language.  This function picks the default language upon startup,
462
     so is dependent upon which languages that GDB is built for.
463
 
464
     Update `allocate_symtab' in `symfile.c' and/or symbol-reading code
465
     so that the language of each symtab (source file) is set properly.
466
     This is used to determine the language to use at each stack frame
467
     level.  Currently, the language is set based upon the extension of
468
     the source file.  If the language can be better inferred from the
469
     symbol information, please set the language of the symtab in the
470
     symbol-reading code.
471
 
472
     Add helper code to `print_subexp' (in `expprint.c') to handle any
473
     new expression opcodes you have added to `expression.h'.  Also,
474
     add the printed representations of your operators to
475
     `op_print_tab'.
476
 
477
_Add a place of call_
478
     Add a call to `LANG_parse()' and `LANG_error' in `parse_exp_1'
479
     (defined in `parse.c').
480
 
481
_Use macros to trim code_
482
     The user has the option of building GDB for some or all of the
483
     languages.  If the user decides to build GDB for the language
484
     LANG, then every file dependent on `language.h' will have the
485
     macro `_LANG_LANG' defined in it.  Use `#ifdef's to leave out
486
     large routines that the user won't need if he or she is not using
487
     your language.
488
 
489
     Note that you do not need to do this in your YACC parser, since if
490
     GDB is not build for LANG, then `LANG-exp.tab.o' (the compiled
491
     form of your parser) is not linked into GDB at all.
492
 
493
     See the file `configure.in' for how GDB is configured for
494
     different languages.
495
 
496
_Edit `Makefile.in'_
497
     Add dependencies in `Makefile.in'.  Make sure you update the macro
498
     variables such as `HFILES' and `OBJS', otherwise your code may not
499
     get linked in, or, worse yet, it may not get `tar'red into the
500
     distribution!
501
 
502

503
File: gdbint.info,  Node: Host Definition,  Next: Target Architecture Definition,  Prev: Language Support,  Up: Top
504
 
505
Host Definition
506
***************
507
 
508
   _Maintainer's note: In theory, new targets no longer need to use the
509
host framework described below.  Instead it should be possible to
510
handle everything using autoconf.  Patches eliminating this framework
511
welcome._
512
 
513
   With the advent of Autoconf, it's rarely necessary to have host
514
definition machinery anymore.
515
 
516
Adding a New Host
517
=================
518
 
519
   Most of GDB's host configuration support happens via Autoconf.  New
520
host-specific definitions should be rarely needed.  GDB still uses the
521
host-specific definitions and files listed below, but these mostly
522
exist for historical reasons, and should eventually disappear.
523
 
524
   Several files control GDB's configuration for host systems:
525
 
526
`gdb/config/ARCH/XYZ.mh'
527
     Specifies Makefile fragments needed when hosting on machine XYZ.
528
     In particular, this lists the required machine-dependent object
529
     files, by defining `XDEPFILES=...'.  Also specifies the header file
530
     which describes host XYZ, by defining `XM_FILE= xm-XYZ.h'.  You
531
     can also define `CC', `SYSV_DEFINE', `XM_CFLAGS', `XM_ADD_FILES',
532
     `XM_CLIBS', `XM_CDEPS', etc.; see `Makefile.in'.
533
 
534
`gdb/config/ARCH/xm-XYZ.h'
535
     (`xm.h' is a link to this file, created by `configure').  Contains
536
     C macro definitions describing the host system environment, such
537
     as byte order, host C compiler and library.
538
 
539
`gdb/XYZ-xdep.c'
540
     Contains any miscellaneous C code required for this machine as a
541
     host.  On most machines it doesn't exist at all.  If it does
542
     exist, put `XYZ-xdep.o' into the `XDEPFILES' line in
543
     `gdb/config/ARCH/XYZ.mh'.
544
 
545
Generic Host Support Files
546
--------------------------
547
 
548
   There are some "generic" versions of routines that can be used by
549
various systems.  These can be customized in various ways by macros
550
defined in your `xm-XYZ.h' file.  If these routines work for the XYZ
551
host, you can just include the generic file's name (with `.o', not
552
`.c') in `XDEPFILES'.
553
 
554
   Otherwise, if your machine needs custom support routines, you will
555
need to write routines that perform the same functions as the generic
556
file.  Put them into `XYZ-xdep.c', and put `XYZ-xdep.o' into
557
`XDEPFILES'.
558
 
559
`ser-unix.c'
560
     This contains serial line support for Unix systems.  This is always
561
     included, via the makefile variable `SER_HARDWIRE'; override this
562
     variable in the `.mh' file to avoid it.
563
 
564
`ser-go32.c'
565
     This contains serial line support for 32-bit programs running
566
     under DOS, using the DJGPP (a.k.a. GO32) execution environment.
567
 
568
`ser-tcp.c'
569
     This contains generic TCP support using sockets.
570
 
571
Host Conditionals
572
=================
573
 
574
   When GDB is configured and compiled, various macros are defined or
575
left undefined, to control compilation based on the attributes of the
576
host system.  These macros and their meanings (or if the meaning is not
577
documented here, then one of the source files where they are used is
578
indicated) are:
579
 
580
`GDBINIT_FILENAME'
581
     The default name of GDB's initialization file (normally
582
     `.gdbinit').
583
 
584
`MEM_FNS_DECLARED'
585
     Your host config file defines this if it includes declarations of
586
     `memcpy' and `memset'.  Define this to avoid conflicts between the
587
     native include files and the declarations in `defs.h'.
588
 
589
`NO_STD_REGS'
590
     This macro is deprecated.
591
 
592
`NO_SYS_FILE'
593
     Define this if your system does not have a `'.
594
 
595
`SIGWINCH_HANDLER'
596
     If your host defines `SIGWINCH', you can define this to be the name
597
     of a function to be called if `SIGWINCH' is received.
598
 
599
`SIGWINCH_HANDLER_BODY'
600
     Define this to expand into code that will define the function
601
     named by the expansion of `SIGWINCH_HANDLER'.
602
 
603
`ALIGN_STACK_ON_STARTUP'
604
     Define this if your system is of a sort that will crash in
605
     `tgetent' if the stack happens not to be longword-aligned when
606
     `main' is called.  This is a rare situation, but is known to occur
607
     on several different types of systems.
608
 
609
`CRLF_SOURCE_FILES'
610
     Define this if host files use `\r\n' rather than `\n' as a line
611
     terminator.  This will cause source file listings to omit `\r'
612
     characters when printing and it will allow `\r\n' line endings of
613
     files which are "sourced" by gdb.  It must be possible to open
614
     files in binary mode using `O_BINARY' or, for fopen, `"rb"'.
615
 
616
`DEFAULT_PROMPT'
617
     The default value of the prompt string (normally `"(gdb) "').
618
 
619
`DEV_TTY'
620
     The name of the generic TTY device, defaults to `"/dev/tty"'.
621
 
622
`FCLOSE_PROVIDED'
623
     Define this if the system declares `fclose' in the headers included
624
     in `defs.h'.  This isn't needed unless your compiler is unusually
625
     anal.
626
 
627
`FOPEN_RB'
628
     Define this if binary files are opened the same way as text files.
629
 
630
`GETENV_PROVIDED'
631
     Define this if the system declares `getenv' in its headers included
632
     in `defs.h'.  This isn't needed unless your compiler is unusually
633
     anal.
634
 
635
`HAVE_MMAP'
636
     In some cases, use the system call `mmap' for reading symbol
637
     tables.  For some machines this allows for sharing and quick
638
     updates.
639
 
640
`HAVE_SIGSETMASK'
641
     Define this if the host system has job control, but does not define
642
     `sigsetmask'.  Currently, this is only true of the RS/6000.
643
 
644
`HAVE_TERMIO'
645
     Define this if the host system has `termio.h'.
646
 
647
`HOST_BYTE_ORDER'
648
     The ordering of bytes in the host.  This must be defined to be
649
     either `BIG_ENDIAN' or `LITTLE_ENDIAN'.
650
 
651
`INT_MAX'
652
`INT_MIN'
653
`LONG_MAX'
654
`UINT_MAX'
655
`ULONG_MAX'
656
     Values for host-side constants.
657
 
658
`ISATTY'
659
     Substitute for isatty, if not available.
660
 
661
`LONGEST'
662
     This is the longest integer type available on the host.  If not
663
     defined, it will default to `long long' or `long', depending on
664
     `CC_HAS_LONG_LONG'.
665
 
666
`CC_HAS_LONG_LONG'
667
     Define this if the host C compiler supports `long long'.  This is
668
     set by the `configure' script.
669
 
670
`PRINTF_HAS_LONG_LONG'
671
     Define this if the host can handle printing of long long integers
672
     via the printf format conversion specifier `ll'.  This is set by
673
     the `configure' script.
674
 
675
`HAVE_LONG_DOUBLE'
676
     Define this if the host C compiler supports `long double'.  This is
677
     set by the `configure' script.
678
 
679
`PRINTF_HAS_LONG_DOUBLE'
680
     Define this if the host can handle printing of long double
681
     float-point numbers via the printf format conversion specifier
682
     `Lg'.  This is set by the `configure' script.
683
 
684
`SCANF_HAS_LONG_DOUBLE'
685
     Define this if the host can handle the parsing of long double
686
     float-point numbers via the scanf format conversion specifier
687
     `Lg'.  This is set by the `configure' script.
688
 
689
`LSEEK_NOT_LINEAR'
690
     Define this if `lseek (n)' does not necessarily move to byte number
691
     `n' in the file.  This is only used when reading source files.  It
692
     is normally faster to define `CRLF_SOURCE_FILES' when possible.
693
 
694
`L_SET'
695
     This macro is used as the argument to `lseek' (or, most commonly,
696
     `bfd_seek').  FIXME, should be replaced by SEEK_SET instead, which
697
     is the POSIX equivalent.
698
 
699
`MALLOC_INCOMPATIBLE'
700
     Define this if the system's prototype for `malloc' differs from the
701
     ANSI definition.
702
 
703
`MMAP_BASE_ADDRESS'
704
     When using HAVE_MMAP, the first mapping should go at this address.
705
 
706
`MMAP_INCREMENT'
707
     when using HAVE_MMAP, this is the increment between mappings.
708
 
709
`NEED_POSIX_SETPGID'
710
     Define this to use the POSIX version of `setpgid' to determine
711
     whether job control is available.
712
 
713
`NORETURN'
714
     If defined, this should be one or more tokens, such as `volatile',
715
     that can be used in both the declaration and definition of
716
     functions to indicate that they never return.  The default is
717
     already set correctly if compiling with GCC.  This will almost
718
     never need to be defined.
719
 
720
`ATTR_NORETURN'
721
     If defined, this should be one or more tokens, such as
722
     `__attribute__ ((noreturn))', that can be used in the declarations
723
     of functions to indicate that they never return.  The default is
724
     already set correctly if compiling with GCC.  This will almost
725
     never need to be defined.
726
 
727
`USE_GENERIC_DUMMY_FRAMES'
728
     Define this to 1 if the target is using the generic inferior
729
     function call code.  See `blockframe.c' for more information.
730
 
731
`USE_MMALLOC'
732
     GDB will use the `mmalloc' library for memory allocation for
733
     symbol reading if this symbol is defined.  Be careful defining it
734
     since there are systems on which `mmalloc' does not work for some
735
     reason.  One example is the DECstation, where its RPC library can't
736
     cope with our redefinition of `malloc' to call `mmalloc'.  When
737
     defining `USE_MMALLOC', you will also have to set `MMALLOC' in the
738
     Makefile, to point to the `mmalloc' library.  This define is set
739
     when you configure with `--with-mmalloc'.
740
 
741
`NO_MMCHECK'
742
     Define this if you are using `mmalloc', but don't want the overhead
743
     of checking the heap with `mmcheck'.  Note that on some systems,
744
     the C runtime makes calls to `malloc' prior to calling `main', and
745
     if `free' is ever called with these pointers after calling
746
     `mmcheck' to enable checking, a memory corruption abort is certain
747
     to occur.  These systems can still use `mmalloc', but must define
748
     `NO_MMCHECK'.
749
 
750
`MMCHECK_FORCE'
751
     Define this to 1 if the C runtime allocates memory prior to
752
     `mmcheck' being called, but that memory is never freed so we don't
753
     have to worry about it triggering a memory corruption abort.  The
754
     default is 0, which means that `mmcheck' will only install the heap
755
     checking functions if there has not yet been any memory allocation
756
     calls, and if it fails to install the functions, GDB will issue a
757
     warning.  This is currently defined if you configure using
758
     `--with-mmalloc'.
759
 
760
`NO_SIGINTERRUPT'
761
     Define this to indicate that `siginterrupt' is not available.
762
 
763
`R_OK'
764
     Define if this is not in a system header file (typically,
765
     `unistd.h').
766
 
767
`SEEK_CUR'
768
`SEEK_SET'
769
     Define these to appropriate value for the system `lseek', if not
770
     already defined.
771
 
772
`STOP_SIGNAL'
773
     This is the signal for stopping GDB.  Defaults to `SIGTSTP'.
774
     (Only redefined for the Convex.)
775
 
776
`USE_O_NOCTTY'
777
     Define this if the interior's tty should be opened with the
778
     `O_NOCTTY' flag.  (FIXME: This should be a native-only flag, but
779
     `inflow.c' is always linked in.)
780
 
781
`USG'
782
     Means that System V (prior to SVR4) include files are in use.
783
     (FIXME: This symbol is abused in `infrun.c', `regex.c',
784
     `remote-nindy.c', and `utils.c' for other things, at the moment.)
785
 
786
`lint'
787
     Define this to help placate `lint' in some situations.
788
 
789
`volatile'
790
     Define this to override the defaults of `__volatile__' or `/**/'.
791
 

powered by: WebSVN 2.1.0

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