Home | History | Annotate | Download | only in info
      1 This is stabs.info, produced by makeinfo version 4.11 from
      2 /home/jingyu/projects/gcc/android-toolchainsrc/build/../gdb/gdb-7.1.x/gdb/doc/stabs.texinfo.
      3 
      4 INFO-DIR-SECTION Software development
      5 START-INFO-DIR-ENTRY
      6 * Stabs: (stabs).                 The "stabs" debugging information format.
      7 END-INFO-DIR-ENTRY
      8 
      9    Copyright (C) 1992, 1993, 1994, 1995, 1997, 1998, 2000, 2001, 2002,
     10 2003, 2004, 2005, 2006, 2007, 2009, 2010 Free Software Foundation, Inc.
     11 Contributed by Cygnus Support.  Written by Julia Menapace, Jim Kingdon,
     12 and David MacKenzie.
     13 
     14    Permission is granted to copy, distribute and/or modify this document
     15 under the terms of the GNU Free Documentation License, Version 1.1 or
     16 any later version published by the Free Software Foundation; with no
     17 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
     18 Texts.  A copy of the license is included in the section entitled "GNU
     19 Free Documentation License".
     20 
     21    This document describes the stabs debugging symbol tables.
     22 
     23    Copyright (C) 1992, 1993, 1994, 1995, 1997, 1998, 2000, 2001, 2002,
     24 2003, 2004, 2005, 2006, 2007, 2009, 2010 Free Software Foundation, Inc.
     25 Contributed by Cygnus Support.  Written by Julia Menapace, Jim Kingdon,
     26 and David MacKenzie.
     27 
     28    Permission is granted to copy, distribute and/or modify this document
     29 under the terms of the GNU Free Documentation License, Version 1.1 or
     30 any later version published by the Free Software Foundation; with no
     31 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
     32 Texts.  A copy of the license is included in the section entitled "GNU
     33 Free Documentation License".
     34 
     35 
     36 File: stabs.info,  Node: Top,  Next: Overview,  Up: (dir)
     37 
     38 The "stabs" representation of debugging information
     39 ***************************************************
     40 
     41 This document describes the stabs debugging format.
     42 
     43 * Menu:
     44 
     45 * Overview::			Overview of stabs
     46 * Program Structure::		Encoding of the structure of the program
     47 * Constants::			Constants
     48 * Variables::
     49 * Types::			Type definitions
     50 * Macro define and undefine::	Representation of #define and #undef
     51 * Symbol Tables::		Symbol information in symbol tables
     52 * Cplusplus::			Stabs specific to C++
     53 * Stab Types::			Symbol types in a.out files
     54 * Symbol Descriptors::		Table of symbol descriptors
     55 * Type Descriptors::		Table of type descriptors
     56 * Expanded Reference::		Reference information by stab type
     57 * Questions::			Questions and anomalies
     58 * Stab Sections::		In some object file formats, stabs are
     59                                 in sections.
     60 * Symbol Types Index::          Index of symbolic stab symbol type names.
     61 * GNU Free Documentation License::  The license for this documentation
     62 
     63 
     64 File: stabs.info,  Node: Overview,  Next: Program Structure,  Prev: Top,  Up: Top
     65 
     66 1 Overview of Stabs
     67 *******************
     68 
     69 "Stabs" refers to a format for information that describes a program to
     70 a debugger.  This format was apparently invented by Peter Kessler at
     71 the University of California at Berkeley, for the `pdx' Pascal
     72 debugger; the format has spread widely since then.
     73 
     74    This document is one of the few published sources of documentation on
     75 stabs.  It is believed to be comprehensive for stabs used by C.  The
     76 lists of symbol descriptors (*note Symbol Descriptors::) and type
     77 descriptors (*note Type Descriptors::) are believed to be completely
     78 comprehensive.  Stabs for COBOL-specific features and for variant
     79 records (used by Pascal and Modula-2) are poorly documented here.
     80 
     81    Other sources of information on stabs are `Dbx and Dbxtool
     82 Interfaces', 2nd edition, by Sun, 1988, and `AIX Version 3.2 Files
     83 Reference', Fourth Edition, September 1992, "dbx Stabstring Grammar" in
     84 the a.out section, page 2-31.  This document is believed to incorporate
     85 the information from those two sources except where it explicitly
     86 directs you to them for more information.
     87 
     88 * Menu:
     89 
     90 * Flow::			Overview of debugging information flow
     91 * Stabs Format::		Overview of stab format
     92 * String Field::		The string field
     93 * C Example::			A simple example in C source
     94 * Assembly Code::		The simple example at the assembly level
     95 
     96 
     97 File: stabs.info,  Node: Flow,  Next: Stabs Format,  Up: Overview
     98 
     99 1.1 Overview of Debugging Information Flow
    100 ==========================================
    101 
    102 The GNU C compiler compiles C source in a `.c' file into assembly
    103 language in a `.s' file, which the assembler translates into a `.o'
    104 file, which the linker combines with other `.o' files and libraries to
    105 produce an executable file.
    106 
    107    With the `-g' option, GCC puts in the `.s' file additional debugging
    108 information, which is slightly transformed by the assembler and linker,
    109 and carried through into the final executable.  This debugging
    110 information describes features of the source file like line numbers,
    111 the types and scopes of variables, and function names, parameters, and
    112 scopes.
    113 
    114    For some object file formats, the debugging information is
    115 encapsulated in assembler directives known collectively as "stab"
    116 (symbol table) directives, which are interspersed with the generated
    117 code.  Stabs are the native format for debugging information in the
    118 a.out and XCOFF object file formats.  The GNU tools can also emit stabs
    119 in the COFF and ECOFF object file formats.
    120 
    121    The assembler adds the information from stabs to the symbol
    122 information it places by default in the symbol table and the string
    123 table of the `.o' file it is building.  The linker consolidates the `.o'
    124 files into one executable file, with one symbol table and one string
    125 table.  Debuggers use the symbol and string tables in the executable as
    126 a source of debugging information about the program.
    127 
    128 
    129 File: stabs.info,  Node: Stabs Format,  Next: String Field,  Prev: Flow,  Up: Overview
    130 
    131 1.2 Overview of Stab Format
    132 ===========================
    133 
    134 There are three overall formats for stab assembler directives,
    135 differentiated by the first word of the stab.  The name of the directive
    136 describes which combination of four possible data fields follows.  It is
    137 either `.stabs' (string), `.stabn' (number), or `.stabd' (dot).  IBM's
    138 XCOFF assembler uses `.stabx' (and some other directives such as
    139 `.file' and `.bi') instead of `.stabs', `.stabn' or `.stabd'.
    140 
    141    The overall format of each class of stab is:
    142 
    143      .stabs "STRING",TYPE,OTHER,DESC,VALUE
    144      .stabn TYPE,OTHER,DESC,VALUE
    145      .stabd TYPE,OTHER,DESC
    146      .stabx "STRING",VALUE,TYPE,SDB-TYPE
    147 
    148    For `.stabn' and `.stabd', there is no STRING (the `n_strx' field is
    149 zero; see *note Symbol Tables::).  For `.stabd', the VALUE field is
    150 implicit and has the value of the current file location.  For `.stabx',
    151 the SDB-TYPE field is unused for stabs and can always be set to zero.
    152 The OTHER field is almost always unused and can be set to zero.
    153 
    154    The number in the TYPE field gives some basic information about
    155 which type of stab this is (or whether it _is_ a stab, as opposed to an
    156 ordinary symbol).  Each valid type number defines a different stab
    157 type; further, the stab type defines the exact interpretation of, and
    158 possible values for, any remaining STRING, DESC, or VALUE fields
    159 present in the stab.  *Note Stab Types::, for a list in numeric order
    160 of the valid TYPE field values for stab directives.
    161 
    162 
    163 File: stabs.info,  Node: String Field,  Next: C Example,  Prev: Stabs Format,  Up: Overview
    164 
    165 1.3 The String Field
    166 ====================
    167 
    168 For most stabs the string field holds the meat of the debugging
    169 information.  The flexible nature of this field is what makes stabs
    170 extensible.  For some stab types the string field contains only a name.
    171 For other stab types the contents can be a great deal more complex.
    172 
    173    The overall format of the string field for most stab types is:
    174 
    175      "NAME:SYMBOL-DESCRIPTOR TYPE-INFORMATION"
    176 
    177    NAME is the name of the symbol represented by the stab; it can
    178 contain a pair of colons (*note Nested Symbols::).  NAME can be
    179 omitted, which means the stab represents an unnamed object.  For
    180 example, `:t10=*2' defines type 10 as a pointer to type 2, but does not
    181 give the type a name.  Omitting the NAME field is supported by AIX dbx
    182 and GDB after about version 4.8, but not other debuggers.  GCC
    183 sometimes uses a single space as the name instead of omitting the name
    184 altogether; apparently that is supported by most debuggers.
    185 
    186    The SYMBOL-DESCRIPTOR following the `:' is an alphabetic character
    187 that tells more specifically what kind of symbol the stab represents.
    188 If the SYMBOL-DESCRIPTOR is omitted, but type information follows, then
    189 the stab represents a local variable.  For a list of symbol
    190 descriptors, see *note Symbol Descriptors::.  The `c' symbol descriptor
    191 is an exception in that it is not followed by type information.  *Note
    192 Constants::.
    193 
    194    TYPE-INFORMATION is either a TYPE-NUMBER, or `TYPE-NUMBER='.  A
    195 TYPE-NUMBER alone is a type reference, referring directly to a type
    196 that has already been defined.
    197 
    198    The `TYPE-NUMBER=' form is a type definition, where the number
    199 represents a new type which is about to be defined.  The type
    200 definition may refer to other types by number, and those type numbers
    201 may be followed by `=' and nested definitions.  Also, the Lucid
    202 compiler will repeat `TYPE-NUMBER=' more than once if it wants to
    203 define several type numbers at once.
    204 
    205    In a type definition, if the character that follows the equals sign
    206 is non-numeric then it is a TYPE-DESCRIPTOR, and tells what kind of
    207 type is about to be defined.  Any other values following the
    208 TYPE-DESCRIPTOR vary, depending on the TYPE-DESCRIPTOR.  *Note Type
    209 Descriptors::, for a list of TYPE-DESCRIPTOR values.  If a number
    210 follows the `=' then the number is a TYPE-REFERENCE.  For a full
    211 description of types, *note Types::.
    212 
    213    A TYPE-NUMBER is often a single number.  The GNU and Sun tools
    214 additionally permit a TYPE-NUMBER to be a pair
    215 (FILE-NUMBER,FILETYPE-NUMBER) (the parentheses appear in the string,
    216 and serve to distinguish the two cases).  The FILE-NUMBER is 0 for the
    217 base source file, 1 for the first included file, 2 for the next, and so
    218 on.  The FILETYPE-NUMBER is a number starting with 1 which is
    219 incremented for each new type defined in the file.  (Separating the
    220 file number and the type number permits the `N_BINCL' optimization to
    221 succeed more often; see *note Include Files::).
    222 
    223    There is an AIX extension for type attributes.  Following the `='
    224 are any number of type attributes.  Each one starts with `@' and ends
    225 with `;'.  Debuggers, including AIX's dbx and GDB 4.10, skip any type
    226 attributes they do not recognize.  GDB 4.9 and other versions of dbx
    227 may not do this.  Because of a conflict with C++ (*note Cplusplus::),
    228 new attributes should not be defined which begin with a digit, `(', or
    229 `-'; GDB may be unable to distinguish those from the C++ type
    230 descriptor `@'.  The attributes are:
    231 
    232 `aBOUNDARY'
    233      BOUNDARY is an integer specifying the alignment.  I assume it
    234      applies to all variables of this type.
    235 
    236 `pINTEGER'
    237      Pointer class (for checking).  Not sure what this means, or how
    238      INTEGER is interpreted.
    239 
    240 `P'
    241      Indicate this is a packed type, meaning that structure fields or
    242      array elements are placed more closely in memory, to save memory
    243      at the expense of speed.
    244 
    245 `sSIZE'
    246      Size in bits of a variable of this type.  This is fully supported
    247      by GDB 4.11 and later.
    248 
    249 `S'
    250      Indicate that this type is a string instead of an array of
    251      characters, or a bitstring instead of a set.  It doesn't change
    252      the layout of the data being represented, but does enable the
    253      debugger to know which type it is.
    254 
    255 `V'
    256      Indicate that this type is a vector instead of an array.  The only
    257      major difference between vectors and arrays is that vectors are
    258      passed by value instead of by reference (vector coprocessor
    259      extension).
    260 
    261 
    262    All of this can make the string field quite long.  All versions of
    263 GDB, and some versions of dbx, can handle arbitrarily long strings.
    264 But many versions of dbx (or assemblers or linkers, I'm not sure which)
    265 cretinously limit the strings to about 80 characters, so compilers which
    266 must work with such systems need to split the `.stabs' directive into
    267 several `.stabs' directives.  Each stab duplicates every field except
    268 the string field.  The string field of every stab except the last is
    269 marked as continued with a backslash at the end (in the assembly code
    270 this may be written as a double backslash, depending on the assembler).
    271 Removing the backslashes and concatenating the string fields of each
    272 stab produces the original, long string.  Just to be incompatible (or so
    273 they don't have to worry about what the assembler does with
    274 backslashes), AIX can use `?' instead of backslash.
    275 
    276 
    277 File: stabs.info,  Node: C Example,  Next: Assembly Code,  Prev: String Field,  Up: Overview
    278 
    279 1.4 A Simple Example in C Source
    280 ================================
    281 
    282 To get the flavor of how stabs describe source information for a C
    283 program, let's look at the simple program:
    284 
    285      main()
    286      {
    287              printf("Hello world");
    288      }
    289 
    290    When compiled with `-g', the program above yields the following `.s'
    291 file.  Line numbers have been added to make it easier to refer to parts
    292 of the `.s' file in the description of the stabs that follows.
    293 
    294 
    295 File: stabs.info,  Node: Assembly Code,  Prev: C Example,  Up: Overview
    296 
    297 1.5 The Simple Example at the Assembly Level
    298 ============================================
    299 
    300 This simple "hello world" example demonstrates several of the stab
    301 types used to describe C language source files.
    302 
    303      1  gcc2_compiled.:
    304      2  .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0
    305      3  .stabs "hello.c",100,0,0,Ltext0
    306      4  .text
    307      5  Ltext0:
    308      6  .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0
    309      7  .stabs "char:t2=r2;0;127;",128,0,0,0
    310      8  .stabs "long int:t3=r1;-2147483648;2147483647;",128,0,0,0
    311      9  .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
    312      10 .stabs "long unsigned int:t5=r1;0;-1;",128,0,0,0
    313      11 .stabs "short int:t6=r1;-32768;32767;",128,0,0,0
    314      12 .stabs "long long int:t7=r1;0;-1;",128,0,0,0
    315      13 .stabs "short unsigned int:t8=r1;0;65535;",128,0,0,0
    316      14 .stabs "long long unsigned int:t9=r1;0;-1;",128,0,0,0
    317      15 .stabs "signed char:t10=r1;-128;127;",128,0,0,0
    318      16 .stabs "unsigned char:t11=r1;0;255;",128,0,0,0
    319      17 .stabs "float:t12=r1;4;0;",128,0,0,0
    320      18 .stabs "double:t13=r1;8;0;",128,0,0,0
    321      19 .stabs "long double:t14=r1;8;0;",128,0,0,0
    322      20 .stabs "void:t15=15",128,0,0,0
    323      21      .align 4
    324      22 LC0:
    325      23      .ascii "Hello, world!\12\0"
    326      24      .align 4
    327      25      .global _main
    328      26      .proc 1
    329      27 _main:
    330      28 .stabn 68,0,4,LM1
    331      29 LM1:
    332      30      !#PROLOGUE# 0
    333      31      save %sp,-136,%sp
    334      32      !#PROLOGUE# 1
    335      33      call ___main,0
    336      34      nop
    337      35 .stabn 68,0,5,LM2
    338      36 LM2:
    339      37 LBB2:
    340      38      sethi %hi(LC0),%o1
    341      39      or %o1,%lo(LC0),%o0
    342      40      call _printf,0
    343      41      nop
    344      42 .stabn 68,0,6,LM3
    345      43 LM3:
    346      44 LBE2:
    347      45 .stabn 68,0,6,LM4
    348      46 LM4:
    349      47 L1:
    350      48      ret
    351      49      restore
    352      50 .stabs "main:F1",36,0,0,_main
    353      51 .stabn 192,0,0,LBB2
    354      52 .stabn 224,0,0,LBE2
    355 
    356 
    357 File: stabs.info,  Node: Program Structure,  Next: Constants,  Prev: Overview,  Up: Top
    358 
    359 2 Encoding the Structure of the Program
    360 ***************************************
    361 
    362 The elements of the program structure that stabs encode include the name
    363 of the main function, the names of the source and include files, the
    364 line numbers, procedure names and types, and the beginnings and ends of
    365 blocks of code.
    366 
    367 * Menu:
    368 
    369 * Main Program::		Indicate what the main program is
    370 * Source Files::		The path and name of the source file
    371 * Include Files::               Names of include files
    372 * Line Numbers::
    373 * Procedures::
    374 * Nested Procedures::
    375 * Block Structure::
    376 * Alternate Entry Points::      Entering procedures except at the beginning.
    377 
    378 
    379 File: stabs.info,  Node: Main Program,  Next: Source Files,  Up: Program Structure
    380 
    381 2.1 Main Program
    382 ================
    383 
    384 Most languages allow the main program to have any name.  The `N_MAIN'
    385 stab type tells the debugger the name that is used in this program.
    386 Only the string field is significant; it is the name of a function
    387 which is the main program.  Most C compilers do not use this stab (they
    388 expect the debugger to assume that the name is `main'), but some C
    389 compilers emit an `N_MAIN' stab for the `main' function.  I'm not sure
    390 how XCOFF handles this.
    391 
    392 
    393 File: stabs.info,  Node: Source Files,  Next: Include Files,  Prev: Main Program,  Up: Program Structure
    394 
    395 2.2 Paths and Names of the Source Files
    396 =======================================
    397 
    398 Before any other stabs occur, there must be a stab specifying the source
    399 file.  This information is contained in a symbol of stab type `N_SO';
    400 the string field contains the name of the file.  The value of the
    401 symbol is the start address of the portion of the text section
    402 corresponding to that file.
    403 
    404    Some compilers use the desc field to indicate the language of the
    405 source file.  Sun's compilers started this usage, and the first
    406 constants are derived from their documentation.  Languages added by
    407 gcc/gdb start at 0x32 to avoid conflict with languages Sun may add in
    408 the future.  A desc field with a value 0 indicates that no language has
    409 been specified via this mechanism.
    410 
    411 `N_SO_AS' (0x1)
    412      Assembly language
    413 
    414 `N_SO_C'  (0x2)
    415      K&R traditional C
    416 
    417 `N_SO_ANSI_C' (0x3)
    418      ANSI C
    419 
    420 `N_SO_CC'  (0x4)
    421      C++
    422 
    423 `N_SO_FORTRAN' (0x5)
    424      Fortran
    425 
    426 `N_SO_PASCAL' (0x6)
    427      Pascal
    428 
    429 `N_SO_FORTRAN90' (0x7)
    430      Fortran90
    431 
    432 `N_SO_OBJC' (0x32)
    433      Objective-C
    434 
    435 `N_SO_OBJCPLUS' (0x33)
    436      Objective-C++
    437 
    438    Some compilers (for example, GCC2 and SunOS4 `/bin/cc') also include
    439 the directory in which the source was compiled, in a second `N_SO'
    440 symbol preceding the one containing the file name.  This symbol can be
    441 distinguished by the fact that it ends in a slash.  Code from the
    442 `cfront' C++ compiler can have additional `N_SO' symbols for
    443 nonexistent source files after the `N_SO' for the real source file;
    444 these are believed to contain no useful information.
    445 
    446    For example:
    447 
    448      .stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0     # 100 is N_SO
    449      .stabs "hello.c",100,0,0,Ltext0
    450              .text
    451      Ltext0:
    452 
    453    Instead of `N_SO' symbols, XCOFF uses a `.file' assembler directive
    454 which assembles to a `C_FILE' symbol; explaining this in detail is
    455 outside the scope of this document.
    456 
    457    If it is useful to indicate the end of a source file, this is done
    458 with an `N_SO' symbol with an empty string for the name.  The value is
    459 the address of the end of the text section for the file.  For some
    460 systems, there is no indication of the end of a source file, and you
    461 just need to figure it ended when you see an `N_SO' for a different
    462 source file, or a symbol ending in `.o' (which at least some linkers
    463 insert to mark the start of a new `.o' file).
    464 
    465 
    466 File: stabs.info,  Node: Include Files,  Next: Line Numbers,  Prev: Source Files,  Up: Program Structure
    467 
    468 2.3 Names of Include Files
    469 ==========================
    470 
    471 There are several schemes for dealing with include files: the
    472 traditional `N_SOL' approach, Sun's `N_BINCL' approach, and the XCOFF
    473 `C_BINCL' approach (which despite the similar name has little in common
    474 with `N_BINCL').
    475 
    476    An `N_SOL' symbol specifies which include file subsequent symbols
    477 refer to.  The string field is the name of the file and the value is the
    478 text address corresponding to the end of the previous include file and
    479 the start of this one.  To specify the main source file again, use an
    480 `N_SOL' symbol with the name of the main source file.
    481 
    482    The `N_BINCL' approach works as follows.  An `N_BINCL' symbol
    483 specifies the start of an include file.  In an object file, only the
    484 string is significant; the linker puts data into some of the other
    485 fields.  The end of the include file is marked by an `N_EINCL' symbol
    486 (which has no string field).  In an object file, there is no
    487 significant data in the `N_EINCL' symbol.  `N_BINCL' and `N_EINCL' can
    488 be nested.
    489 
    490    If the linker detects that two source files have identical stabs
    491 between an `N_BINCL' and `N_EINCL' pair (as will generally be the case
    492 for a header file), then it only puts out the stabs once.  Each
    493 additional occurrence is replaced by an `N_EXCL' symbol.  I believe the
    494 GNU linker and the Sun (both SunOS4 and Solaris) linker are the only
    495 ones which supports this feature.
    496 
    497    A linker which supports this feature will set the value of a
    498 `N_BINCL' symbol to the total of all the characters in the stabs
    499 strings included in the header file, omitting any file numbers.  The
    500 value of an `N_EXCL' symbol is the same as the value of the `N_BINCL'
    501 symbol it replaces.  This information can be used to match up `N_EXCL'
    502 and `N_BINCL' symbols which have the same filename.  The `N_EINCL'
    503 value, and the values of the other and description fields for all
    504 three, appear to always be zero.
    505 
    506    For the start of an include file in XCOFF, use the `.bi' assembler
    507 directive, which generates a `C_BINCL' symbol.  A `.ei' directive,
    508 which generates a `C_EINCL' symbol, denotes the end of the include
    509 file.  Both directives are followed by the name of the source file in
    510 quotes, which becomes the string for the symbol.  The value of each
    511 symbol, produced automatically by the assembler and linker, is the
    512 offset into the executable of the beginning (inclusive, as you'd
    513 expect) or end (inclusive, as you would not expect) of the portion of
    514 the COFF line table that corresponds to this include file.  `C_BINCL'
    515 and `C_EINCL' do not nest.
    516 
    517 
    518 File: stabs.info,  Node: Line Numbers,  Next: Procedures,  Prev: Include Files,  Up: Program Structure
    519 
    520 2.4 Line Numbers
    521 ================
    522 
    523 An `N_SLINE' symbol represents the start of a source line.  The desc
    524 field contains the line number and the value contains the code address
    525 for the start of that source line.  On most machines the address is
    526 absolute; for stabs in sections (*note Stab Sections::), it is relative
    527 to the function in which the `N_SLINE' symbol occurs.
    528 
    529    GNU documents `N_DSLINE' and `N_BSLINE' symbols for line numbers in
    530 the data or bss segments, respectively.  They are identical to
    531 `N_SLINE' but are relocated differently by the linker.  They were
    532 intended to be used to describe the source location of a variable
    533 declaration, but I believe that GCC2 actually puts the line number in
    534 the desc field of the stab for the variable itself.  GDB has been
    535 ignoring these symbols (unless they contain a string field) since at
    536 least GDB 3.5.
    537 
    538    For single source lines that generate discontiguous code, such as
    539 flow of control statements, there may be more than one line number
    540 entry for the same source line.  In this case there is a line number
    541 entry at the start of each code range, each with the same line number.
    542 
    543    XCOFF does not use stabs for line numbers.  Instead, it uses COFF
    544 line numbers (which are outside the scope of this document).  Standard
    545 COFF line numbers cannot deal with include files, but in XCOFF this is
    546 fixed with the `C_BINCL' method of marking include files (*note Include
    547 Files::).
    548 
    549 
    550 File: stabs.info,  Node: Procedures,  Next: Nested Procedures,  Prev: Line Numbers,  Up: Program Structure
    551 
    552 2.5 Procedures
    553 ==============
    554 
    555 All of the following stabs normally use the `N_FUN' symbol type.
    556 However, Sun's `acc' compiler on SunOS4 uses `N_GSYM' and `N_STSYM',
    557 which means that the value of the stab for the function is useless and
    558 the debugger must get the address of the function from the non-stab
    559 symbols instead.  On systems where non-stab symbols have leading
    560 underscores, the stabs will lack underscores and the debugger needs to
    561 know about the leading underscore to match up the stab and the non-stab
    562 symbol.  BSD Fortran is said to use `N_FNAME' with the same
    563 restriction; the value of the symbol is not useful (I'm not sure it
    564 really does use this, because GDB doesn't handle this and no one has
    565 complained).
    566 
    567    A function is represented by an `F' symbol descriptor for a global
    568 (extern) function, and `f' for a static (local) function.  For a.out,
    569 the value of the symbol is the address of the start of the function; it
    570 is already relocated.  For stabs in ELF, the SunPRO compiler version
    571 2.0.1 and GCC put out an address which gets relocated by the linker.
    572 In a future release SunPRO is planning to put out zero, in which case
    573 the address can be found from the ELF (non-stab) symbol.  Because
    574 looking things up in the ELF symbols would probably be slow, I'm not
    575 sure how to find which symbol of that name is the right one, and this
    576 doesn't provide any way to deal with nested functions, it would
    577 probably be better to make the value of the stab an address relative to
    578 the start of the file, or just absolute.  See *note ELF Linker
    579 Relocation:: for more information on linker relocation of stabs in ELF
    580 files.  For XCOFF, the stab uses the `C_FUN' storage class and the
    581 value of the stab is meaningless; the address of the function can be
    582 found from the csect symbol (XTY_LD/XMC_PR).
    583 
    584    The type information of the stab represents the return type of the
    585 function; thus `foo:f5' means that foo is a function returning type 5.
    586 There is no need to try to get the line number of the start of the
    587 function from the stab for the function; it is in the next `N_SLINE'
    588 symbol.
    589 
    590    Some compilers (such as Sun's Solaris compiler) support an extension
    591 for specifying the types of the arguments.  I suspect this extension is
    592 not used for old (non-prototyped) function definitions in C.  If the
    593 extension is in use, the type information of the stab for the function
    594 is followed by type information for each argument, with each argument
    595 preceded by `;'.  An argument type of 0 means that additional arguments
    596 are being passed, whose types and number may vary (`...' in ANSI C).
    597 GDB has tolerated this extension (parsed the syntax, if not necessarily
    598 used the information) since at least version 4.8; I don't know whether
    599 all versions of dbx tolerate it.  The argument types given here are not
    600 redundant with the symbols for the formal parameters (*note
    601 Parameters::); they are the types of the arguments as they are passed,
    602 before any conversions might take place.  For example, if a C function
    603 which is declared without a prototype takes a `float' argument, the
    604 value is passed as a `double' but then converted to a `float'.
    605 Debuggers need to use the types given in the arguments when printing
    606 values, but when calling the function they need to use the types given
    607 in the symbol defining the function.
    608 
    609    If the return type and types of arguments of a function which is
    610 defined in another source file are specified (i.e., a function
    611 prototype in ANSI C), traditionally compilers emit no stab; the only
    612 way for the debugger to find the information is if the source file
    613 where the function is defined was also compiled with debugging symbols.
    614 As an extension the Solaris compiler uses symbol descriptor `P'
    615 followed by the return type of the function, followed by the arguments,
    616 each preceded by `;', as in a stab with symbol descriptor `f' or `F'.
    617 This use of symbol descriptor `P' can be distinguished from its use for
    618 register parameters (*note Register Parameters::) by the fact that it
    619 has symbol type `N_FUN'.
    620 
    621    The AIX documentation also defines symbol descriptor `J' as an
    622 internal function.  I assume this means a function nested within another
    623 function.  It also says symbol descriptor `m' is a module in Modula-2
    624 or extended Pascal.
    625 
    626    Procedures (functions which do not return values) are represented as
    627 functions returning the `void' type in C.  I don't see why this couldn't
    628 be used for all languages (inventing a `void' type for this purpose if
    629 necessary), but the AIX documentation defines `I', `P', and `Q' for
    630 internal, global, and static procedures, respectively.  These symbol
    631 descriptors are unusual in that they are not followed by type
    632 information.
    633 
    634    The following example shows a stab for a function `main' which
    635 returns type number `1'.  The `_main' specified for the value is a
    636 reference to an assembler label which is used to fill in the start
    637 address of the function.
    638 
    639      .stabs "main:F1",36,0,0,_main      # 36 is N_FUN
    640 
    641    The stab representing a procedure is located immediately following
    642 the code of the procedure.  This stab is in turn directly followed by a
    643 group of other stabs describing elements of the procedure.  These other
    644 stabs describe the procedure's parameters, its block local variables,
    645 and its block structure.
    646 
    647    If functions can appear in different sections, then the debugger may
    648 not be able to find the end of a function.  Recent versions of GCC will
    649 mark the end of a function with an `N_FUN' symbol with an empty string
    650 for the name.  The value is the address of the end of the current
    651 function.  Without such a symbol, there is no indication of the address
    652 of the end of a function, and you must assume that it ended at the
    653 starting address of the next function or at the end of the text section
    654 for the program.
    655 
    656 
    657 File: stabs.info,  Node: Nested Procedures,  Next: Block Structure,  Prev: Procedures,  Up: Program Structure
    658 
    659 2.6 Nested Procedures
    660 =====================
    661 
    662 For any of the symbol descriptors representing procedures, after the
    663 symbol descriptor and the type information is optionally a scope
    664 specifier.  This consists of a comma, the name of the procedure, another
    665 comma, and the name of the enclosing procedure.  The first name is local
    666 to the scope specified, and seems to be redundant with the name of the
    667 symbol (before the `:').  This feature is used by GCC, and presumably
    668 Pascal, Modula-2, etc., compilers, for nested functions.
    669 
    670    If procedures are nested more than one level deep, only the
    671 immediately containing scope is specified.  For example, this code:
    672 
    673      int
    674      foo (int x)
    675      {
    676        int bar (int y)
    677          {
    678            int baz (int z)
    679              {
    680                return x + y + z;
    681              }
    682            return baz (x + 2 * y);
    683          }
    684        return x + bar (3 * x);
    685      }
    686 
    687 produces the stabs:
    688 
    689      .stabs "baz:f1,baz,bar",36,0,0,_baz.15         # 36 is N_FUN
    690      .stabs "bar:f1,bar,foo",36,0,0,_bar.12
    691      .stabs "foo:F1",36,0,0,_foo
    692 
    693 
    694 File: stabs.info,  Node: Block Structure,  Next: Alternate Entry Points,  Prev: Nested Procedures,  Up: Program Structure
    695 
    696 2.7 Block Structure
    697 ===================
    698 
    699 The program's block structure is represented by the `N_LBRAC' (left
    700 brace) and the `N_RBRAC' (right brace) stab types.  The variables
    701 defined inside a block precede the `N_LBRAC' symbol for most compilers,
    702 including GCC.  Other compilers, such as the Convex, Acorn RISC
    703 machine, and Sun `acc' compilers, put the variables after the `N_LBRAC'
    704 symbol.  The values of the `N_LBRAC' and `N_RBRAC' symbols are the
    705 start and end addresses of the code of the block, respectively.  For
    706 most machines, they are relative to the starting address of this source
    707 file.  For the Gould NP1, they are absolute.  For stabs in sections
    708 (*note Stab Sections::), they are relative to the function in which
    709 they occur.
    710 
    711    The `N_LBRAC' and `N_RBRAC' stabs that describe the block scope of a
    712 procedure are located after the `N_FUN' stab that represents the
    713 procedure itself.
    714 
    715    Sun documents the desc field of `N_LBRAC' and `N_RBRAC' symbols as
    716 containing the nesting level of the block.  However, dbx seems to not
    717 care, and GCC always sets desc to zero.
    718 
    719    For XCOFF, block scope is indicated with `C_BLOCK' symbols.  If the
    720 name of the symbol is `.bb', then it is the beginning of the block; if
    721 the name of the symbol is `.be'; it is the end of the block.
    722 
    723 
    724 File: stabs.info,  Node: Alternate Entry Points,  Prev: Block Structure,  Up: Program Structure
    725 
    726 2.8 Alternate Entry Points
    727 ==========================
    728 
    729 Some languages, like Fortran, have the ability to enter procedures at
    730 some place other than the beginning.  One can declare an alternate entry
    731 point.  The `N_ENTRY' stab is for this; however, the Sun FORTRAN
    732 compiler doesn't use it.  According to AIX documentation, only the name
    733 of a `C_ENTRY' stab is significant; the address of the alternate entry
    734 point comes from the corresponding external symbol.  A previous
    735 revision of this document said that the value of an `N_ENTRY' stab was
    736 the address of the alternate entry point, but I don't know the source
    737 for that information.
    738 
    739 
    740 File: stabs.info,  Node: Constants,  Next: Variables,  Prev: Program Structure,  Up: Top
    741 
    742 3 Constants
    743 ***********
    744 
    745 The `c' symbol descriptor indicates that this stab represents a
    746 constant.  This symbol descriptor is an exception to the general rule
    747 that symbol descriptors are followed by type information.  Instead, it
    748 is followed by `=' and one of the following:
    749 
    750 `b VALUE'
    751      Boolean constant.  VALUE is a numeric value; I assume it is 0 for
    752      false or 1 for true.
    753 
    754 `c VALUE'
    755      Character constant.  VALUE is the numeric value of the constant.
    756 
    757 `e TYPE-INFORMATION , VALUE'
    758      Constant whose value can be represented as integral.
    759      TYPE-INFORMATION is the type of the constant, as it would appear
    760      after a symbol descriptor (*note String Field::).  VALUE is the
    761      numeric value of the constant.  GDB 4.9 does not actually get the
    762      right value if VALUE does not fit in a host `int', but it does not
    763      do anything violent, and future debuggers could be extended to
    764      accept integers of any size (whether unsigned or not).  This
    765      constant type is usually documented as being only for enumeration
    766      constants, but GDB has never imposed that restriction; I don't
    767      know about other debuggers.
    768 
    769 `i VALUE'
    770      Integer constant.  VALUE is the numeric value.  The type is some
    771      sort of generic integer type (for GDB, a host `int'); to specify
    772      the type explicitly, use `e' instead.
    773 
    774 `r VALUE'
    775      Real constant.  VALUE is the real value, which can be `INF'
    776      (optionally preceded by a sign) for infinity, `QNAN' for a quiet
    777      NaN (not-a-number), or `SNAN' for a signalling NaN.  If it is a
    778      normal number the format is that accepted by the C library function
    779      `atof'.
    780 
    781 `s STRING'
    782      String constant.  STRING is a string enclosed in either `'' (in
    783      which case `'' characters within the string are represented as
    784      `\'' or `"' (in which case `"' characters within the string are
    785      represented as `\"').
    786 
    787 `S TYPE-INFORMATION , ELEMENTS , BITS , PATTERN'
    788      Set constant.  TYPE-INFORMATION is the type of the constant, as it
    789      would appear after a symbol descriptor (*note String Field::).
    790      ELEMENTS is the number of elements in the set (does this means how
    791      many bits of PATTERN are actually used, which would be redundant
    792      with the type, or perhaps the number of bits set in PATTERN?  I
    793      don't get it), BITS is the number of bits in the constant (meaning
    794      it specifies the length of PATTERN, I think), and PATTERN is a
    795      hexadecimal representation of the set.  AIX documentation refers
    796      to a limit of 32 bytes, but I see no reason why this limit should
    797      exist.  This form could probably be used for arbitrary constants,
    798      not just sets; the only catch is that PATTERN should be understood
    799      to be target, not host, byte order and format.
    800 
    801    The boolean, character, string, and set constants are not supported
    802 by GDB 4.9, but it ignores them.  GDB 4.8 and earlier gave an error
    803 message and refused to read symbols from the file containing the
    804 constants.
    805 
    806    The above information is followed by `;'.
    807 
    808 
    809 File: stabs.info,  Node: Variables,  Next: Types,  Prev: Constants,  Up: Top
    810 
    811 4 Variables
    812 ***********
    813 
    814 Different types of stabs describe the various ways that variables can be
    815 allocated: on the stack, globally, in registers, in common blocks,
    816 statically, or as arguments to a function.
    817 
    818 * Menu:
    819 
    820 * Stack Variables::		Variables allocated on the stack.
    821 * Global Variables::		Variables used by more than one source file.
    822 * Register Variables::		Variables in registers.
    823 * Common Blocks::		Variables statically allocated together.
    824 * Statics::			Variables local to one source file.
    825 * Based Variables::		Fortran pointer based variables.
    826 * Parameters::			Variables for arguments to functions.
    827 
    828 
    829 File: stabs.info,  Node: Stack Variables,  Next: Global Variables,  Up: Variables
    830 
    831 4.1 Automatic Variables Allocated on the Stack
    832 ==============================================
    833 
    834 If a variable's scope is local to a function and its lifetime is only as
    835 long as that function executes (C calls such variables "automatic"), it
    836 can be allocated in a register (*note Register Variables::) or on the
    837 stack.
    838 
    839    Each variable allocated on the stack has a stab with the symbol
    840 descriptor omitted.  Since type information should begin with a digit,
    841 `-', or `(', only those characters precluded from being used for symbol
    842 descriptors.  However, the Acorn RISC machine (ARM) is said to get this
    843 wrong: it puts out a mere type definition here, without the preceding
    844 `TYPE-NUMBER='.  This is a bad idea; there is no guarantee that type
    845 descriptors are distinct from symbol descriptors.  Stabs for stack
    846 variables use the `N_LSYM' stab type, or `C_LSYM' for XCOFF.
    847 
    848    The value of the stab is the offset of the variable within the local
    849 variables.  On most machines this is an offset from the frame pointer
    850 and is negative.  The location of the stab specifies which block it is
    851 defined in; see *note Block Structure::.
    852 
    853    For example, the following C code:
    854 
    855      int
    856      main ()
    857      {
    858        int x;
    859      }
    860 
    861    produces the following stabs:
    862 
    863      .stabs "main:F1",36,0,0,_main   # 36 is N_FUN
    864      .stabs "x:1",128,0,0,-12        # 128 is N_LSYM
    865      .stabn 192,0,0,LBB2             # 192 is N_LBRAC
    866      .stabn 224,0,0,LBE2             # 224 is N_RBRAC
    867 
    868    See *note Procedures:: for more information on the `N_FUN' stab, and
    869 *note Block Structure:: for more information on the `N_LBRAC' and
    870 `N_RBRAC' stabs.
    871 
    872 
    873 File: stabs.info,  Node: Global Variables,  Next: Register Variables,  Prev: Stack Variables,  Up: Variables
    874 
    875 4.2 Global Variables
    876 ====================
    877 
    878 A variable whose scope is not specific to just one source file is
    879 represented by the `G' symbol descriptor.  These stabs use the `N_GSYM'
    880 stab type (C_GSYM for XCOFF).  The type information for the stab (*note
    881 String Field::) gives the type of the variable.
    882 
    883    For example, the following source code:
    884 
    885      char g_foo = 'c';
    886 
    887 yields the following assembly code:
    888 
    889      .stabs "g_foo:G2",32,0,0,0     # 32 is N_GSYM
    890           .global _g_foo
    891           .data
    892      _g_foo:
    893           .byte 99
    894 
    895    The address of the variable represented by the `N_GSYM' is not
    896 contained in the `N_GSYM' stab.  The debugger gets this information
    897 from the external symbol for the global variable.  In the example above,
    898 the `.global _g_foo' and `_g_foo:' lines tell the assembler to produce
    899 an external symbol.
    900 
    901    Some compilers, like GCC, output `N_GSYM' stabs only once, where the
    902 variable is defined.  Other compilers, like SunOS4 /bin/cc, output a
    903 `N_GSYM' stab for each compilation unit which references the variable.
    904 
    905 
    906 File: stabs.info,  Node: Register Variables,  Next: Common Blocks,  Prev: Global Variables,  Up: Variables
    907 
    908 4.3 Register Variables
    909 ======================
    910 
    911 Register variables have their own stab type, `N_RSYM' (`C_RSYM' for
    912 XCOFF), and their own symbol descriptor, `r'.  The stab's value is the
    913 number of the register where the variable data will be stored.
    914 
    915    AIX defines a separate symbol descriptor `d' for floating point
    916 registers.  This seems unnecessary; why not just just give floating
    917 point registers different register numbers?  I have not verified whether
    918 the compiler actually uses `d'.
    919 
    920    If the register is explicitly allocated to a global variable, but not
    921 initialized, as in:
    922 
    923      register int g_bar asm ("%g5");
    924 
    925 then the stab may be emitted at the end of the object file, with the
    926 other bss symbols.
    927 
    928 
    929 File: stabs.info,  Node: Common Blocks,  Next: Statics,  Prev: Register Variables,  Up: Variables
    930 
    931 4.4 Common Blocks
    932 =================
    933 
    934 A common block is a statically allocated section of memory which can be
    935 referred to by several source files.  It may contain several variables.
    936 I believe Fortran is the only language with this feature.
    937 
    938    A `N_BCOMM' stab begins a common block and an `N_ECOMM' stab ends
    939 it.  The only field that is significant in these two stabs is the
    940 string, which names a normal (non-debugging) symbol that gives the
    941 address of the common block.  According to IBM documentation, only the
    942 `N_BCOMM' has the name of the common block (even though their compiler
    943 actually puts it both places).
    944 
    945    The stabs for the members of the common block are between the
    946 `N_BCOMM' and the `N_ECOMM'; the value of each stab is the offset
    947 within the common block of that variable.  IBM uses the `C_ECOML' stab
    948 type, and there is a corresponding `N_ECOML' stab type, but Sun's
    949 Fortran compiler uses `N_GSYM' instead.  The variables within a common
    950 block use the `V' symbol descriptor (I believe this is true of all
    951 Fortran variables).  Other stabs (at least type declarations using
    952 `C_DECL') can also be between the `N_BCOMM' and the `N_ECOMM'.
    953 
    954 
    955 File: stabs.info,  Node: Statics,  Next: Based Variables,  Prev: Common Blocks,  Up: Variables
    956 
    957 4.5 Static Variables
    958 ====================
    959 
    960 Initialized static variables are represented by the `S' and `V' symbol
    961 descriptors.  `S' means file scope static, and `V' means procedure
    962 scope static.  One exception: in XCOFF, IBM's xlc compiler always uses
    963 `V', and whether it is file scope or not is distinguished by whether
    964 the stab is located within a function.
    965 
    966    In a.out files, `N_STSYM' means the data section, `N_FUN' means the
    967 text section, and `N_LCSYM' means the bss section.  For those systems
    968 with a read-only data section separate from the text section (Solaris),
    969 `N_ROSYM' means the read-only data section.
    970 
    971    For example, the source lines:
    972 
    973      static const int var_const = 5;
    974      static int var_init = 2;
    975      static int var_noinit;
    976 
    977 yield the following stabs:
    978 
    979      .stabs "var_const:S1",36,0,0,_var_const      # 36 is N_FUN
    980      ...
    981      .stabs "var_init:S1",38,0,0,_var_init        # 38 is N_STSYM
    982      ...
    983      .stabs "var_noinit:S1",40,0,0,_var_noinit    # 40 is N_LCSYM
    984 
    985    In XCOFF files, the stab type need not indicate the section;
    986 `C_STSYM' can be used for all statics.  Also, each static variable is
    987 enclosed in a static block.  A `C_BSTAT' (emitted with a `.bs'
    988 assembler directive) symbol begins the static block; its value is the
    989 symbol number of the csect symbol whose value is the address of the
    990 static block, its section is the section of the variables in that
    991 static block, and its name is `.bs'.  A `C_ESTAT' (emitted with a `.es'
    992 assembler directive) symbol ends the static block; its name is `.es'
    993 and its value and section are ignored.
    994 
    995    In ECOFF files, the storage class is used to specify the section, so
    996 the stab type need not indicate the section.
    997 
    998    In ELF files, for the SunPRO compiler version 2.0.1, symbol
    999 descriptor `S' means that the address is absolute (the linker relocates
   1000 it) and symbol descriptor `V' means that the address is relative to the
   1001 start of the relevant section for that compilation unit.  SunPRO has
   1002 plans to have the linker stop relocating stabs; I suspect that their the
   1003 debugger gets the address from the corresponding ELF (not stab) symbol.
   1004 I'm not sure how to find which symbol of that name is the right one.
   1005 The clean way to do all this would be to have the value of a symbol
   1006 descriptor `S' symbol be an offset relative to the start of the file,
   1007 just like everything else, but that introduces obvious compatibility
   1008 problems.  For more information on linker stab relocation, *Note ELF
   1009 Linker Relocation::.
   1010 
   1011 
   1012 File: stabs.info,  Node: Based Variables,  Next: Parameters,  Prev: Statics,  Up: Variables
   1013 
   1014 4.6 Fortran Based Variables
   1015 ===========================
   1016 
   1017 Fortran (at least, the Sun and SGI dialects of FORTRAN-77) has a feature
   1018 which allows allocating arrays with `malloc', but which avoids blurring
   1019 the line between arrays and pointers the way that C does.  In stabs
   1020 such a variable uses the `b' symbol descriptor.
   1021 
   1022    For example, the Fortran declarations
   1023 
   1024      real foo, foo10(10), foo10_5(10,5)
   1025      pointer (foop, foo)
   1026      pointer (foo10p, foo10)
   1027      pointer (foo105p, foo10_5)
   1028 
   1029    produce the stabs
   1030 
   1031      foo:b6
   1032      foo10:bar3;1;10;6
   1033      foo10_5:bar3;1;5;ar3;1;10;6
   1034 
   1035    In this example, `real' is type 6 and type 3 is an integral type
   1036 which is the type of the subscripts of the array (probably `integer').
   1037 
   1038    The `b' symbol descriptor is like `V' in that it denotes a
   1039 statically allocated symbol whose scope is local to a function; see
   1040 *Note Statics::.  The value of the symbol, instead of being the address
   1041 of the variable itself, is the address of a pointer to that variable.
   1042 So in the above example, the value of the `foo' stab is the address of
   1043 a pointer to a real, the value of the `foo10' stab is the address of a
   1044 pointer to a 10-element array of reals, and the value of the `foo10_5'
   1045 stab is the address of a pointer to a 5-element array of 10-element
   1046 arrays of reals.
   1047 
   1048 
   1049 File: stabs.info,  Node: Parameters,  Prev: Based Variables,  Up: Variables
   1050 
   1051 4.7 Parameters
   1052 ==============
   1053 
   1054 Formal parameters to a function are represented by a stab (or sometimes
   1055 two; see below) for each parameter.  The stabs are in the order in which
   1056 the debugger should print the parameters (i.e., the order in which the
   1057 parameters are declared in the source file).  The exact form of the stab
   1058 depends on how the parameter is being passed.
   1059 
   1060    Parameters passed on the stack use the symbol descriptor `p' and the
   1061 `N_PSYM' symbol type (or `C_PSYM' for XCOFF).  The value of the symbol
   1062 is an offset used to locate the parameter on the stack; its exact
   1063 meaning is machine-dependent, but on most machines it is an offset from
   1064 the frame pointer.
   1065 
   1066    As a simple example, the code:
   1067 
   1068      main (argc, argv)
   1069           int argc;
   1070           char **argv;
   1071 
   1072    produces the stabs:
   1073 
   1074      .stabs "main:F1",36,0,0,_main                 # 36 is N_FUN
   1075      .stabs "argc:p1",160,0,0,68                   # 160 is N_PSYM
   1076      .stabs "argv:p20=*21=*2",160,0,0,72
   1077 
   1078    The type definition of `argv' is interesting because it contains
   1079 several type definitions.  Type 21 is pointer to type 2 (char) and
   1080 `argv' (type 20) is pointer to type 21.
   1081 
   1082    The following symbol descriptors are also said to go with `N_PSYM'.
   1083 The value of the symbol is said to be an offset from the argument
   1084 pointer (I'm not sure whether this is true or not).
   1085 
   1086      pP (<<??>>)
   1087      pF Fortran function parameter
   1088      X  (function result variable)
   1089 
   1090 * Menu:
   1091 
   1092 * Register Parameters::
   1093 * Local Variable Parameters::
   1094 * Reference Parameters::
   1095 * Conformant Arrays::
   1096 
   1097 
   1098 File: stabs.info,  Node: Register Parameters,  Next: Local Variable Parameters,  Up: Parameters
   1099 
   1100 4.7.1 Passing Parameters in Registers
   1101 -------------------------------------
   1102 
   1103 If the parameter is passed in a register, then traditionally there are
   1104 two symbols for each argument:
   1105 
   1106      .stabs "arg:p1" . . .       ; N_PSYM
   1107      .stabs "arg:r1" . . .       ; N_RSYM
   1108 
   1109    Debuggers use the second one to find the value, and the first one to
   1110 know that it is an argument.
   1111 
   1112    Because that approach is kind of ugly, some compilers use symbol
   1113 descriptor `P' or `R' to indicate an argument which is in a register.
   1114 Symbol type `C_RPSYM' is used in XCOFF and `N_RSYM' is used otherwise.
   1115 The symbol's value is the register number.  `P' and `R' mean the same
   1116 thing; the difference is that `P' is a GNU invention and `R' is an IBM
   1117 (XCOFF) invention.  As of version 4.9, GDB should handle either one.
   1118 
   1119    There is at least one case where GCC uses a `p' and `r' pair rather
   1120 than `P'; this is where the argument is passed in the argument list and
   1121 then loaded into a register.
   1122 
   1123    According to the AIX documentation, symbol descriptor `D' is for a
   1124 parameter passed in a floating point register.  This seems
   1125 unnecessary--why not just use `R' with a register number which
   1126 indicates that it's a floating point register?  I haven't verified
   1127 whether the system actually does what the documentation indicates.
   1128 
   1129    On the sparc and hppa, for a `P' symbol whose type is a structure or
   1130 union, the register contains the address of the structure.  On the
   1131 sparc, this is also true of a `p' and `r' pair (using Sun `cc') or a
   1132 `p' symbol.  However, if a (small) structure is really in a register,
   1133 `r' is used.  And, to top it all off, on the hppa it might be a
   1134 structure which was passed on the stack and loaded into a register and
   1135 for which there is a `p' and `r' pair!  I believe that symbol
   1136 descriptor `i' is supposed to deal with this case (it is said to mean
   1137 "value parameter by reference, indirect access"; I don't know the
   1138 source for this information), but I don't know details or what
   1139 compilers or debuggers use it, if any (not GDB or GCC).  It is not
   1140 clear to me whether this case needs to be dealt with differently than
   1141 parameters passed by reference (*note Reference Parameters::).
   1142 
   1143 
   1144 File: stabs.info,  Node: Local Variable Parameters,  Next: Reference Parameters,  Prev: Register Parameters,  Up: Parameters
   1145 
   1146 4.7.2 Storing Parameters as Local Variables
   1147 -------------------------------------------
   1148 
   1149 There is a case similar to an argument in a register, which is an
   1150 argument that is actually stored as a local variable.  Sometimes this
   1151 happens when the argument was passed in a register and then the compiler
   1152 stores it as a local variable.  If possible, the compiler should claim
   1153 that it's in a register, but this isn't always done.
   1154 
   1155    If a parameter is passed as one type and converted to a smaller type
   1156 by the prologue (for example, the parameter is declared as a `float',
   1157 but the calling conventions specify that it is passed as a `double'),
   1158 then GCC2 (sometimes) uses a pair of symbols.  The first symbol uses
   1159 symbol descriptor `p' and the type which is passed.  The second symbol
   1160 has the type and location which the parameter actually has after the
   1161 prologue.  For example, suppose the following C code appears with no
   1162 prototypes involved:
   1163 
   1164      void
   1165      subr (f)
   1166           float f;
   1167      {
   1168 
   1169    if `f' is passed as a double at stack offset 8, and the prologue
   1170 converts it to a float in register number 0, then the stabs look like:
   1171 
   1172      .stabs "f:p13",160,0,3,8   # 160 is `N_PSYM', here 13 is `double'
   1173      .stabs "f:r12",64,0,3,0    # 64 is `N_RSYM', here 12 is `float'
   1174 
   1175    In both stabs 3 is the line number where `f' is declared (*note Line
   1176 Numbers::).
   1177 
   1178    GCC, at least on the 960, has another solution to the same problem.
   1179 It uses a single `p' symbol descriptor for an argument which is stored
   1180 as a local variable but uses `N_LSYM' instead of `N_PSYM'.  In this
   1181 case, the value of the symbol is an offset relative to the local
   1182 variables for that function, not relative to the arguments; on some
   1183 machines those are the same thing, but not on all.
   1184 
   1185    On the VAX or on other machines in which the calling convention
   1186 includes the number of words of arguments actually passed, the debugger
   1187 (GDB at least) uses the parameter symbols to keep track of whether it
   1188 needs to print nameless arguments in addition to the formal parameters
   1189 which it has printed because each one has a stab.  For example, in
   1190 
   1191      extern int fprintf (FILE *stream, char *format, ...);
   1192      ...
   1193      fprintf (stdout, "%d\n", x);
   1194 
   1195    there are stabs for `stream' and `format'.  On most machines, the
   1196 debugger can only print those two arguments (because it has no way of
   1197 knowing that additional arguments were passed), but on the VAX or other
   1198 machines with a calling convention which indicates the number of words
   1199 of arguments, the debugger can print all three arguments.  To do so,
   1200 the parameter symbol (symbol descriptor `p') (not necessarily `r' or
   1201 symbol descriptor omitted symbols) needs to contain the actual type as
   1202 passed (for example, `double' not `float' if it is passed as a double
   1203 and converted to a float).
   1204 
   1205 
   1206 File: stabs.info,  Node: Reference Parameters,  Next: Conformant Arrays,  Prev: Local Variable Parameters,  Up: Parameters
   1207 
   1208 4.7.3 Passing Parameters by Reference
   1209 -------------------------------------
   1210 
   1211 If the parameter is passed by reference (e.g., Pascal `VAR'
   1212 parameters), then the symbol descriptor is `v' if it is in the argument
   1213 list, or `a' if it in a register.  Other than the fact that these
   1214 contain the address of the parameter rather than the parameter itself,
   1215 they are identical to `p' and `R', respectively.  I believe `a' is an
   1216 AIX invention; `v' is supported by all stabs-using systems as far as I
   1217 know.
   1218 
   1219 
   1220 File: stabs.info,  Node: Conformant Arrays,  Prev: Reference Parameters,  Up: Parameters
   1221 
   1222 4.7.4 Passing Conformant Array Parameters
   1223 -----------------------------------------
   1224 
   1225 Conformant arrays are a feature of Modula-2, and perhaps other
   1226 languages, in which the size of an array parameter is not known to the
   1227 called function until run-time.  Such parameters have two stabs: a `x'
   1228 for the array itself, and a `C', which represents the size of the
   1229 array.  The value of the `x' stab is the offset in the argument list
   1230 where the address of the array is stored (it this right?  it is a
   1231 guess); the value of the `C' stab is the offset in the argument list
   1232 where the size of the array (in elements? in bytes?) is stored.
   1233 
   1234 
   1235 File: stabs.info,  Node: Types,  Next: Macro define and undefine,  Prev: Variables,  Up: Top
   1236 
   1237 5 Defining Types
   1238 ****************
   1239 
   1240 The examples so far have described types as references to previously
   1241 defined types, or defined in terms of subranges of or pointers to
   1242 previously defined types.  This chapter describes the other type
   1243 descriptors that may follow the `=' in a type definition.
   1244 
   1245 * Menu:
   1246 
   1247 * Builtin Types::		Integers, floating point, void, etc.
   1248 * Miscellaneous Types::		Pointers, sets, files, etc.
   1249 * Cross-References::		Referring to a type not yet defined.
   1250 * Subranges::			A type with a specific range.
   1251 * Arrays::			An aggregate type of same-typed elements.
   1252 * Strings::			Like an array but also has a length.
   1253 * Enumerations::		Like an integer but the values have names.
   1254 * Structures::			An aggregate type of different-typed elements.
   1255 * Typedefs::			Giving a type a name.
   1256 * Unions::			Different types sharing storage.
   1257 * Function Types::
   1258 
   1259 
   1260 File: stabs.info,  Node: Builtin Types,  Next: Miscellaneous Types,  Up: Types
   1261 
   1262 5.1 Builtin Types
   1263 =================
   1264 
   1265 Certain types are built in (`int', `short', `void', `float', etc.); the
   1266 debugger recognizes these types and knows how to handle them.  Thus,
   1267 don't be surprised if some of the following ways of specifying builtin
   1268 types do not specify everything that a debugger would need to know
   1269 about the type--in some cases they merely specify enough information to
   1270 distinguish the type from other types.
   1271 
   1272    The traditional way to define builtin types is convoluted, so new
   1273 ways have been invented to describe them.  Sun's `acc' uses special
   1274 builtin type descriptors (`b' and `R'), and IBM uses negative type
   1275 numbers.  GDB accepts all three ways, as of version 4.8; dbx just
   1276 accepts the traditional builtin types and perhaps one of the other two
   1277 formats.  The following sections describe each of these formats.
   1278 
   1279 * Menu:
   1280 
   1281 * Traditional Builtin Types::	Put on your seat belts and prepare for kludgery
   1282 * Builtin Type Descriptors::	Builtin types with special type descriptors
   1283 * Negative Type Numbers::	Builtin types using negative type numbers
   1284 
   1285 
   1286 File: stabs.info,  Node: Traditional Builtin Types,  Next: Builtin Type Descriptors,  Up: Builtin Types
   1287 
   1288 5.1.1 Traditional Builtin Types
   1289 -------------------------------
   1290 
   1291 This is the traditional, convoluted method for defining builtin types.
   1292 There are several classes of such type definitions: integer, floating
   1293 point, and `void'.
   1294 
   1295 * Menu:
   1296 
   1297 * Traditional Integer Types::
   1298 * Traditional Other Types::
   1299 
   1300 
   1301 File: stabs.info,  Node: Traditional Integer Types,  Next: Traditional Other Types,  Up: Traditional Builtin Types
   1302 
   1303 5.1.1.1 Traditional Integer Types
   1304 .................................
   1305 
   1306 Often types are defined as subranges of themselves.  If the bounding
   1307 values fit within an `int', then they are given normally.  For example:
   1308 
   1309      .stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0    # 128 is N_LSYM
   1310      .stabs "char:t2=r2;0;127;",128,0,0,0
   1311 
   1312    Builtin types can also be described as subranges of `int':
   1313 
   1314      .stabs "unsigned short:t6=r1;0;65535;",128,0,0,0
   1315 
   1316    If the lower bound of a subrange is 0 and the upper bound is -1, the
   1317 type is an unsigned integral type whose bounds are too big to describe
   1318 in an `int'.  Traditionally this is only used for `unsigned int' and
   1319 `unsigned long':
   1320 
   1321      .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
   1322 
   1323    For larger types, GCC 2.4.5 puts out bounds in octal, with one or
   1324 more leading zeroes.  In this case a negative bound consists of a number
   1325 which is a 1 bit (for the sign bit) followed by a 0 bit for each bit in
   1326 the number (except the sign bit), and a positive bound is one which is a
   1327 1 bit for each bit in the number (except possibly the sign bit).  All
   1328 known versions of dbx and GDB version 4 accept this (at least in the
   1329 sense of not refusing to process the file), but GDB 3.5 refuses to read
   1330 the whole file containing such symbols.  So GCC 2.3.3 did not output the
   1331 proper size for these types.  As an example of octal bounds, the string
   1332 fields of the stabs for 64 bit integer types look like:
   1333 
   1334      long int:t3=r1;001000000000000000000000;000777777777777777777777;
   1335      long unsigned int:t5=r1;000000000000000000000000;001777777777777777777777;
   1336 
   1337    If the lower bound of a subrange is 0 and the upper bound is
   1338 negative, the type is an unsigned integral type whose size in bytes is
   1339 the absolute value of the upper bound.  I believe this is a Convex
   1340 convention for `unsigned long long'.
   1341 
   1342    If the lower bound of a subrange is negative and the upper bound is
   1343 0, the type is a signed integral type whose size in bytes is the
   1344 absolute value of the lower bound.  I believe this is a Convex
   1345 convention for `long long'.  To distinguish this from a legitimate
   1346 subrange, the type should be a subrange of itself.  I'm not sure whether
   1347 this is the case for Convex.
   1348 
   1349 
   1350 File: stabs.info,  Node: Traditional Other Types,  Prev: Traditional Integer Types,  Up: Traditional Builtin Types
   1351 
   1352 5.1.1.2 Traditional Other Types
   1353 ...............................
   1354 
   1355 If the upper bound of a subrange is 0 and the lower bound is positive,
   1356 the type is a floating point type, and the lower bound of the subrange
   1357 indicates the number of bytes in the type:
   1358 
   1359      .stabs "float:t12=r1;4;0;",128,0,0,0
   1360      .stabs "double:t13=r1;8;0;",128,0,0,0
   1361 
   1362    However, GCC writes `long double' the same way it writes `double',
   1363 so there is no way to distinguish.
   1364 
   1365      .stabs "long double:t14=r1;8;0;",128,0,0,0
   1366 
   1367    Complex types are defined the same way as floating-point types;
   1368 there is no way to distinguish a single-precision complex from a
   1369 double-precision floating-point type.
   1370 
   1371    The C `void' type is defined as itself:
   1372 
   1373      .stabs "void:t15=15",128,0,0,0
   1374 
   1375    I'm not sure how a boolean type is represented.
   1376 
   1377 
   1378 File: stabs.info,  Node: Builtin Type Descriptors,  Next: Negative Type Numbers,  Prev: Traditional Builtin Types,  Up: Builtin Types
   1379 
   1380 5.1.2 Defining Builtin Types Using Builtin Type Descriptors
   1381 -----------------------------------------------------------
   1382 
   1383 This is the method used by Sun's `acc' for defining builtin types.
   1384 These are the type descriptors to define builtin types:
   1385 
   1386 `b SIGNED CHAR-FLAG WIDTH ; OFFSET ; NBITS ;'
   1387      Define an integral type.  SIGNED is `u' for unsigned or `s' for
   1388      signed.  CHAR-FLAG is `c' which indicates this is a character
   1389      type, or is omitted.  I assume this is to distinguish an integral
   1390      type from a character type of the same size, for example it might
   1391      make sense to set it for the C type `wchar_t' so the debugger can
   1392      print such variables differently (Solaris does not do this).  Sun
   1393      sets it on the C types `signed char' and `unsigned char' which
   1394      arguably is wrong.  WIDTH and OFFSET appear to be for small
   1395      objects stored in larger ones, for example a `short' in an `int'
   1396      register.  WIDTH is normally the number of bytes in the type.
   1397      OFFSET seems to always be zero.  NBITS is the number of bits in
   1398      the type.
   1399 
   1400      Note that type descriptor `b' used for builtin types conflicts with
   1401      its use for Pascal space types (*note Miscellaneous Types::); they
   1402      can be distinguished because the character following the type
   1403      descriptor will be a digit, `(', or `-' for a Pascal space type, or
   1404      `u' or `s' for a builtin type.
   1405 
   1406 `w'
   1407      Documented by AIX to define a wide character type, but their
   1408      compiler actually uses negative type numbers (*note Negative Type
   1409      Numbers::).
   1410 
   1411 `R FP-TYPE ; BYTES ;'
   1412      Define a floating point type.  FP-TYPE has one of the following
   1413      values:
   1414 
   1415     `1 (NF_SINGLE)'
   1416           IEEE 32-bit (single precision) floating point format.
   1417 
   1418     `2 (NF_DOUBLE)'
   1419           IEEE 64-bit (double precision) floating point format.
   1420 
   1421     `3 (NF_COMPLEX)'
   1422 
   1423     `4 (NF_COMPLEX16)'
   1424 
   1425     `5 (NF_COMPLEX32)'
   1426           These are for complex numbers.  A comment in the GDB source
   1427           describes them as Fortran `complex', `double complex', and
   1428           `complex*16', respectively, but what does that mean?  (i.e.,
   1429           Single precision?  Double precision?).
   1430 
   1431     `6 (NF_LDOUBLE)'
   1432           Long double.  This should probably only be used for Sun format
   1433           `long double', and new codes should be used for other floating
   1434           point formats (`NF_DOUBLE' can be used if a `long double' is
   1435           really just an IEEE double, of course).
   1436 
   1437      BYTES is the number of bytes occupied by the type.  This allows a
   1438      debugger to perform some operations with the type even if it
   1439      doesn't understand FP-TYPE.
   1440 
   1441 `g TYPE-INFORMATION ; NBITS'
   1442      Documented by AIX to define a floating type, but their compiler
   1443      actually uses negative type numbers (*note Negative Type
   1444      Numbers::).
   1445 
   1446 `c TYPE-INFORMATION ; NBITS'
   1447      Documented by AIX to define a complex type, but their compiler
   1448      actually uses negative type numbers (*note Negative Type
   1449      Numbers::).
   1450 
   1451    The C `void' type is defined as a signed integral type 0 bits long:
   1452      .stabs "void:t19=bs0;0;0",128,0,0,0
   1453    The Solaris compiler seems to omit the trailing semicolon in this
   1454 case.  Getting sloppy in this way is not a swift move because if a type
   1455 is embedded in a more complex expression it is necessary to be able to
   1456 tell where it ends.
   1457 
   1458    I'm not sure how a boolean type is represented.
   1459 
   1460 
   1461 File: stabs.info,  Node: Negative Type Numbers,  Prev: Builtin Type Descriptors,  Up: Builtin Types
   1462 
   1463 5.1.3 Negative Type Numbers
   1464 ---------------------------
   1465 
   1466 This is the method used in XCOFF for defining builtin types.  Since the
   1467 debugger knows about the builtin types anyway, the idea of negative
   1468 type numbers is simply to give a special type number which indicates
   1469 the builtin type.  There is no stab defining these types.
   1470 
   1471    There are several subtle issues with negative type numbers.
   1472 
   1473    One is the size of the type.  A builtin type (for example the C types
   1474 `int' or `long') might have different sizes depending on compiler
   1475 options, the target architecture, the ABI, etc.  This issue doesn't
   1476 come up for IBM tools since (so far) they just target the RS/6000; the
   1477 sizes indicated below for each size are what the IBM RS/6000 tools use.
   1478 To deal with differing sizes, either define separate negative type
   1479 numbers for each size (which works but requires changing the debugger,
   1480 and, unless you get both AIX dbx and GDB to accept the change,
   1481 introduces an incompatibility), or use a type attribute (*note String
   1482 Field::) to define a new type with the appropriate size (which merely
   1483 requires a debugger which understands type attributes, like AIX dbx or
   1484 GDB).  For example,
   1485 
   1486      .stabs "boolean:t10=@s8;-16",128,0,0,0
   1487 
   1488    defines an 8-bit boolean type, and
   1489 
   1490      .stabs "boolean:t10=@s64;-16",128,0,0,0
   1491 
   1492    defines a 64-bit boolean type.
   1493 
   1494    A similar issue is the format of the type.  This comes up most often
   1495 for floating-point types, which could have various formats (particularly
   1496 extended doubles, which vary quite a bit even among IEEE systems).
   1497 Again, it is best to define a new negative type number for each
   1498 different format; changing the format based on the target system has
   1499 various problems.  One such problem is that the Alpha has both VAX and
   1500 IEEE floating types.  One can easily imagine one library using the VAX
   1501 types and another library in the same executable using the IEEE types.
   1502 Another example is that the interpretation of whether a boolean is true
   1503 or false can be based on the least significant bit, most significant
   1504 bit, whether it is zero, etc., and different compilers (or different
   1505 options to the same compiler) might provide different kinds of boolean.
   1506 
   1507    The last major issue is the names of the types.  The name of a given
   1508 type depends _only_ on the negative type number given; these do not
   1509 vary depending on the language, the target system, or anything else.
   1510 One can always define separate type numbers--in the following list you
   1511 will see for example separate `int' and `integer*4' types which are
   1512 identical except for the name.  But compatibility can be maintained by
   1513 not inventing new negative type numbers and instead just defining a new
   1514 type with a new name.  For example:
   1515 
   1516      .stabs "CARDINAL:t10=-8",128,0,0,0
   1517 
   1518    Here is the list of negative type numbers.  The phrase "integral
   1519 type" is used to mean twos-complement (I strongly suspect that all
   1520 machines which use stabs use twos-complement; most machines use
   1521 twos-complement these days).
   1522 
   1523 `-1'
   1524      `int', 32 bit signed integral type.
   1525 
   1526 `-2'
   1527      `char', 8 bit type holding a character.   Both GDB and dbx on AIX
   1528      treat this as signed.  GCC uses this type whether `char' is signed
   1529      or not, which seems like a bad idea.  The AIX compiler (`xlc')
   1530      seems to avoid this type; it uses -5 instead for `char'.
   1531 
   1532 `-3'
   1533      `short', 16 bit signed integral type.
   1534 
   1535 `-4'
   1536      `long', 32 bit signed integral type.
   1537 
   1538 `-5'
   1539      `unsigned char', 8 bit unsigned integral type.
   1540 
   1541 `-6'
   1542      `signed char', 8 bit signed integral type.
   1543 
   1544 `-7'
   1545      `unsigned short', 16 bit unsigned integral type.
   1546 
   1547 `-8'
   1548      `unsigned int', 32 bit unsigned integral type.
   1549 
   1550 `-9'
   1551      `unsigned', 32 bit unsigned integral type.
   1552 
   1553 `-10'
   1554      `unsigned long', 32 bit unsigned integral type.
   1555 
   1556 `-11'
   1557      `void', type indicating the lack of a value.
   1558 
   1559 `-12'
   1560      `float', IEEE single precision.
   1561 
   1562 `-13'
   1563      `double', IEEE double precision.
   1564 
   1565 `-14'
   1566      `long double', IEEE double precision.  The compiler claims the size
   1567      will increase in a future release, and for binary compatibility
   1568      you have to avoid using `long double'.  I hope when they increase
   1569      it they use a new negative type number.
   1570 
   1571 `-15'
   1572      `integer'.  32 bit signed integral type.
   1573 
   1574 `-16'
   1575      `boolean'.  32 bit type.  GDB and GCC assume that zero is false,
   1576      one is true, and other values have unspecified meaning.  I hope
   1577      this agrees with how the IBM tools use the type.
   1578 
   1579 `-17'
   1580      `short real'.  IEEE single precision.
   1581 
   1582 `-18'
   1583      `real'.  IEEE double precision.
   1584 
   1585 `-19'
   1586      `stringptr'.  *Note Strings::.
   1587 
   1588 `-20'
   1589      `character', 8 bit unsigned character type.
   1590 
   1591 `-21'
   1592      `logical*1', 8 bit type.  This Fortran type has a split
   1593      personality in that it is used for boolean variables, but can also
   1594      be used for unsigned integers.  0 is false, 1 is true, and other
   1595      values are non-boolean.
   1596 
   1597 `-22'
   1598      `logical*2', 16 bit type.  This Fortran type has a split
   1599      personality in that it is used for boolean variables, but can also
   1600      be used for unsigned integers.  0 is false, 1 is true, and other
   1601      values are non-boolean.
   1602 
   1603 `-23'
   1604      `logical*4', 32 bit type.  This Fortran type has a split
   1605      personality in that it is used for boolean variables, but can also
   1606      be used for unsigned integers.  0 is false, 1 is true, and other
   1607      values are non-boolean.
   1608 
   1609 `-24'
   1610      `logical', 32 bit type.  This Fortran type has a split personality
   1611      in that it is used for boolean variables, but can also be used for
   1612      unsigned integers.  0 is false, 1 is true, and other values are
   1613      non-boolean.
   1614 
   1615 `-25'
   1616      `complex'.  A complex type consisting of two IEEE single-precision
   1617      floating point values.
   1618 
   1619 `-26'
   1620      `complex'.  A complex type consisting of two IEEE double-precision
   1621      floating point values.
   1622 
   1623 `-27'
   1624      `integer*1', 8 bit signed integral type.
   1625 
   1626 `-28'
   1627      `integer*2', 16 bit signed integral type.
   1628 
   1629 `-29'
   1630      `integer*4', 32 bit signed integral type.
   1631 
   1632 `-30'
   1633      `wchar'.  Wide character, 16 bits wide, unsigned (what format?
   1634      Unicode?).
   1635 
   1636 `-31'
   1637      `long long', 64 bit signed integral type.
   1638 
   1639 `-32'
   1640      `unsigned long long', 64 bit unsigned integral type.
   1641 
   1642 `-33'
   1643      `logical*8', 64 bit unsigned integral type.
   1644 
   1645 `-34'
   1646      `integer*8', 64 bit signed integral type.
   1647 
   1648 
   1649 File: stabs.info,  Node: Miscellaneous Types,  Next: Cross-References,  Prev: Builtin Types,  Up: Types
   1650 
   1651 5.2 Miscellaneous Types
   1652 =======================
   1653 
   1654 `b TYPE-INFORMATION ; BYTES'
   1655      Pascal space type.  This is documented by IBM; what does it mean?
   1656 
   1657      This use of the `b' type descriptor can be distinguished from its
   1658      use for builtin integral types (*note Builtin Type Descriptors::)
   1659      because the character following the type descriptor is always a
   1660      digit, `(', or `-'.
   1661 
   1662 `B TYPE-INFORMATION'
   1663      A volatile-qualified version of TYPE-INFORMATION.  This is a Sun
   1664      extension.  References and stores to a variable with a
   1665      volatile-qualified type must not be optimized or cached; they must
   1666      occur as the user specifies them.
   1667 
   1668 `d TYPE-INFORMATION'
   1669      File of type TYPE-INFORMATION.  As far as I know this is only used
   1670      by Pascal.
   1671 
   1672 `k TYPE-INFORMATION'
   1673      A const-qualified version of TYPE-INFORMATION.  This is a Sun
   1674      extension.  A variable with a const-qualified type cannot be
   1675      modified.
   1676 
   1677 `M TYPE-INFORMATION ; LENGTH'
   1678      Multiple instance type.  The type seems to composed of LENGTH
   1679      repetitions of TYPE-INFORMATION, for example `character*3' is
   1680      represented by `M-2;3', where `-2' is a reference to a character
   1681      type (*note Negative Type Numbers::).  I'm not sure how this
   1682      differs from an array.  This appears to be a Fortran feature.
   1683      LENGTH is a bound, like those in range types; see *note
   1684      Subranges::.
   1685 
   1686 `S TYPE-INFORMATION'
   1687      Pascal set type.  TYPE-INFORMATION must be a small type such as an
   1688      enumeration or a subrange, and the type is a bitmask whose length
   1689      is specified by the number of elements in TYPE-INFORMATION.
   1690 
   1691      In CHILL, if it is a bitstring instead of a set, also use the `S'
   1692      type attribute (*note String Field::).
   1693 
   1694 `* TYPE-INFORMATION'
   1695      Pointer to TYPE-INFORMATION.
   1696 
   1697 
   1698 File: stabs.info,  Node: Cross-References,  Next: Subranges,  Prev: Miscellaneous Types,  Up: Types
   1699 
   1700 5.3 Cross-References to Other Types
   1701 ===================================
   1702 
   1703 A type can be used before it is defined; one common way to deal with
   1704 that situation is just to use a type reference to a type which has not
   1705 yet been defined.
   1706 
   1707    Another way is with the `x' type descriptor, which is followed by
   1708 `s' for a structure tag, `u' for a union tag, or `e' for a enumerator
   1709 tag, followed by the name of the tag, followed by `:'.  If the name
   1710 contains `::' between a `<' and `>' pair (for C++ templates), such a
   1711 `::' does not end the name--only a single `:' ends the name; see *note
   1712 Nested Symbols::.
   1713 
   1714    For example, the following C declarations:
   1715 
   1716      struct foo;
   1717      struct foo *bar;
   1718 
   1719 produce:
   1720 
   1721      .stabs "bar:G16=*17=xsfoo:",32,0,0,0
   1722 
   1723    Not all debuggers support the `x' type descriptor, so on some
   1724 machines GCC does not use it.  I believe that for the above example it
   1725 would just emit a reference to type 17 and never define it, but I
   1726 haven't verified that.
   1727 
   1728    Modula-2 imported types, at least on AIX, use the `i' type
   1729 descriptor, which is followed by the name of the module from which the
   1730 type is imported, followed by `:', followed by the name of the type.
   1731 There is then optionally a comma followed by type information for the
   1732 type.  This differs from merely naming the type (*note Typedefs::) in
   1733 that it identifies the module; I don't understand whether the name of
   1734 the type given here is always just the same as the name we are giving
   1735 it, or whether this type descriptor is used with a nameless stab (*note
   1736 String Field::), or what.  The symbol ends with `;'.
   1737 
   1738 
   1739 File: stabs.info,  Node: Subranges,  Next: Arrays,  Prev: Cross-References,  Up: Types
   1740 
   1741 5.4 Subrange Types
   1742 ==================
   1743 
   1744 The `r' type descriptor defines a type as a subrange of another type.
   1745 It is followed by type information for the type of which it is a
   1746 subrange, a semicolon, an integral lower bound, a semicolon, an
   1747 integral upper bound, and a semicolon.  The AIX documentation does not
   1748 specify the trailing semicolon, in an effort to specify array indexes
   1749 more cleanly, but a subrange which is not an array index has always
   1750 included a trailing semicolon (*note Arrays::).
   1751 
   1752    Instead of an integer, either bound can be one of the following:
   1753 
   1754 `A OFFSET'
   1755      The bound is passed by reference on the stack at offset OFFSET
   1756      from the argument list.  *Note Parameters::, for more information
   1757      on such offsets.
   1758 
   1759 `T OFFSET'
   1760      The bound is passed by value on the stack at offset OFFSET from
   1761      the argument list.
   1762 
   1763 `a REGISTER-NUMBER'
   1764      The bound is passed by reference in register number
   1765      REGISTER-NUMBER.
   1766 
   1767 `t REGISTER-NUMBER'
   1768      The bound is passed by value in register number REGISTER-NUMBER.
   1769 
   1770 `J'
   1771      There is no bound.
   1772 
   1773    Subranges are also used for builtin types; see *note Traditional
   1774 Builtin Types::.
   1775 
   1776 
   1777 File: stabs.info,  Node: Arrays,  Next: Strings,  Prev: Subranges,  Up: Types
   1778 
   1779 5.5 Array Types
   1780 ===============
   1781 
   1782 Arrays use the `a' type descriptor.  Following the type descriptor is
   1783 the type of the index and the type of the array elements.  If the index
   1784 type is a range type, it ends in a semicolon; otherwise (for example,
   1785 if it is a type reference), there does not appear to be any way to tell
   1786 where the types are separated.  In an effort to clean up this mess, IBM
   1787 documents the two types as being separated by a semicolon, and a range
   1788 type as not ending in a semicolon (but this is not right for range
   1789 types which are not array indexes, *note Subranges::).  I think
   1790 probably the best solution is to specify that a semicolon ends a range
   1791 type, and that the index type and element type of an array are
   1792 separated by a semicolon, but that if the index type is a range type,
   1793 the extra semicolon can be omitted.  GDB (at least through version 4.9)
   1794 doesn't support any kind of index type other than a range anyway; I'm
   1795 not sure about dbx.
   1796 
   1797    It is well established, and widely used, that the type of the index,
   1798 unlike most types found in the stabs, is merely a type definition, not
   1799 type information (*note String Field::) (that is, it need not start with
   1800 `TYPE-NUMBER=' if it is defining a new type).  According to a comment
   1801 in GDB, this is also true of the type of the array elements; it gives
   1802 `ar1;1;10;ar1;1;10;4' as a legitimate way to express a two dimensional
   1803 array.  According to AIX documentation, the element type must be type
   1804 information.  GDB accepts either.
   1805 
   1806    The type of the index is often a range type, expressed as the type
   1807 descriptor `r' and some parameters.  It defines the size of the array.
   1808 In the example below, the range `r1;0;2;' defines an index type which
   1809 is a subrange of type 1 (integer), with a lower bound of 0 and an upper
   1810 bound of 2.  This defines the valid range of subscripts of a
   1811 three-element C array.
   1812 
   1813    For example, the definition:
   1814 
   1815      char char_vec[3] = {'a','b','c'};
   1816 
   1817 produces the output:
   1818 
   1819      .stabs "char_vec:G19=ar1;0;2;2",32,0,0,0
   1820           .global _char_vec
   1821           .align 4
   1822      _char_vec:
   1823           .byte 97
   1824           .byte 98
   1825           .byte 99
   1826 
   1827    If an array is "packed", the elements are spaced more closely than
   1828 normal, saving memory at the expense of speed.  For example, an array
   1829 of 3-byte objects might, if unpacked, have each element aligned on a
   1830 4-byte boundary, but if packed, have no padding.  One way to specify
   1831 that something is packed is with type attributes (*note String
   1832 Field::).  In the case of arrays, another is to use the `P' type
   1833 descriptor instead of `a'.  Other than specifying a packed array, `P'
   1834 is identical to `a'.
   1835 
   1836    An open array is represented by the `A' type descriptor followed by
   1837 type information specifying the type of the array elements.
   1838 
   1839    An N-dimensional dynamic array is represented by
   1840 
   1841      D DIMENSIONS ; TYPE-INFORMATION
   1842 
   1843    DIMENSIONS is the number of dimensions; TYPE-INFORMATION specifies
   1844 the type of the array elements.
   1845 
   1846    A subarray of an N-dimensional array is represented by
   1847 
   1848      E DIMENSIONS ; TYPE-INFORMATION
   1849 
   1850    DIMENSIONS is the number of dimensions; TYPE-INFORMATION specifies
   1851 the type of the array elements.
   1852 
   1853 
   1854 File: stabs.info,  Node: Strings,  Next: Enumerations,  Prev: Arrays,  Up: Types
   1855 
   1856 5.6 Strings
   1857 ===========
   1858 
   1859 Some languages, like C or the original Pascal, do not have string types,
   1860 they just have related things like arrays of characters.  But most
   1861 Pascals and various other languages have string types, which are
   1862 indicated as follows:
   1863 
   1864 `n TYPE-INFORMATION ; BYTES'
   1865      BYTES is the maximum length.  I'm not sure what TYPE-INFORMATION
   1866      is; I suspect that it means that this is a string of
   1867      TYPE-INFORMATION (thus allowing a string of integers, a string of
   1868      wide characters, etc., as well as a string of characters).  Not
   1869      sure what the format of this type is.  This is an AIX feature.
   1870 
   1871 `z TYPE-INFORMATION ; BYTES'
   1872      Just like `n' except that this is a gstring, not an ordinary
   1873      string.  I don't know the difference.
   1874 
   1875 `N'
   1876      Pascal Stringptr.  What is this?  This is an AIX feature.
   1877 
   1878    Languages, such as CHILL which have a string type which is basically
   1879 just an array of characters use the `S' type attribute (*note String
   1880 Field::).
   1881 
   1882 
   1883 File: stabs.info,  Node: Enumerations,  Next: Structures,  Prev: Strings,  Up: Types
   1884 
   1885 5.7 Enumerations
   1886 ================
   1887 
   1888 Enumerations are defined with the `e' type descriptor.
   1889 
   1890    The source line below declares an enumeration type at file scope.
   1891 The type definition is located after the `N_RBRAC' that marks the end of
   1892 the previous procedure's block scope, and before the `N_FUN' that marks
   1893 the beginning of the next procedure's block scope.  Therefore it does
   1894 not describe a block local symbol, but a file local one.
   1895 
   1896    The source line:
   1897 
   1898      enum e_places {first,second=3,last};
   1899 
   1900 generates the following stab:
   1901 
   1902      .stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0
   1903 
   1904    The symbol descriptor (`T') says that the stab describes a
   1905 structure, enumeration, or union tag.  The type descriptor `e',
   1906 following the `22=' of the type definition narrows it down to an
   1907 enumeration type.  Following the `e' is a list of the elements of the
   1908 enumeration.  The format is `NAME:VALUE,'.  The list of elements ends
   1909 with `;'.  The fact that VALUE is specified as an integer can cause
   1910 problems if the value is large.  GCC 2.5.2 tries to output it in octal
   1911 in that case with a leading zero, which is probably a good thing,
   1912 although GDB 4.11 supports octal only in cases where decimal is
   1913 perfectly good.  Negative decimal values are supported by both GDB and
   1914 dbx.
   1915 
   1916    There is no standard way to specify the size of an enumeration type;
   1917 it is determined by the architecture (normally all enumerations types
   1918 are 32 bits).  Type attributes can be used to specify an enumeration
   1919 type of another size for debuggers which support them; see *note String
   1920 Field::.
   1921 
   1922    Enumeration types are unusual in that they define symbols for the
   1923 enumeration values (`first', `second', and `third' in the above
   1924 example), and even though these symbols are visible in the file as a
   1925 whole (rather than being in a more local namespace like structure
   1926 member names), they are defined in the type definition for the
   1927 enumeration type rather than each having their own symbol.  In order to
   1928 be fast, GDB will only get symbols from such types (in its initial scan
   1929 of the stabs) if the type is the first thing defined after a `T' or `t'
   1930 symbol descriptor (the above example fulfills this requirement).  If
   1931 the type does not have a name, the compiler should emit it in a
   1932 nameless stab (*note String Field::); GCC does this.
   1933 
   1934 
   1935 File: stabs.info,  Node: Structures,  Next: Typedefs,  Prev: Enumerations,  Up: Types
   1936 
   1937 5.8 Structures
   1938 ==============
   1939 
   1940 The encoding of structures in stabs can be shown with an example.
   1941 
   1942    The following source code declares a structure tag and defines an
   1943 instance of the structure in global scope. Then a `typedef' equates the
   1944 structure tag with a new type.  Separate stabs are generated for the
   1945 structure tag, the structure `typedef', and the structure instance.  The
   1946 stabs for the tag and the `typedef' are emitted when the definitions are
   1947 encountered.  Since the structure elements are not initialized, the
   1948 stab and code for the structure variable itself is located at the end
   1949 of the program in the bss section.
   1950 
   1951      struct s_tag {
   1952        int   s_int;
   1953        float s_float;
   1954        char  s_char_vec[8];
   1955        struct s_tag* s_next;
   1956      } g_an_s;
   1957 
   1958      typedef struct s_tag s_typedef;
   1959 
   1960    The structure tag has an `N_LSYM' stab type because, like the
   1961 enumeration, the symbol has file scope.  Like the enumeration, the
   1962 symbol descriptor is `T', for enumeration, structure, or tag type.  The
   1963 type descriptor `s' following the `16=' of the type definition narrows
   1964 the symbol type to structure.
   1965 
   1966    Following the `s' type descriptor is the number of bytes the
   1967 structure occupies, followed by a description of each structure element.
   1968 The structure element descriptions are of the form `NAME:TYPE, BIT
   1969 OFFSET FROM THE START OF THE STRUCT, NUMBER OF BITS IN THE ELEMENT'.
   1970 
   1971      # 128 is N_LSYM
   1972      .stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;
   1973              s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0
   1974 
   1975    In this example, the first two structure elements are previously
   1976 defined types.  For these, the type following the `NAME:' part of the
   1977 element description is a simple type reference.  The other two structure
   1978 elements are new types.  In this case there is a type definition
   1979 embedded after the `NAME:'.  The type definition for the array element
   1980 looks just like a type definition for a stand-alone array.  The
   1981 `s_next' field is a pointer to the same kind of structure that the
   1982 field is an element of.  So the definition of structure type 16
   1983 contains a type definition for an element which is a pointer to type 16.
   1984 
   1985    If a field is a static member (this is a C++ feature in which a
   1986 single variable appears to be a field of every structure of a given
   1987 type) it still starts out with the field name, a colon, and the type,
   1988 but then instead of a comma, bit position, comma, and bit size, there
   1989 is a colon followed by the name of the variable which each such field
   1990 refers to.
   1991 
   1992    If the structure has methods (a C++ feature), they follow the
   1993 non-method fields; see *note Cplusplus::.
   1994 
   1995 
   1996 File: stabs.info,  Node: Typedefs,  Next: Unions,  Prev: Structures,  Up: Types
   1997 
   1998 5.9 Giving a Type a Name
   1999 ========================
   2000 
   2001 To give a type a name, use the `t' symbol descriptor.  The type is
   2002 specified by the type information (*note String Field::) for the stab.
   2003 For example,
   2004 
   2005      .stabs "s_typedef:t16",128,0,0,0     # 128 is N_LSYM
   2006 
   2007    specifies that `s_typedef' refers to type number 16.  Such stabs
   2008 have symbol type `N_LSYM' (or `C_DECL' for XCOFF).  (The Sun
   2009 documentation mentions using `N_GSYM' in some cases).
   2010 
   2011    If you are specifying the tag name for a structure, union, or
   2012 enumeration, use the `T' symbol descriptor instead.  I believe C is the
   2013 only language with this feature.
   2014 
   2015    If the type is an opaque type (I believe this is a Modula-2 feature),
   2016 AIX provides a type descriptor to specify it.  The type descriptor is
   2017 `o' and is followed by a name.  I don't know what the name means--is it
   2018 always the same as the name of the type, or is this type descriptor
   2019 used with a nameless stab (*note String Field::)?  There optionally
   2020 follows a comma followed by type information which defines the type of
   2021 this type.  If omitted, a semicolon is used in place of the comma and
   2022 the type information, and the type is much like a generic pointer
   2023 type--it has a known size but little else about it is specified.
   2024 
   2025 
   2026 File: stabs.info,  Node: Unions,  Next: Function Types,  Prev: Typedefs,  Up: Types
   2027 
   2028 5.10 Unions
   2029 ===========
   2030 
   2031      union u_tag {
   2032        int  u_int;
   2033        float u_float;
   2034        char* u_char;
   2035      } an_u;
   2036 
   2037    This code generates a stab for a union tag and a stab for a union
   2038 variable.  Both use the `N_LSYM' stab type.  If a union variable is
   2039 scoped locally to the procedure in which it is defined, its stab is
   2040 located immediately preceding the `N_LBRAC' for the procedure's block
   2041 start.
   2042 
   2043    The stab for the union tag, however, is located preceding the code
   2044 for the procedure in which it is defined.  The stab type is `N_LSYM'.
   2045 This would seem to imply that the union type is file scope, like the
   2046 struct type `s_tag'.  This is not true.  The contents and position of
   2047 the stab for `u_type' do not convey any information about its procedure
   2048 local scope.
   2049 
   2050      # 128 is N_LSYM
   2051      .stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;",
   2052             128,0,0,0
   2053 
   2054    The symbol descriptor `T', following the `name:' means that the stab
   2055 describes an enumeration, structure, or union tag.  The type descriptor
   2056 `u', following the `23=' of the type definition, narrows it down to a
   2057 union type definition.  Following the `u' is the number of bytes in the
   2058 union.  After that is a list of union element descriptions.  Their
   2059 format is `NAME:TYPE, BIT OFFSET INTO THE UNION, NUMBER OF BYTES FOR
   2060 THE ELEMENT;'.
   2061 
   2062    The stab for the union variable is:
   2063 
   2064      .stabs "an_u:23",128,0,0,-20     # 128 is N_LSYM
   2065 
   2066    `-20' specifies where the variable is stored (*note Stack
   2067 Variables::).
   2068 
   2069 
   2070 File: stabs.info,  Node: Function Types,  Prev: Unions,  Up: Types
   2071 
   2072 5.11 Function Types
   2073 ===================
   2074 
   2075 Various types can be defined for function variables.  These types are
   2076 not used in defining functions (*note Procedures::); they are used for
   2077 things like pointers to functions.
   2078 
   2079    The simple, traditional, type is type descriptor `f' is followed by
   2080 type information for the return type of the function, followed by a
   2081 semicolon.
   2082 
   2083    This does not deal with functions for which the number and types of
   2084 the parameters are part of the type, as in Modula-2 or ANSI C.  AIX
   2085 provides extensions to specify these, using the `f', `F', `p', and `R'
   2086 type descriptors.
   2087 
   2088    First comes the type descriptor.  If it is `f' or `F', this type
   2089 involves a function rather than a procedure, and the type information
   2090 for the return type of the function follows, followed by a comma.  Then
   2091 comes the number of parameters to the function and a semicolon.  Then,
   2092 for each parameter, there is the name of the parameter followed by a
   2093 colon (this is only present for type descriptors `R' and `F' which
   2094 represent Pascal function or procedure parameters), type information
   2095 for the parameter, a comma, 0 if passed by reference or 1 if passed by
   2096 value, and a semicolon.  The type definition ends with a semicolon.
   2097 
   2098    For example, this variable definition:
   2099 
   2100      int (*g_pf)();
   2101 
   2102 generates the following code:
   2103 
   2104      .stabs "g_pf:G24=*25=f1",32,0,0,0
   2105          .common _g_pf,4,"bss"
   2106 
   2107    The variable defines a new type, 24, which is a pointer to another
   2108 new type, 25, which is a function returning `int'.
   2109 
   2110 
   2111 File: stabs.info,  Node: Macro define and undefine,  Next: Symbol Tables,  Prev: Types,  Up: Top
   2112 
   2113 6 Representation of #define and #undef
   2114 **************************************
   2115 
   2116 This section describes the stabs support for macro define and undefine
   2117 information, supported on some systems.  (e.g., with `-g3' `-gstabs'
   2118 when using GCC).
   2119 
   2120    A `#define MACRO-NAME MACRO-BODY' is represented with an
   2121 `N_MAC_DEFINE' stab with a string field of `MACRO-NAME MACRO-BODY'.  
   2122 
   2123    An `#undef MACRO-NAME' is represented with an `N_MAC_UNDEF' stabs
   2124 with a string field of simply `MACRO-NAME'.  
   2125 
   2126    For both `N_MAC_DEFINE' and `N_MAC_UNDEF', the desc field is the
   2127 line number within the file where the corresponding `#define' or
   2128 `#undef' occurred.
   2129 
   2130    For example, the following C code:
   2131 
   2132          #define NONE	42
   2133          #define TWO(a, b)	(a + (a) + 2 * b)
   2134          #define ONE(c)	(c + 19)
   2135 
   2136          main(int argc, char *argv[])
   2137          {
   2138            func(NONE, TWO(10, 11));
   2139            func(NONE, ONE(23));
   2140 
   2141          #undef ONE
   2142          #define ONE(c)	(c + 23)
   2143 
   2144            func(NONE, ONE(-23));
   2145 
   2146            return (0);
   2147          }
   2148 
   2149          int global;
   2150 
   2151          func(int arg1, int arg2)
   2152          {
   2153            global = arg1 + arg2;
   2154          }
   2155 
   2156 produces the following stabs (as well as many others):
   2157 
   2158          .stabs	"NONE 42",54,0,1,0
   2159          .stabs	"TWO(a,b) (a + (a) + 2 * b)",54,0,2,0
   2160          .stabs	"ONE(c) (c + 19)",54,0,3,0
   2161          .stabs	"ONE",58,0,10,0
   2162          .stabs	"ONE(c) (c + 23)",54,0,11,0
   2163 
   2164 NOTE: In the above example, `54' is `N_MAC_DEFINE' and `58' is
   2165 `N_MAC_UNDEF'.
   2166 
   2167 
   2168 File: stabs.info,  Node: Symbol Tables,  Next: Cplusplus,  Prev: Macro define and undefine,  Up: Top
   2169 
   2170 7 Symbol Information in Symbol Tables
   2171 *************************************
   2172 
   2173 This chapter describes the format of symbol table entries and how stab
   2174 assembler directives map to them.  It also describes the
   2175 transformations that the assembler and linker make on data from stabs.
   2176 
   2177 * Menu:
   2178 
   2179 * Symbol Table Format::
   2180 * Transformations On Symbol Tables::
   2181 
   2182 
   2183 File: stabs.info,  Node: Symbol Table Format,  Next: Transformations On Symbol Tables,  Up: Symbol Tables
   2184 
   2185 7.1 Symbol Table Format
   2186 =======================
   2187 
   2188 Each time the assembler encounters a stab directive, it puts each field
   2189 of the stab into a corresponding field in a symbol table entry of its
   2190 output file.  If the stab contains a string field, the symbol table
   2191 entry for that stab points to a string table entry containing the
   2192 string data from the stab.  Assembler labels become relocatable
   2193 addresses.  Symbol table entries in a.out have the format:
   2194 
   2195      struct internal_nlist {
   2196        unsigned long n_strx;         /* index into string table of name */
   2197        unsigned char n_type;         /* type of symbol */
   2198        unsigned char n_other;        /* misc info (usually empty) */
   2199        unsigned short n_desc;        /* description field */
   2200        bfd_vma n_value;              /* value of symbol */
   2201      };
   2202 
   2203    If the stab has a string, the `n_strx' field holds the offset in
   2204 bytes of the string within the string table.  The string is terminated
   2205 by a NUL character.  If the stab lacks a string (for example, it was
   2206 produced by a `.stabn' or `.stabd' directive), the `n_strx' field is
   2207 zero.
   2208 
   2209    Symbol table entries with `n_type' field values greater than 0x1f
   2210 originated as stabs generated by the compiler (with one random
   2211 exception).  The other entries were placed in the symbol table of the
   2212 executable by the assembler or the linker.
   2213 
   2214 
   2215 File: stabs.info,  Node: Transformations On Symbol Tables,  Prev: Symbol Table Format,  Up: Symbol Tables
   2216 
   2217 7.2 Transformations on Symbol Tables
   2218 ====================================
   2219 
   2220 The linker concatenates object files and does fixups of externally
   2221 defined symbols.
   2222 
   2223    You can see the transformations made on stab data by the assembler
   2224 and linker by examining the symbol table after each pass of the build.
   2225 To do this, use `nm -ap', which dumps the symbol table, including
   2226 debugging information, unsorted.  For stab entries the columns are:
   2227 VALUE, OTHER, DESC, TYPE, STRING.  For assembler and linker symbols,
   2228 the columns are: VALUE, TYPE, STRING.
   2229 
   2230    The low 5 bits of the stab type tell the linker how to relocate the
   2231 value of the stab.  Thus for stab types like `N_RSYM' and `N_LSYM',
   2232 where the value is an offset or a register number, the low 5 bits are
   2233 `N_ABS', which tells the linker not to relocate the value.
   2234 
   2235    Where the value of a stab contains an assembly language label, it is
   2236 transformed by each build step.  The assembler turns it into a
   2237 relocatable address and the linker turns it into an absolute address.
   2238 
   2239 * Menu:
   2240 
   2241 * Transformations On Static Variables::
   2242 * Transformations On Global Variables::
   2243 * Stab Section Transformations::	   For some object file formats,
   2244                                            things are a bit different.
   2245 
   2246 
   2247 File: stabs.info,  Node: Transformations On Static Variables,  Next: Transformations On Global Variables,  Up: Transformations On Symbol Tables
   2248 
   2249 7.2.1 Transformations on Static Variables
   2250 -----------------------------------------
   2251 
   2252 This source line defines a static variable at file scope:
   2253 
   2254      static int s_g_repeat
   2255 
   2256 The following stab describes the symbol:
   2257 
   2258      .stabs "s_g_repeat:S1",38,0,0,_s_g_repeat
   2259 
   2260 The assembler transforms the stab into this symbol table entry in the
   2261 `.o' file.  The location is expressed as a data segment offset.
   2262 
   2263      00000084 - 00 0000 STSYM s_g_repeat:S1
   2264 
   2265 In the symbol table entry from the executable, the linker has made the
   2266 relocatable address absolute.
   2267 
   2268      0000e00c - 00 0000 STSYM s_g_repeat:S1
   2269 
   2270 
   2271 File: stabs.info,  Node: Transformations On Global Variables,  Next: Stab Section Transformations,  Prev: Transformations On Static Variables,  Up: Transformations On Symbol Tables
   2272 
   2273 7.2.2 Transformations on Global Variables
   2274 -----------------------------------------
   2275 
   2276 Stabs for global variables do not contain location information. In this
   2277 case, the debugger finds location information in the assembler or
   2278 linker symbol table entry describing the variable.  The source line:
   2279 
   2280      char g_foo = 'c';
   2281 
   2282 generates the stab:
   2283 
   2284      .stabs "g_foo:G2",32,0,0,0
   2285 
   2286    The variable is represented by two symbol table entries in the object
   2287 file (see below).  The first one originated as a stab.  The second one
   2288 is an external symbol.  The upper case `D' signifies that the `n_type'
   2289 field of the symbol table contains 7, `N_DATA' with local linkage.  The
   2290 stab's value is zero since the value is not used for `N_GSYM' stabs.
   2291 The value of the linker symbol is the relocatable address corresponding
   2292 to the variable.
   2293 
   2294      00000000 - 00 0000  GSYM g_foo:G2
   2295      00000080 D _g_foo
   2296 
   2297 These entries as transformed by the linker.  The linker symbol table
   2298 entry now holds an absolute address:
   2299 
   2300      00000000 - 00 0000  GSYM g_foo:G2
   2301      ...
   2302      0000e008 D _g_foo
   2303 
   2304 
   2305 File: stabs.info,  Node: Stab Section Transformations,  Prev: Transformations On Global Variables,  Up: Transformations On Symbol Tables
   2306 
   2307 7.2.3 Transformations of Stabs in separate sections
   2308 ---------------------------------------------------
   2309 
   2310 For object file formats using stabs in separate sections (*note Stab
   2311 Sections::), use `objdump --stabs' instead of `nm' to show the stabs in
   2312 an object or executable file.  `objdump' is a GNU utility; Sun does not
   2313 provide any equivalent.
   2314 
   2315    The following example is for a stab whose value is an address is
   2316 relative to the compilation unit (*note ELF Linker Relocation::).  For
   2317 example, if the source line
   2318 
   2319      static int ld = 5;
   2320 
   2321    appears within a function, then the assembly language output from the
   2322 compiler contains:
   2323 
   2324      .Ddata.data:
   2325      ...
   2326              .stabs "ld:V(0,3)",0x26,0,4,.L18-Ddata.data    # 0x26 is N_STSYM
   2327      ...
   2328      .L18:
   2329              .align 4
   2330              .word 0x5
   2331 
   2332    Because the value is formed by subtracting one symbol from another,
   2333 the value is absolute, not relocatable, and so the object file contains
   2334 
   2335      Symnum n_type n_othr n_desc n_value  n_strx String
   2336      31     STSYM  0      4      00000004 680    ld:V(0,3)
   2337 
   2338    without any relocations, and the executable file also contains
   2339 
   2340      Symnum n_type n_othr n_desc n_value  n_strx String
   2341      31     STSYM  0      4      00000004 680    ld:V(0,3)
   2342 
   2343 
   2344 File: stabs.info,  Node: Cplusplus,  Next: Stab Types,  Prev: Symbol Tables,  Up: Top
   2345 
   2346 8 GNU C++ Stabs
   2347 ***************
   2348 
   2349 * Menu:
   2350 
   2351 * Class Names::			C++ class names are both tags and typedefs.
   2352 * Nested Symbols::		C++ symbol names can be within other types.
   2353 * Basic Cplusplus Types::
   2354 * Simple Classes::
   2355 * Class Instance::
   2356 * Methods::			Method definition
   2357 * Method Type Descriptor::      The `#' type descriptor
   2358 * Member Type Descriptor::      The `@' type descriptor
   2359 * Protections::
   2360 * Method Modifiers::
   2361 * Virtual Methods::
   2362 * Inheritance::
   2363 * Virtual Base Classes::
   2364 * Static Members::
   2365 
   2366 
   2367 File: stabs.info,  Node: Class Names,  Next: Nested Symbols,  Up: Cplusplus
   2368 
   2369 8.1 C++ Class Names
   2370 ===================
   2371 
   2372 In C++, a class name which is declared with `class', `struct', or
   2373 `union', is not only a tag, as in C, but also a type name.  Thus there
   2374 should be stabs with both `t' and `T' symbol descriptors (*note
   2375 Typedefs::).
   2376 
   2377    To save space, there is a special abbreviation for this case.  If the
   2378 `T' symbol descriptor is followed by `t', then the stab defines both a
   2379 type name and a tag.
   2380 
   2381    For example, the C++ code
   2382 
   2383      struct foo {int x;};
   2384 
   2385    can be represented as either
   2386 
   2387      .stabs "foo:T19=s4x:1,0,32;;",128,0,0,0       # 128 is N_LSYM
   2388      .stabs "foo:t19",128,0,0,0
   2389 
   2390    or
   2391 
   2392      .stabs "foo:Tt19=s4x:1,0,32;;",128,0,0,0
   2393 
   2394 
   2395 File: stabs.info,  Node: Nested Symbols,  Next: Basic Cplusplus Types,  Prev: Class Names,  Up: Cplusplus
   2396 
   2397 8.2 Defining a Symbol Within Another Type
   2398 =========================================
   2399 
   2400 In C++, a symbol (such as a type name) can be defined within another
   2401 type.
   2402 
   2403    In stabs, this is sometimes represented by making the name of a
   2404 symbol which contains `::'.  Such a pair of colons does not end the name
   2405 of the symbol, the way a single colon would (*note String Field::).  I'm
   2406 not sure how consistently used or well thought out this mechanism is.
   2407 So that a pair of colons in this position always has this meaning, `:'
   2408 cannot be used as a symbol descriptor.
   2409 
   2410    For example, if the string for a stab is `foo::bar::baz:t5=*6', then
   2411 `foo::bar::baz' is the name of the symbol, `t' is the symbol
   2412 descriptor, and `5=*6' is the type information.
   2413 
   2414 
   2415 File: stabs.info,  Node: Basic Cplusplus Types,  Next: Simple Classes,  Prev: Nested Symbols,  Up: Cplusplus
   2416 
   2417 8.3 Basic Types For C++
   2418 =======================
   2419 
   2420 << the examples that follow are based on a01.C >>
   2421 
   2422    C++ adds two more builtin types to the set defined for C.  These are
   2423 the unknown type and the vtable record type.  The unknown type, type
   2424 16, is defined in terms of itself like the void type.
   2425 
   2426    The vtable record type, type 17, is defined as a structure type and
   2427 then as a structure tag.  The structure has four fields: delta, index,
   2428 pfn, and delta2.  pfn is the function pointer.
   2429 
   2430    << In boilerplate $vtbl_ptr_type, what are the fields delta, index,
   2431 and delta2 used for? >>
   2432 
   2433    This basic type is present in all C++ programs even if there are no
   2434 virtual methods defined.
   2435 
   2436      .stabs "struct_name:sym_desc(type)type_def(17)=type_desc(struct)struct_bytes(8)
   2437              elem_name(delta):type_ref(short int),bit_offset(0),field_bits(16);
   2438              elem_name(index):type_ref(short int),bit_offset(16),field_bits(16);
   2439              elem_name(pfn):type_def(18)=type_desc(ptr to)type_ref(void),
   2440                                          bit_offset(32),field_bits(32);
   2441              elem_name(delta2):type_def(short int);bit_offset(32),field_bits(16);;"
   2442              N_LSYM, NIL, NIL
   2443 
   2444      .stabs "$vtbl_ptr_type:t17=s8
   2445              delta:6,0,16;index:6,16,16;pfn:18=*15,32,32;delta2:6,32,16;;"
   2446              ,128,0,0,0
   2447 
   2448      .stabs "name:sym_dec(struct tag)type_ref($vtbl_ptr_type)",N_LSYM,NIL,NIL,NIL
   2449 
   2450      .stabs "$vtbl_ptr_type:T17",128,0,0,0
   2451 
   2452 
   2453 File: stabs.info,  Node: Simple Classes,  Next: Class Instance,  Prev: Basic Cplusplus Types,  Up: Cplusplus
   2454 
   2455 8.4 Simple Class Definition
   2456 ===========================
   2457 
   2458 The stabs describing C++ language features are an extension of the
   2459 stabs describing C.  Stabs representing C++ class types elaborate
   2460 extensively on the stab format used to describe structure types in C.
   2461 Stabs representing class type variables look just like stabs
   2462 representing C language variables.
   2463 
   2464    Consider the following very simple class definition.
   2465 
   2466      class baseA {
   2467      public:
   2468              int Adat;
   2469              int Ameth(int in, char other);
   2470      };
   2471 
   2472    The class `baseA' is represented by two stabs.  The first stab
   2473 describes the class as a structure type.  The second stab describes a
   2474 structure tag of the class type.  Both stabs are of stab type `N_LSYM'.
   2475 Since the stab is not located between an `N_FUN' and an `N_LBRAC' stab
   2476 this indicates that the class is defined at file scope.  If it were,
   2477 then the `N_LSYM' would signify a local variable.
   2478 
   2479    A stab describing a C++ class type is similar in format to a stab
   2480 describing a C struct, with each class member shown as a field in the
   2481 structure.  The part of the struct format describing fields is expanded
   2482 to include extra information relevant to C++ class members.  In
   2483 addition, if the class has multiple base classes or virtual functions
   2484 the struct format outside of the field parts is also augmented.
   2485 
   2486    In this simple example the field part of the C++ class stab
   2487 representing member data looks just like the field part of a C struct
   2488 stab.  The section on protections describes how its format is sometimes
   2489 extended for member data.
   2490 
   2491    The field part of a C++ class stab representing a member function
   2492 differs substantially from the field part of a C struct stab.  It still
   2493 begins with `name:' but then goes on to define a new type number for
   2494 the member function, describe its return type, its argument types, its
   2495 protection level, any qualifiers applied to the method definition, and
   2496 whether the method is virtual or not.  If the method is virtual then
   2497 the method description goes on to give the vtable index of the method,
   2498 and the type number of the first base class defining the method.
   2499 
   2500    When the field name is a method name it is followed by two colons
   2501 rather than one.  This is followed by a new type definition for the
   2502 method.  This is a number followed by an equal sign and the type of the
   2503 method.  Normally this will be a type declared using the `#' type
   2504 descriptor; see *note Method Type Descriptor::; static member functions
   2505 are declared using the `f' type descriptor instead; see *note Function
   2506 Types::.
   2507 
   2508    The format of an overloaded operator method name differs from that of
   2509 other methods.  It is `op$::OPERATOR-NAME.' where OPERATOR-NAME is the
   2510 operator name such as `+' or `+='.  The name ends with a period, and
   2511 any characters except the period can occur in the OPERATOR-NAME string.
   2512 
   2513    The next part of the method description represents the arguments to
   2514 the method, preceded by a colon and ending with a semi-colon.  The
   2515 types of the arguments are expressed in the same way argument types are
   2516 expressed in C++ name mangling.  In this example an `int' and a `char'
   2517 map to `ic'.
   2518 
   2519    This is followed by a number, a letter, and an asterisk or period,
   2520 followed by another semicolon.  The number indicates the protections
   2521 that apply to the member function.  Here the 2 means public.  The
   2522 letter encodes any qualifier applied to the method definition.  In this
   2523 case, `A' means that it is a normal function definition.  The dot shows
   2524 that the method is not virtual.  The sections that follow elaborate
   2525 further on these fields and describe the additional information present
   2526 for virtual methods.
   2527 
   2528      .stabs "class_name:sym_desc(type)type_def(20)=type_desc(struct)struct_bytes(4)
   2529              field_name(Adat):type(int),bit_offset(0),field_bits(32);
   2530 
   2531              method_name(Ameth)::type_def(21)=type_desc(method)return_type(int);
   2532              :arg_types(int char);
   2533              protection(public)qualifier(normal)virtual(no);;"
   2534              N_LSYM,NIL,NIL,NIL
   2535 
   2536      .stabs "baseA:t20=s4Adat:1,0,32;Ameth::21=##1;:ic;2A.;;",128,0,0,0
   2537 
   2538      .stabs "class_name:sym_desc(struct tag)",N_LSYM,NIL,NIL,NIL
   2539 
   2540      .stabs "baseA:T20",128,0,0,0
   2541 
   2542 
   2543 File: stabs.info,  Node: Class Instance,  Next: Methods,  Prev: Simple Classes,  Up: Cplusplus
   2544 
   2545 8.5 Class Instance
   2546 ==================
   2547 
   2548 As shown above, describing even a simple C++ class definition is
   2549 accomplished by massively extending the stab format used in C to
   2550 describe structure types.  However, once the class is defined, C stabs
   2551 with no modifications can be used to describe class instances.  The
   2552 following source:
   2553 
   2554      main () {
   2555              baseA AbaseA;
   2556      }
   2557 
   2558 yields the following stab describing the class instance.  It looks no
   2559 different from a standard C stab describing a local variable.
   2560 
   2561      .stabs "name:type_ref(baseA)", N_LSYM, NIL, NIL, frame_ptr_offset
   2562 
   2563      .stabs "AbaseA:20",128,0,0,-20
   2564 
   2565 
   2566 File: stabs.info,  Node: Methods,  Next: Method Type Descriptor,  Prev: Class Instance,  Up: Cplusplus
   2567 
   2568 8.6 Method Definition
   2569 =====================
   2570 
   2571 The class definition shown above declares Ameth.  The C++ source below
   2572 defines Ameth:
   2573 
   2574      int
   2575      baseA::Ameth(int in, char other)
   2576      {
   2577              return in;
   2578      };
   2579 
   2580    This method definition yields three stabs following the code of the
   2581 method.  One stab describes the method itself and following two describe
   2582 its parameters.  Although there is only one formal argument all methods
   2583 have an implicit argument which is the `this' pointer.  The `this'
   2584 pointer is a pointer to the object on which the method was called.  Note
   2585 that the method name is mangled to encode the class name and argument
   2586 types.  Name mangling is described in the ARM (`The Annotated C++
   2587 Reference Manual', by Ellis and Stroustrup, ISBN 0-201-51459-1);
   2588 `gpcompare.texi' in Cygnus GCC distributions describes the differences
   2589 between GNU mangling and ARM mangling.
   2590 
   2591      .stabs "name:symbol_descriptor(global function)return_type(int)",
   2592              N_FUN, NIL, NIL, code_addr_of_method_start
   2593 
   2594      .stabs "Ameth__5baseAic:F1",36,0,0,_Ameth__5baseAic
   2595 
   2596    Here is the stab for the `this' pointer implicit argument.  The name
   2597 of the `this' pointer is always `this'.  Type 19, the `this' pointer is
   2598 defined as a pointer to type 20, `baseA', but a stab defining `baseA'
   2599 has not yet been emitted.  Since the compiler knows it will be emitted
   2600 shortly, here it just outputs a cross reference to the undefined
   2601 symbol, by prefixing the symbol name with `xs'.
   2602 
   2603      .stabs "name:sym_desc(register param)type_def(19)=
   2604              type_desc(ptr to)type_ref(baseA)=
   2605              type_desc(cross-reference to)baseA:",N_RSYM,NIL,NIL,register_number
   2606 
   2607      .stabs "this:P19=*20=xsbaseA:",64,0,0,8
   2608 
   2609    The stab for the explicit integer argument looks just like a
   2610 parameter to a C function.  The last field of the stab is the offset
   2611 from the argument pointer, which in most systems is the same as the
   2612 frame pointer.
   2613 
   2614      .stabs "name:sym_desc(value parameter)type_ref(int)",
   2615              N_PSYM,NIL,NIL,offset_from_arg_ptr
   2616 
   2617      .stabs "in:p1",160,0,0,72
   2618 
   2619    << The examples that follow are based on A1.C >>
   2620 
   2621 
   2622 File: stabs.info,  Node: Method Type Descriptor,  Next: Member Type Descriptor,  Prev: Methods,  Up: Cplusplus
   2623 
   2624 8.7 The `#' Type Descriptor
   2625 ===========================
   2626 
   2627 This is used to describe a class method.  This is a function which takes
   2628 an extra argument as its first argument, for the `this' pointer.
   2629 
   2630    If the `#' is immediately followed by another `#', the second one
   2631 will be followed by the return type and a semicolon.  The class and
   2632 argument types are not specified, and must be determined by demangling
   2633 the name of the method if it is available.
   2634 
   2635    Otherwise, the single `#' is followed by the class type, a comma,
   2636 the return type, a comma, and zero or more parameter types separated by
   2637 commas.  The list of arguments is terminated by a semicolon.  In the
   2638 debugging output generated by gcc, a final argument type of `void'
   2639 indicates a method which does not take a variable number of arguments.
   2640 If the final argument type of `void' does not appear, the method was
   2641 declared with an ellipsis.
   2642 
   2643    Note that although such a type will normally be used to describe
   2644 fields in structures, unions, or classes, for at least some versions of
   2645 the compiler it can also be used in other contexts.
   2646 
   2647 
   2648 File: stabs.info,  Node: Member Type Descriptor,  Next: Protections,  Prev: Method Type Descriptor,  Up: Cplusplus
   2649 
   2650 8.8 The `@' Type Descriptor
   2651 ===========================
   2652 
   2653 The `@' type descriptor is used for a pointer-to-non-static-member-data
   2654 type.  It is followed by type information for the class (or union), a
   2655 comma, and type information for the member data.
   2656 
   2657    The following C++ source:
   2658 
   2659      typedef int A::*int_in_a;
   2660 
   2661    generates the following stab:
   2662 
   2663      .stabs "int_in_a:t20=21=@19,1",128,0,0,0
   2664 
   2665    Note that there is a conflict between this and type attributes
   2666 (*note String Field::); both use type descriptor `@'.  Fortunately, the
   2667 `@' type descriptor used in this C++ sense always will be followed by a
   2668 digit, `(', or `-', and type attributes never start with those things.
   2669 
   2670 
   2671 File: stabs.info,  Node: Protections,  Next: Method Modifiers,  Prev: Member Type Descriptor,  Up: Cplusplus
   2672 
   2673 8.9 Protections
   2674 ===============
   2675 
   2676 In the simple class definition shown above all member data and
   2677 functions were publicly accessible.  The example that follows contrasts
   2678 public, protected and privately accessible fields and shows how these
   2679 protections are encoded in C++ stabs.
   2680 
   2681    If the character following the `FIELD-NAME:' part of the string is
   2682 `/', then the next character is the visibility.  `0' means private, `1'
   2683 means protected, and `2' means public.  Debuggers should ignore
   2684 visibility characters they do not recognize, and assume a reasonable
   2685 default (such as public) (GDB 4.11 does not, but this should be fixed
   2686 in the next GDB release).  If no visibility is specified the field is
   2687 public.  The visibility `9' means that the field has been optimized out
   2688 and is public (there is no way to specify an optimized out field with a
   2689 private or protected visibility).  Visibility `9' is not supported by
   2690 GDB 4.11; this should be fixed in the next GDB release.
   2691 
   2692    The following C++ source:
   2693 
   2694      class vis {
   2695      private:
   2696              int   priv;
   2697      protected:
   2698              char  prot;
   2699      public:
   2700              float pub;
   2701      };
   2702 
   2703 generates the following stab:
   2704 
   2705      # 128 is N_LSYM
   2706      .stabs "vis:T19=s12priv:/01,0,32;prot:/12,32,8;pub:12,64,32;;",128,0,0,0
   2707 
   2708    `vis:T19=s12' indicates that type number 19 is a 12 byte structure
   2709 named `vis' The `priv' field has public visibility (`/0'), type int
   2710 (`1'), and offset and size `,0,32;'.  The `prot' field has protected
   2711 visibility (`/1'), type char (`2') and offset and size `,32,8;'.  The
   2712 `pub' field has type float (`12'), and offset and size `,64,32;'.
   2713 
   2714    Protections for member functions are signified by one digit embedded
   2715 in the field part of the stab describing the method.  The digit is 0 if
   2716 private, 1 if protected and 2 if public.  Consider the C++ class
   2717 definition below:
   2718 
   2719      class all_methods {
   2720      private:
   2721              int   priv_meth(int in){return in;};
   2722      protected:
   2723              char  protMeth(char in){return in;};
   2724      public:
   2725              float pubMeth(float in){return in;};
   2726      };
   2727 
   2728    It generates the following stab.  The digit in question is to the
   2729 left of an `A' in each case.  Notice also that in this case two symbol
   2730 descriptors apply to the class name struct tag and struct type.
   2731 
   2732      .stabs "class_name:sym_desc(struct tag&type)type_def(21)=
   2733              sym_desc(struct)struct_bytes(1)
   2734              meth_name::type_def(22)=sym_desc(method)returning(int);
   2735              :args(int);protection(private)modifier(normal)virtual(no);
   2736              meth_name::type_def(23)=sym_desc(method)returning(char);
   2737              :args(char);protection(protected)modifier(normal)virtual(no);
   2738              meth_name::type_def(24)=sym_desc(method)returning(float);
   2739              :args(float);protection(public)modifier(normal)virtual(no);;",
   2740              N_LSYM,NIL,NIL,NIL
   2741 
   2742      .stabs "all_methods:Tt21=s1priv_meth::22=##1;:i;0A.;protMeth::23=##2;:c;1A.;
   2743              pubMeth::24=##12;:f;2A.;;",128,0,0,0
   2744 
   2745 
   2746 File: stabs.info,  Node: Method Modifiers,  Next: Virtual Methods,  Prev: Protections,  Up: Cplusplus
   2747 
   2748 8.10 Method Modifiers (`const', `volatile', `const volatile')
   2749 =============================================================
   2750 
   2751 << based on a6.C >>
   2752 
   2753    In the class example described above all the methods have the normal
   2754 modifier.  This method modifier information is located just after the
   2755 protection information for the method.  This field has four possible
   2756 character values.  Normal methods use `A', const methods use `B',
   2757 volatile methods use `C', and const volatile methods use `D'.  Consider
   2758 the class definition below:
   2759 
   2760      class A {
   2761      public:
   2762              int ConstMeth (int arg) const { return arg; };
   2763              char VolatileMeth (char arg) volatile { return arg; };
   2764              float ConstVolMeth (float arg) const volatile {return arg; };
   2765      };
   2766 
   2767    This class is described by the following stab:
   2768 
   2769      .stabs "class(A):sym_desc(struct)type_def(20)=type_desc(struct)struct_bytes(1)
   2770              meth_name(ConstMeth)::type_def(21)sym_desc(method)
   2771              returning(int);:arg(int);protection(public)modifier(const)virtual(no);
   2772              meth_name(VolatileMeth)::type_def(22)=sym_desc(method)
   2773              returning(char);:arg(char);protection(public)modifier(volatile)virt(no)
   2774              meth_name(ConstVolMeth)::type_def(23)=sym_desc(method)
   2775              returning(float);:arg(float);protection(public)modifier(const volatile)
   2776              virtual(no);;", ...
   2777 
   2778      .stabs "A:T20=s1ConstMeth::21=##1;:i;2B.;VolatileMeth::22=##2;:c;2C.;
   2779                   ConstVolMeth::23=##12;:f;2D.;;",128,0,0,0
   2780 
   2781 
   2782 File: stabs.info,  Node: Virtual Methods,  Next: Inheritance,  Prev: Method Modifiers,  Up: Cplusplus
   2783 
   2784 8.11 Virtual Methods
   2785 ====================
   2786 
   2787 << The following examples are based on a4.C >>
   2788 
   2789    The presence of virtual methods in a class definition adds additional
   2790 data to the class description.  The extra data is appended to the
   2791 description of the virtual method and to the end of the class
   2792 description.  Consider the class definition below:
   2793 
   2794      class A {
   2795      public:
   2796              int Adat;
   2797              virtual int A_virt (int arg) { return arg; };
   2798      };
   2799 
   2800    This results in the stab below describing class A.  It defines a new
   2801 type (20) which is an 8 byte structure.  The first field of the class
   2802 struct is `Adat', an integer, starting at structure offset 0 and
   2803 occupying 32 bits.
   2804 
   2805    The second field in the class struct is not explicitly defined by the
   2806 C++ class definition but is implied by the fact that the class contains
   2807 a virtual method.  This field is the vtable pointer.  The name of the
   2808 vtable pointer field starts with `$vf' and continues with a type
   2809 reference to the class it is part of.  In this example the type
   2810 reference for class A is 20 so the name of its vtable pointer field is
   2811 `$vf20', followed by the usual colon.
   2812 
   2813    Next there is a type definition for the vtable pointer type (21).
   2814 This is in turn defined as a pointer to another new type (22).
   2815 
   2816    Type 22 is the vtable itself, which is defined as an array, indexed
   2817 by a range of integers between 0 and 1, and whose elements are of type
   2818 17.  Type 17 was the vtable record type defined by the boilerplate C++
   2819 type definitions, as shown earlier.
   2820 
   2821    The bit offset of the vtable pointer field is 32.  The number of bits
   2822 in the field are not specified when the field is a vtable pointer.
   2823 
   2824    Next is the method definition for the virtual member function
   2825 `A_virt'.  Its description starts out using the same format as the
   2826 non-virtual member functions described above, except instead of a dot
   2827 after the `A' there is an asterisk, indicating that the function is
   2828 virtual.  Since is is virtual some addition information is appended to
   2829 the end of the method description.
   2830 
   2831    The first number represents the vtable index of the method.  This is
   2832 a 32 bit unsigned number with the high bit set, followed by a
   2833 semi-colon.
   2834 
   2835    The second number is a type reference to the first base class in the
   2836 inheritance hierarchy defining the virtual member function.  In this
   2837 case the class stab describes a base class so the virtual function is
   2838 not overriding any other definition of the method.  Therefore the
   2839 reference is to the type number of the class that the stab is
   2840 describing (20).
   2841 
   2842    This is followed by three semi-colons.  One marks the end of the
   2843 current sub-section, one marks the end of the method field, and the
   2844 third marks the end of the struct definition.
   2845 
   2846    For classes containing virtual functions the very last section of the
   2847 string part of the stab holds a type reference to the first base class.
   2848 This is preceded by `~%' and followed by a final semi-colon.
   2849 
   2850      .stabs "class_name(A):type_def(20)=sym_desc(struct)struct_bytes(8)
   2851              field_name(Adat):type_ref(int),bit_offset(0),field_bits(32);
   2852              field_name(A virt func ptr):type_def(21)=type_desc(ptr to)type_def(22)=
   2853              sym_desc(array)index_type_ref(range of int from 0 to 1);
   2854              elem_type_ref(vtbl elem type),
   2855              bit_offset(32);
   2856              meth_name(A_virt)::typedef(23)=sym_desc(method)returning(int);
   2857              :arg_type(int),protection(public)normal(yes)virtual(yes)
   2858              vtable_index(1);class_first_defining(A);;;~%first_base(A);",
   2859              N_LSYM,NIL,NIL,NIL
   2860 
   2861      .stabs "A:t20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;
   2862              A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
   2863 
   2864 
   2865 File: stabs.info,  Node: Inheritance,  Next: Virtual Base Classes,  Prev: Virtual Methods,  Up: Cplusplus
   2866 
   2867 8.12 Inheritance
   2868 ================
   2869 
   2870 Stabs describing C++ derived classes include additional sections that
   2871 describe the inheritance hierarchy of the class.  A derived class stab
   2872 also encodes the number of base classes.  For each base class it tells
   2873 if the base class is virtual or not, and if the inheritance is private
   2874 or public.  It also gives the offset into the object of the portion of
   2875 the object corresponding to each base class.
   2876 
   2877    This additional information is embedded in the class stab following
   2878 the number of bytes in the struct.  First the number of base classes
   2879 appears bracketed by an exclamation point and a comma.
   2880 
   2881    Then for each base type there repeats a series: a virtual character,
   2882 a visibility character, a number, a comma, another number, and a
   2883 semi-colon.
   2884 
   2885    The virtual character is `1' if the base class is virtual and `0' if
   2886 not.  The visibility character is `2' if the derivation is public, `1'
   2887 if it is protected, and `0' if it is private.  Debuggers should ignore
   2888 virtual or visibility characters they do not recognize, and assume a
   2889 reasonable default (such as public and non-virtual) (GDB 4.11 does not,
   2890 but this should be fixed in the next GDB release).
   2891 
   2892    The number following the virtual and visibility characters is the
   2893 offset from the start of the object to the part of the object
   2894 pertaining to the base class.
   2895 
   2896    After the comma, the second number is a type_descriptor for the base
   2897 type.  Finally a semi-colon ends the series, which repeats for each
   2898 base class.
   2899 
   2900    The source below defines three base classes `A', `B', and `C' and
   2901 the derived class `D'.
   2902 
   2903      class A {
   2904      public:
   2905              int Adat;
   2906              virtual int A_virt (int arg) { return arg; };
   2907      };
   2908 
   2909      class B {
   2910      public:
   2911              int B_dat;
   2912              virtual int B_virt (int arg) {return arg; };
   2913      };
   2914 
   2915      class C {
   2916      public:
   2917              int Cdat;
   2918              virtual int C_virt (int arg) {return arg; };
   2919      };
   2920 
   2921      class D : A, virtual B, public C {
   2922      public:
   2923              int Ddat;
   2924              virtual int A_virt (int arg ) { return arg+1; };
   2925              virtual int B_virt (int arg)  { return arg+2; };
   2926              virtual int C_virt (int arg)  { return arg+3; };
   2927              virtual int D_virt (int arg)  { return arg; };
   2928      };
   2929 
   2930    Class stabs similar to the ones described earlier are generated for
   2931 each base class.
   2932 
   2933      .stabs "A:T20=s8Adat:1,0,32;$vf20:21=*22=ar1;0;1;17,32;
   2934              A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
   2935 
   2936      .stabs "B:Tt25=s8Bdat:1,0,32;$vf25:21,32;B_virt::26=##1;
   2937              :i;2A*-2147483647;25;;;~%25;",128,0,0,0
   2938 
   2939      .stabs "C:Tt28=s8Cdat:1,0,32;$vf28:21,32;C_virt::29=##1;
   2940              :i;2A*-2147483647;28;;;~%28;",128,0,0,0
   2941 
   2942    In the stab describing derived class `D' below, the information about
   2943 the derivation of this class is encoded as follows.
   2944 
   2945      .stabs "derived_class_name:symbol_descriptors(struct tag&type)=
   2946              type_descriptor(struct)struct_bytes(32)!num_bases(3),
   2947              base_virtual(no)inheritance_public(no)base_offset(0),
   2948              base_class_type_ref(A);
   2949              base_virtual(yes)inheritance_public(no)base_offset(NIL),
   2950              base_class_type_ref(B);
   2951              base_virtual(no)inheritance_public(yes)base_offset(64),
   2952              base_class_type_ref(C); ...
   2953 
   2954      .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:
   2955              1,160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt:
   2956              :32:i;2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;
   2957              28;;D_virt::32:i;2A*-2147483646;31;;;~%20;",128,0,0,0
   2958 
   2959 
   2960 File: stabs.info,  Node: Virtual Base Classes,  Next: Static Members,  Prev: Inheritance,  Up: Cplusplus
   2961 
   2962 8.13 Virtual Base Classes
   2963 =========================
   2964 
   2965 A derived class object consists of a concatenation in memory of the data
   2966 areas defined by each base class, starting with the leftmost and ending
   2967 with the rightmost in the list of base classes.  The exception to this
   2968 rule is for virtual inheritance.  In the example above, class `D'
   2969 inherits virtually from base class `B'.  This means that an instance of
   2970 a `D' object will not contain its own `B' part but merely a pointer to
   2971 a `B' part, known as a virtual base pointer.
   2972 
   2973    In a derived class stab, the base offset part of the derivation
   2974 information, described above, shows how the base class parts are
   2975 ordered.  The base offset for a virtual base class is always given as 0.
   2976 Notice that the base offset for `B' is given as 0 even though `B' is
   2977 not the first base class.  The first base class `A' starts at offset 0.
   2978 
   2979    The field information part of the stab for class `D' describes the
   2980 field which is the pointer to the virtual base class `B'. The vbase
   2981 pointer name is `$vb' followed by a type reference to the virtual base
   2982 class.  Since the type id for `B' in this example is 25, the vbase
   2983 pointer name is `$vb25'.
   2984 
   2985      .stabs "D:Tt31=s32!3,000,20;100,25;0264,28;$vb25:24,128;Ddat:1,
   2986             160,32;A_virt::32=##1;:i;2A*-2147483647;20;;B_virt::32:i;
   2987             2A*-2147483647;25;;C_virt::32:i;2A*-2147483647;28;;D_virt:
   2988             :32:i;2A*-2147483646;31;;;~%20;",128,0,0,0
   2989 
   2990    Following the name and a semicolon is a type reference describing the
   2991 type of the virtual base class pointer, in this case 24.  Type 24 was
   2992 defined earlier as the type of the `B' class `this' pointer.  The
   2993 `this' pointer for a class is a pointer to the class type.
   2994 
   2995      .stabs "this:P24=*25=xsB:",64,0,0,8
   2996 
   2997    Finally the field offset part of the vbase pointer field description
   2998 shows that the vbase pointer is the first field in the `D' object,
   2999 before any data fields defined by the class.  The layout of a `D' class
   3000 object is a follows, `Adat' at 0, the vtable pointer for `A' at 32,
   3001 `Cdat' at 64, the vtable pointer for C at 96, the virtual base pointer
   3002 for `B' at 128, and `Ddat' at 160.
   3003 
   3004 
   3005 File: stabs.info,  Node: Static Members,  Prev: Virtual Base Classes,  Up: Cplusplus
   3006 
   3007 8.14 Static Members
   3008 ===================
   3009 
   3010 The data area for a class is a concatenation of the space used by the
   3011 data members of the class.  If the class has virtual methods, a vtable
   3012 pointer follows the class data.  The field offset part of each field
   3013 description in the class stab shows this ordering.
   3014 
   3015    << How is this reflected in stabs?  See Cygnus bug #677 for some
   3016 info.  >>
   3017 
   3018 
   3019 File: stabs.info,  Node: Stab Types,  Next: Symbol Descriptors,  Prev: Cplusplus,  Up: Top
   3020 
   3021 Appendix A Table of Stab Types
   3022 ******************************
   3023 
   3024 The following are all the possible values for the stab type field, for
   3025 a.out files, in numeric order.  This does not apply to XCOFF, but it
   3026 does apply to stabs in sections (*note Stab Sections::).  Stabs in
   3027 ECOFF use these values but add 0x8f300 to distinguish them from non-stab
   3028 symbols.
   3029 
   3030    The symbolic names are defined in the file `include/aout/stabs.def'.
   3031 
   3032 * Menu:
   3033 
   3034 * Non-Stab Symbol Types::	Types from 0 to 0x1f
   3035 * Stab Symbol Types::		Types from 0x20 to 0xff
   3036 
   3037 
   3038 File: stabs.info,  Node: Non-Stab Symbol Types,  Next: Stab Symbol Types,  Up: Stab Types
   3039 
   3040 A.1 Non-Stab Symbol Types
   3041 =========================
   3042 
   3043 The following types are used by the linker and assembler, not by stab
   3044 directives.  Since this document does not attempt to describe aspects of
   3045 object file format other than the debugging format, no details are
   3046 given.
   3047 
   3048 `0x0     N_UNDF'
   3049      Undefined symbol
   3050 
   3051 `0x2     N_ABS'
   3052      File scope absolute symbol
   3053 
   3054 `0x3     N_ABS | N_EXT'
   3055      External absolute symbol
   3056 
   3057 `0x4     N_TEXT'
   3058      File scope text symbol
   3059 
   3060 `0x5     N_TEXT | N_EXT'
   3061      External text symbol
   3062 
   3063 `0x6     N_DATA'
   3064      File scope data symbol
   3065 
   3066 `0x7     N_DATA | N_EXT'
   3067      External data symbol
   3068 
   3069 `0x8     N_BSS'
   3070      File scope BSS symbol
   3071 
   3072 `0x9     N_BSS | N_EXT'
   3073      External BSS symbol
   3074 
   3075 `0x0c    N_FN_SEQ'
   3076      Same as `N_FN', for Sequent compilers
   3077 
   3078 `0x0a    N_INDR'
   3079      Symbol is indirected to another symbol
   3080 
   3081 `0x12    N_COMM'
   3082      Common--visible after shared library dynamic link
   3083 
   3084 `0x14 N_SETA'
   3085 `0x15 N_SETA | N_EXT'
   3086      Absolute set element
   3087 
   3088 `0x16 N_SETT'
   3089 `0x17 N_SETT | N_EXT'
   3090      Text segment set element
   3091 
   3092 `0x18 N_SETD'
   3093 `0x19 N_SETD | N_EXT'
   3094      Data segment set element
   3095 
   3096 `0x1a N_SETB'
   3097 `0x1b N_SETB | N_EXT'
   3098      BSS segment set element
   3099 
   3100 `0x1c N_SETV'
   3101 `0x1d N_SETV | N_EXT'
   3102      Pointer to set vector
   3103 
   3104 `0x1e N_WARNING'
   3105      Print a warning message during linking
   3106 
   3107 `0x1f    N_FN'
   3108      File name of a `.o' file
   3109 
   3110 
   3111 File: stabs.info,  Node: Stab Symbol Types,  Prev: Non-Stab Symbol Types,  Up: Stab Types
   3112 
   3113 A.2 Stab Symbol Types
   3114 =====================
   3115 
   3116 The following symbol types indicate that this is a stab.  This is the
   3117 full list of stab numbers, including stab types that are used in
   3118 languages other than C.
   3119 
   3120 `0x20     N_GSYM'
   3121      Global symbol; see *note Global Variables::.
   3122 
   3123 `0x22     N_FNAME'
   3124      Function name (for BSD Fortran); see *note Procedures::.
   3125 
   3126 `0x24     N_FUN'
   3127      Function name (*note Procedures::) or text segment variable (*note
   3128      Statics::).
   3129 
   3130 `0x26 N_STSYM'
   3131      Data segment file-scope variable; see *note Statics::.
   3132 
   3133 `0x28 N_LCSYM'
   3134      BSS segment file-scope variable; see *note Statics::.
   3135 
   3136 `0x2a N_MAIN'
   3137      Name of main routine; see *note Main Program::.
   3138 
   3139 `0x2c N_ROSYM'
   3140      Variable in `.rodata' section; see *note Statics::.
   3141 
   3142 `0x30     N_PC'
   3143      Global symbol (for Pascal); see *note N_PC::.
   3144 
   3145 `0x32     N_NSYMS'
   3146      Number of symbols (according to Ultrix V4.0); see *note N_NSYMS::.
   3147 
   3148 `0x34     N_NOMAP'
   3149      No DST map; see *note N_NOMAP::.
   3150 
   3151 `0x36     N_MAC_DEFINE'
   3152      Name and body of a `#define'd macro; see *note Macro define and
   3153      undefine::.
   3154 
   3155 `0x38 N_OBJ'
   3156      Object file (Solaris2).
   3157 
   3158 `0x3a     N_MAC_UNDEF'
   3159      Name of an `#undef'ed macro; see *note Macro define and undefine::.
   3160 
   3161 `0x3c N_OPT'
   3162      Debugger options (Solaris2).
   3163 
   3164 `0x40     N_RSYM'
   3165      Register variable; see *note Register Variables::.
   3166 
   3167 `0x42     N_M2C'
   3168      Modula-2 compilation unit; see *note N_M2C::.
   3169 
   3170 `0x44     N_SLINE'
   3171      Line number in text segment; see *note Line Numbers::.
   3172 
   3173 `0x46     N_DSLINE'
   3174      Line number in data segment; see *note Line Numbers::.
   3175 
   3176 `0x48     N_BSLINE'
   3177      Line number in bss segment; see *note Line Numbers::.
   3178 
   3179 `0x48     N_BROWS'
   3180      Sun source code browser, path to `.cb' file; see *note N_BROWS::.
   3181 
   3182 `0x4a     N_DEFD'
   3183      GNU Modula2 definition module dependency; see *note N_DEFD::.
   3184 
   3185 `0x4c N_FLINE'
   3186      Function start/body/end line numbers (Solaris2).
   3187 
   3188 `0x50     N_EHDECL'
   3189      GNU C++ exception variable; see *note N_EHDECL::.
   3190 
   3191 `0x50     N_MOD2'
   3192      Modula2 info "for imc" (according to Ultrix V4.0); see *note
   3193      N_MOD2::.
   3194 
   3195 `0x54     N_CATCH'
   3196      GNU C++ `catch' clause; see *note N_CATCH::.
   3197 
   3198 `0x60     N_SSYM'
   3199      Structure of union element; see *note N_SSYM::.
   3200 
   3201 `0x62 N_ENDM'
   3202      Last stab for module (Solaris2).
   3203 
   3204 `0x64     N_SO'
   3205      Path and name of source file; see *note Source Files::.
   3206 
   3207 `0x80 N_LSYM'
   3208      Stack variable (*note Stack Variables::) or type (*note
   3209      Typedefs::).
   3210 
   3211 `0x82     N_BINCL'
   3212      Beginning of an include file (Sun only); see *note Include Files::.
   3213 
   3214 `0x84     N_SOL'
   3215      Name of include file; see *note Include Files::.
   3216 
   3217 `0xa0     N_PSYM'
   3218      Parameter variable; see *note Parameters::.
   3219 
   3220 `0xa2     N_EINCL'
   3221      End of an include file; see *note Include Files::.
   3222 
   3223 `0xa4     N_ENTRY'
   3224      Alternate entry point; see *note Alternate Entry Points::.
   3225 
   3226 `0xc0     N_LBRAC'
   3227      Beginning of a lexical block; see *note Block Structure::.
   3228 
   3229 `0xc2     N_EXCL'
   3230      Place holder for a deleted include file; see *note Include Files::.
   3231 
   3232 `0xc4     N_SCOPE'
   3233      Modula2 scope information (Sun linker); see *note N_SCOPE::.
   3234 
   3235 `0xe0     N_RBRAC'
   3236      End of a lexical block; see *note Block Structure::.
   3237 
   3238 `0xe2     N_BCOMM'
   3239      Begin named common block; see *note Common Blocks::.
   3240 
   3241 `0xe4     N_ECOMM'
   3242      End named common block; see *note Common Blocks::.
   3243 
   3244 `0xe8     N_ECOML'
   3245      Member of a common block; see *note Common Blocks::.
   3246 
   3247 `0xea N_WITH'
   3248      Pascal `with' statement: type,,0,0,offset (Solaris2).
   3249 
   3250 `0xf0     N_NBTEXT'
   3251      Gould non-base registers; see *note Gould::.
   3252 
   3253 `0xf2     N_NBDATA'
   3254      Gould non-base registers; see *note Gould::.
   3255 
   3256 `0xf4     N_NBBSS'
   3257      Gould non-base registers; see *note Gould::.
   3258 
   3259 `0xf6     N_NBSTS'
   3260      Gould non-base registers; see *note Gould::.
   3261 
   3262 `0xf8     N_NBLCS'
   3263      Gould non-base registers; see *note Gould::.
   3264 
   3265 
   3266 File: stabs.info,  Node: Symbol Descriptors,  Next: Type Descriptors,  Prev: Stab Types,  Up: Top
   3267 
   3268 Appendix B Table of Symbol Descriptors
   3269 **************************************
   3270 
   3271 The symbol descriptor is the character which follows the colon in many
   3272 stabs, and which tells what kind of stab it is.  *Note String Field::,
   3273 for more information about their use.
   3274 
   3275 `DIGIT'
   3276 `('
   3277 `-'
   3278      Variable on the stack; see *note Stack Variables::.
   3279 
   3280 `:'
   3281      C++ nested symbol; see *Note Nested Symbols::.
   3282 
   3283 `a'
   3284      Parameter passed by reference in register; see *note Reference
   3285      Parameters::.
   3286 
   3287 `b'
   3288      Based variable; see *note Based Variables::.
   3289 
   3290 `c'
   3291      Constant; see *note Constants::.
   3292 
   3293 `C'
   3294      Conformant array bound (Pascal, maybe other languages); *note
   3295      Conformant Arrays::.  Name of a caught exception (GNU C++).  These
   3296      can be distinguished because the latter uses `N_CATCH' and the
   3297      former uses another symbol type.
   3298 
   3299 `d'
   3300      Floating point register variable; see *note Register Variables::.
   3301 
   3302 `D'
   3303      Parameter in floating point register; see *note Register
   3304      Parameters::.
   3305 
   3306 `f'
   3307      File scope function; see *note Procedures::.
   3308 
   3309 `F'
   3310      Global function; see *note Procedures::.
   3311 
   3312 `G'
   3313      Global variable; see *note Global Variables::.
   3314 
   3315 `i'
   3316      *Note Register Parameters::.
   3317 
   3318 `I'
   3319      Internal (nested) procedure; see *note Nested Procedures::.
   3320 
   3321 `J'
   3322      Internal (nested) function; see *note Nested Procedures::.
   3323 
   3324 `L'
   3325      Label name (documented by AIX, no further information known).
   3326 
   3327 `m'
   3328      Module; see *note Procedures::.
   3329 
   3330 `p'
   3331      Argument list parameter; see *note Parameters::.
   3332 
   3333 `pP'
   3334      *Note Parameters::.
   3335 
   3336 `pF'
   3337      Fortran Function parameter; see *note Parameters::.
   3338 
   3339 `P'
   3340      Unfortunately, three separate meanings have been independently
   3341      invented for this symbol descriptor.  At least the GNU and Sun
   3342      uses can be distinguished by the symbol type.  Global Procedure
   3343      (AIX) (symbol type used unknown); see *note Procedures::.
   3344      Register parameter (GNU) (symbol type `N_PSYM'); see *note
   3345      Parameters::.  Prototype of function referenced by this file (Sun
   3346      `acc') (symbol type `N_FUN').
   3347 
   3348 `Q'
   3349      Static Procedure; see *note Procedures::.
   3350 
   3351 `R'
   3352      Register parameter; see *note Register Parameters::.
   3353 
   3354 `r'
   3355      Register variable; see *note Register Variables::.
   3356 
   3357 `S'
   3358      File scope variable; see *note Statics::.
   3359 
   3360 `s'
   3361      Local variable (OS9000).
   3362 
   3363 `t'
   3364      Type name; see *note Typedefs::.
   3365 
   3366 `T'
   3367      Enumeration, structure, or union tag; see *note Typedefs::.
   3368 
   3369 `v'
   3370      Parameter passed by reference; see *note Reference Parameters::.
   3371 
   3372 `V'
   3373      Procedure scope static variable; see *note Statics::.
   3374 
   3375 `x'
   3376      Conformant array; see *note Conformant Arrays::.
   3377 
   3378 `X'
   3379      Function return variable; see *note Parameters::.
   3380 
   3381 
   3382 File: stabs.info,  Node: Type Descriptors,  Next: Expanded Reference,  Prev: Symbol Descriptors,  Up: Top
   3383 
   3384 Appendix C Table of Type Descriptors
   3385 ************************************
   3386 
   3387 The type descriptor is the character which follows the type number and
   3388 an equals sign.  It specifies what kind of type is being defined.
   3389 *Note String Field::, for more information about their use.
   3390 
   3391 `DIGIT'
   3392 `('
   3393      Type reference; see *note String Field::.
   3394 
   3395 `-'
   3396      Reference to builtin type; see *note Negative Type Numbers::.
   3397 
   3398 `#'
   3399      Method (C++); see *note Method Type Descriptor::.
   3400 
   3401 `*'
   3402      Pointer; see *note Miscellaneous Types::.
   3403 
   3404 `&'
   3405      Reference (C++).
   3406 
   3407 `@'
   3408      Type Attributes (AIX); see *note String Field::.  Member (class
   3409      and variable) type (GNU C++); see *note Member Type Descriptor::.
   3410 
   3411 `a'
   3412      Array; see *note Arrays::.
   3413 
   3414 `A'
   3415      Open array; see *note Arrays::.
   3416 
   3417 `b'
   3418      Pascal space type (AIX); see *note Miscellaneous Types::.  Builtin
   3419      integer type (Sun); see *note Builtin Type Descriptors::.  Const
   3420      and volatile qualified type (OS9000).
   3421 
   3422 `B'
   3423      Volatile-qualified type; see *note Miscellaneous Types::.
   3424 
   3425 `c'
   3426      Complex builtin type (AIX); see *note Builtin Type Descriptors::.
   3427      Const-qualified type (OS9000).
   3428 
   3429 `C'
   3430      COBOL Picture type.  See AIX documentation for details.
   3431 
   3432 `d'
   3433      File type; see *note Miscellaneous Types::.
   3434 
   3435 `D'
   3436      N-dimensional dynamic array; see *note Arrays::.
   3437 
   3438 `e'
   3439      Enumeration type; see *note Enumerations::.
   3440 
   3441 `E'
   3442      N-dimensional subarray; see *note Arrays::.
   3443 
   3444 `f'
   3445      Function type; see *note Function Types::.
   3446 
   3447 `F'
   3448      Pascal function parameter; see *note Function Types::
   3449 
   3450 `g'
   3451      Builtin floating point type; see *note Builtin Type Descriptors::.
   3452 
   3453 `G'
   3454      COBOL Group.  See AIX documentation for details.
   3455 
   3456 `i'
   3457      Imported type (AIX); see *note Cross-References::.
   3458      Volatile-qualified type (OS9000).
   3459 
   3460 `k'
   3461      Const-qualified type; see *note Miscellaneous Types::.
   3462 
   3463 `K'
   3464      COBOL File Descriptor.  See AIX documentation for details.
   3465 
   3466 `M'
   3467      Multiple instance type; see *note Miscellaneous Types::.
   3468 
   3469 `n'
   3470      String type; see *note Strings::.
   3471 
   3472 `N'
   3473      Stringptr; see *note Strings::.
   3474 
   3475 `o'
   3476      Opaque type; see *note Typedefs::.
   3477 
   3478 `p'
   3479      Procedure; see *note Function Types::.
   3480 
   3481 `P'
   3482      Packed array; see *note Arrays::.
   3483 
   3484 `r'
   3485      Range type; see *note Subranges::.
   3486 
   3487 `R'
   3488      Builtin floating type; see *note Builtin Type Descriptors:: (Sun).
   3489      Pascal subroutine parameter; see *note Function Types:: (AIX).
   3490      Detecting this conflict is possible with careful parsing (hint: a
   3491      Pascal subroutine parameter type will always contain a comma, and
   3492      a builtin type descriptor never will).
   3493 
   3494 `s'
   3495      Structure type; see *note Structures::.
   3496 
   3497 `S'
   3498      Set type; see *note Miscellaneous Types::.
   3499 
   3500 `u'
   3501      Union; see *note Unions::.
   3502 
   3503 `v'
   3504      Variant record.  This is a Pascal and Modula-2 feature which is
   3505      like a union within a struct in C.  See AIX documentation for
   3506      details.
   3507 
   3508 `w'
   3509      Wide character; see *note Builtin Type Descriptors::.
   3510 
   3511 `x'
   3512      Cross-reference; see *note Cross-References::.
   3513 
   3514 `Y'
   3515      Used by IBM's xlC C++ compiler (for structures, I think).
   3516 
   3517 `z'
   3518      gstring; see *note Strings::.
   3519 
   3520 
   3521 File: stabs.info,  Node: Expanded Reference,  Next: Questions,  Prev: Type Descriptors,  Up: Top
   3522 
   3523 Appendix D Expanded Reference by Stab Type
   3524 ******************************************
   3525 
   3526 For a full list of stab types, and cross-references to where they are
   3527 described, see *note Stab Types::.  This appendix just covers certain
   3528 stabs which are not yet described in the main body of this document;
   3529 eventually the information will all be in one place.
   3530 
   3531    Format of an entry:
   3532 
   3533    The first line is the symbol type (see `include/aout/stab.def').
   3534 
   3535    The second line describes the language constructs the symbol type
   3536 represents.
   3537 
   3538    The third line is the stab format with the significant stab fields
   3539 named and the rest NIL.
   3540 
   3541    Subsequent lines expand upon the meaning and possible values for each
   3542 significant stab field.
   3543 
   3544    Finally, any further information.
   3545 
   3546 * Menu:
   3547 
   3548 * N_PC::			Pascal global symbol
   3549 * N_NSYMS::			Number of symbols
   3550 * N_NOMAP::			No DST map
   3551 * N_M2C::			Modula-2 compilation unit
   3552 * N_BROWS::			Path to .cb file for Sun source code browser
   3553 * N_DEFD::			GNU Modula2 definition module dependency
   3554 * N_EHDECL::			GNU C++ exception variable
   3555 * N_MOD2::			Modula2 information "for imc"
   3556 * N_CATCH::			GNU C++ "catch" clause
   3557 * N_SSYM::			Structure or union element
   3558 * N_SCOPE::			Modula2 scope information (Sun only)
   3559 * Gould::			non-base register symbols used on Gould systems
   3560 * N_LENG::			Length of preceding entry
   3561 
   3562 
   3563 File: stabs.info,  Node: N_PC,  Next: N_NSYMS,  Up: Expanded Reference
   3564 
   3565 D.1 N_PC
   3566 ========
   3567 
   3568  -- `.stabs': N_PC
   3569      Global symbol (for Pascal).
   3570 
   3571           "name" -> "symbol_name"  <<?>>
   3572           value  -> supposedly the line number (stab.def is skeptical)
   3573 
   3574           `stabdump.c' says:
   3575 
   3576           global pascal symbol: name,,0,subtype,line
   3577           << subtype? >>
   3578 
   3579 
   3580 File: stabs.info,  Node: N_NSYMS,  Next: N_NOMAP,  Prev: N_PC,  Up: Expanded Reference
   3581 
   3582 D.2 N_NSYMS
   3583 ===========
   3584 
   3585  -- `.stabn': N_NSYMS
   3586      Number of symbols (according to Ultrix V4.0).
   3587 
   3588                   0, files,,funcs,lines (stab.def)
   3589 
   3590 
   3591 File: stabs.info,  Node: N_NOMAP,  Next: N_M2C,  Prev: N_NSYMS,  Up: Expanded Reference
   3592 
   3593 D.3 N_NOMAP
   3594 ===========
   3595 
   3596  -- `.stabs': N_NOMAP
   3597      No DST map for symbol (according to Ultrix V4.0).  I think this
   3598      means a variable has been optimized out.
   3599 
   3600                   name, ,0,type,ignored (stab.def)
   3601 
   3602 
   3603 File: stabs.info,  Node: N_M2C,  Next: N_BROWS,  Prev: N_NOMAP,  Up: Expanded Reference
   3604 
   3605 D.4 N_M2C
   3606 =========
   3607 
   3608  -- `.stabs': N_M2C
   3609      Modula-2 compilation unit.
   3610 
   3611           "string" -> "unit_name,unit_time_stamp[,code_time_stamp]"
   3612           desc   -> unit_number
   3613           value  -> 0 (main unit)
   3614                     1 (any other unit)
   3615 
   3616      See `Dbx and Dbxtool Interfaces', 2nd edition, by Sun, 1988, for
   3617      more information.
   3618 
   3619 
   3620 
   3621 File: stabs.info,  Node: N_BROWS,  Next: N_DEFD,  Prev: N_M2C,  Up: Expanded Reference
   3622 
   3623 D.5 N_BROWS
   3624 ===========
   3625 
   3626  -- `.stabs': N_BROWS
   3627      Sun source code browser, path to `.cb' file
   3628 
   3629      <<?>> "path to associated `.cb' file"
   3630 
   3631      Note: N_BROWS has the same value as N_BSLINE.
   3632 
   3633 
   3634 File: stabs.info,  Node: N_DEFD,  Next: N_EHDECL,  Prev: N_BROWS,  Up: Expanded Reference
   3635 
   3636 D.6 N_DEFD
   3637 ==========
   3638 
   3639  -- `.stabn': N_DEFD
   3640      GNU Modula2 definition module dependency.
   3641 
   3642      GNU Modula-2 definition module dependency.  The value is the
   3643      modification time of the definition file.  The other field is
   3644      non-zero if it is imported with the GNU M2 keyword `%INITIALIZE'.
   3645      Perhaps `N_M2C' can be used if there are enough empty fields?
   3646 
   3647 
   3648 File: stabs.info,  Node: N_EHDECL,  Next: N_MOD2,  Prev: N_DEFD,  Up: Expanded Reference
   3649 
   3650 D.7 N_EHDECL
   3651 ============
   3652 
   3653  -- `.stabs': N_EHDECL
   3654      GNU C++ exception variable <<?>>.
   3655 
   3656      "STRING is variable name"
   3657 
   3658      Note: conflicts with `N_MOD2'.
   3659 
   3660 
   3661 File: stabs.info,  Node: N_MOD2,  Next: N_CATCH,  Prev: N_EHDECL,  Up: Expanded Reference
   3662 
   3663 D.8 N_MOD2
   3664 ==========
   3665 
   3666  -- `.stab?': N_MOD2
   3667      Modula2 info "for imc" (according to Ultrix V4.0)
   3668 
   3669      Note: conflicts with `N_EHDECL'  <<?>>
   3670 
   3671 
   3672 File: stabs.info,  Node: N_CATCH,  Next: N_SSYM,  Prev: N_MOD2,  Up: Expanded Reference
   3673 
   3674 D.9 N_CATCH
   3675 ===========
   3676 
   3677  -- `.stabn': N_CATCH
   3678      GNU C++ `catch' clause
   3679 
   3680      GNU C++ `catch' clause.  The value is its address.  The desc field
   3681      is nonzero if this entry is immediately followed by a `CAUGHT' stab
   3682      saying what exception was caught.  Multiple `CAUGHT' stabs means
   3683      that multiple exceptions can be caught here.  If desc is 0, it
   3684      means all exceptions are caught here.
   3685 
   3686 
   3687 File: stabs.info,  Node: N_SSYM,  Next: N_SCOPE,  Prev: N_CATCH,  Up: Expanded Reference
   3688 
   3689 D.10 N_SSYM
   3690 ===========
   3691 
   3692  -- `.stabn': N_SSYM
   3693      Structure or union element.
   3694 
   3695      The value is the offset in the structure.
   3696 
   3697      <<?looking at structs and unions in C I didn't see these>>
   3698 
   3699 
   3700 File: stabs.info,  Node: N_SCOPE,  Next: Gould,  Prev: N_SSYM,  Up: Expanded Reference
   3701 
   3702 D.11 N_SCOPE
   3703 ============
   3704 
   3705  -- `.stab?': N_SCOPE
   3706      Modula2 scope information (Sun linker) <<?>>
   3707 
   3708 
   3709 File: stabs.info,  Node: Gould,  Next: N_LENG,  Prev: N_SCOPE,  Up: Expanded Reference
   3710 
   3711 D.12 Non-base registers on Gould systems
   3712 ========================================
   3713 
   3714  -- `.stab?': N_NBTEXT
   3715  -- `.stab?': N_NBDATA
   3716  -- `.stab?': N_NBBSS
   3717  -- `.stab?': N_NBSTS
   3718  -- `.stab?': N_NBLCS
   3719      These are used on Gould systems for non-base registers syms.
   3720 
   3721      However, the following values are not the values used by Gould;
   3722      they are the values which GNU has been documenting for these
   3723      values for a long time, without actually checking what Gould uses.
   3724      I include these values only because perhaps some someone actually
   3725      did something with the GNU information (I hope not, why GNU
   3726      knowingly assigned wrong values to these in the header file is a
   3727      complete mystery to me).
   3728 
   3729           240    0xf0     N_NBTEXT  ??
   3730           242    0xf2     N_NBDATA  ??
   3731           244    0xf4     N_NBBSS   ??
   3732           246    0xf6     N_NBSTS   ??
   3733           248    0xf8     N_NBLCS   ??
   3734 
   3735 
   3736 File: stabs.info,  Node: N_LENG,  Prev: Gould,  Up: Expanded Reference
   3737 
   3738 D.13 N_LENG
   3739 ===========
   3740 
   3741  -- `.stabn': N_LENG
   3742      Second symbol entry containing a length-value for the preceding
   3743      entry.  The value is the length.
   3744 
   3745 
   3746 File: stabs.info,  Node: Questions,  Next: Stab Sections,  Prev: Expanded Reference,  Up: Top
   3747 
   3748 Appendix E Questions and Anomalies
   3749 **********************************
   3750 
   3751    * For GNU C stabs defining local and global variables (`N_LSYM' and
   3752      `N_GSYM'), the desc field is supposed to contain the source line
   3753      number on which the variable is defined.  In reality the desc
   3754      field is always 0.  (This behavior is defined in `dbxout.c' and
   3755      putting a line number in desc is controlled by `#ifdef
   3756      WINNING_GDB', which defaults to false). GDB supposedly uses this
   3757      information if you say `list VAR'.  In reality, VAR can be a
   3758      variable defined in the program and GDB says `function VAR not
   3759      defined'.
   3760 
   3761    * In GNU C stabs, there seems to be no way to differentiate tag
   3762      types: structures, unions, and enums (symbol descriptor `T') and
   3763      typedefs (symbol descriptor `t') defined at file scope from types
   3764      defined locally to a procedure or other more local scope.  They
   3765      all use the `N_LSYM' stab type.  Types defined at procedure scope
   3766      are emitted after the `N_RBRAC' of the preceding function and
   3767      before the code of the procedure in which they are defined.  This
   3768      is exactly the same as types defined in the source file between
   3769      the two procedure bodies.  GDB over-compensates by placing all
   3770      types in block #1, the block for symbols of file scope.  This is
   3771      true for default, `-ansi' and `-traditional' compiler options.
   3772      (Bugs gcc/1063, gdb/1066.)
   3773 
   3774    * What ends the procedure scope?  Is it the proc block's `N_RBRAC'
   3775      or the next `N_FUN'?  (I believe its the first.)
   3776 
   3777 
   3778 File: stabs.info,  Node: Stab Sections,  Next: Symbol Types Index,  Prev: Questions,  Up: Top
   3779 
   3780 Appendix F Using Stabs in Their Own Sections
   3781 ********************************************
   3782 
   3783 Many object file formats allow tools to create object files with custom
   3784 sections containing any arbitrary data.  For any such object file
   3785 format, stabs can be embedded in special sections.  This is how stabs
   3786 are used with ELF and SOM, and aside from ECOFF and XCOFF, is how stabs
   3787 are used with COFF.
   3788 
   3789 * Menu:
   3790 
   3791 * Stab Section Basics::    How to embed stabs in sections
   3792 * ELF Linker Relocation::  Sun ELF hacks
   3793 
   3794 
   3795 File: stabs.info,  Node: Stab Section Basics,  Next: ELF Linker Relocation,  Up: Stab Sections
   3796 
   3797 F.1 How to Embed Stabs in Sections
   3798 ==================================
   3799 
   3800 The assembler creates two custom sections, a section named `.stab'
   3801 which contains an array of fixed length structures, one struct per stab,
   3802 and a section named `.stabstr' containing all the variable length
   3803 strings that are referenced by stabs in the `.stab' section.  The byte
   3804 order of the stabs binary data depends on the object file format.  For
   3805 ELF, it matches the byte order of the ELF file itself, as determined
   3806 from the `EI_DATA' field in the `e_ident' member of the ELF header.
   3807 For SOM, it is always big-endian (is this true??? FIXME).  For COFF, it
   3808 matches the byte order of the COFF headers.  The meaning of the fields
   3809 is the same as for a.out (*note Symbol Table Format::), except that the
   3810 `n_strx' field is relative to the strings for the current compilation
   3811 unit (which can be found using the synthetic N_UNDF stab described
   3812 below), rather than the entire string table.
   3813 
   3814    The first stab in the `.stab' section for each compilation unit is
   3815 synthetic, generated entirely by the assembler, with no corresponding
   3816 `.stab' directive as input to the assembler.  This stab contains the
   3817 following fields:
   3818 
   3819 `n_strx'
   3820      Offset in the `.stabstr' section to the source filename.
   3821 
   3822 `n_type'
   3823      `N_UNDF'.
   3824 
   3825 `n_other'
   3826      Unused field, always zero.  This may eventually be used to hold
   3827      overflows from the count in the `n_desc' field.
   3828 
   3829 `n_desc'
   3830      Count of upcoming symbols, i.e., the number of remaining stabs for
   3831      this source file.
   3832 
   3833 `n_value'
   3834      Size of the string table fragment associated with this source
   3835      file, in bytes.
   3836 
   3837    The `.stabstr' section always starts with a null byte (so that string
   3838 offsets of zero reference a null string), followed by random length
   3839 strings, each of which is null byte terminated.
   3840 
   3841    The ELF section header for the `.stab' section has its `sh_link'
   3842 member set to the section number of the `.stabstr' section, and the
   3843 `.stabstr' section has its ELF section header `sh_type' member set to
   3844 `SHT_STRTAB' to mark it as a string table.  SOM and COFF have no way of
   3845 linking the sections together or marking them as string tables.
   3846 
   3847    For COFF, the `.stab' and `.stabstr' sections may be simply
   3848 concatenated by the linker.  GDB then uses the `n_desc' fields to
   3849 figure out the extent of the original sections.  Similarly, the
   3850 `n_value' fields of the header symbols are added together in order to
   3851 get the actual position of the strings in a desired `.stabstr' section.
   3852 Although this design obviates any need for the linker to relocate or
   3853 otherwise manipulate `.stab' and `.stabstr' sections, it also requires
   3854 some care to ensure that the offsets are calculated correctly.  For
   3855 instance, if the linker were to pad in between the `.stabstr' sections
   3856 before concatenating, then the offsets to strings in the middle of the
   3857 executable's `.stabstr' section would be wrong.
   3858 
   3859    The GNU linker is able to optimize stabs information by merging
   3860 duplicate strings and removing duplicate header file information (*note
   3861 Include Files::).  When some versions of the GNU linker optimize stabs
   3862 in sections, they remove the leading `N_UNDF' symbol and arranges for
   3863 all the `n_strx' fields to be relative to the start of the `.stabstr'
   3864 section.
   3865 
   3866 
   3867 File: stabs.info,  Node: ELF Linker Relocation,  Prev: Stab Section Basics,  Up: Stab Sections
   3868 
   3869 F.2 Having the Linker Relocate Stabs in ELF
   3870 ===========================================
   3871 
   3872 This section describes some Sun hacks for Stabs in ELF; it does not
   3873 apply to COFF or SOM.
   3874 
   3875    To keep linking fast, you don't want the linker to have to relocate
   3876 very many stabs.  Making sure this is done for `N_SLINE', `N_RBRAC',
   3877 and `N_LBRAC' stabs is the most important thing (see the descriptions
   3878 of those stabs for more information).  But Sun's stabs in ELF has taken
   3879 this further, to make all addresses in the `n_value' field (functions
   3880 and static variables) relative to the source file.  For the `N_SO'
   3881 symbol itself, Sun simply omits the address.  To find the address of
   3882 each section corresponding to a given source file, the compiler puts
   3883 out symbols giving the address of each section for a given source file.
   3884 Since these are ELF (not stab) symbols, the linker relocates them
   3885 correctly without having to touch the stabs section.  They are named
   3886 `Bbss.bss' for the bss section, `Ddata.data' for the data section, and
   3887 `Drodata.rodata' for the rodata section.  For the text section, there
   3888 is no such symbol (but there should be, see below).  For an example of
   3889 how these symbols work, *Note Stab Section Transformations::.  GCC does
   3890 not provide these symbols; it instead relies on the stabs getting
   3891 relocated.  Thus addresses which would normally be relative to
   3892 `Bbss.bss', etc., are already relocated.  The Sun linker provided with
   3893 Solaris 2.2 and earlier relocates stabs using normal ELF relocation
   3894 information, as it would do for any section.  Sun has been threatening
   3895 to kludge their linker to not do this (to speed up linking), even
   3896 though the correct way to avoid having the linker do these relocations
   3897 is to have the compiler no longer output relocatable values.  Last I
   3898 heard they had been talked out of the linker kludge.  See Sun point
   3899 patch 101052-01 and Sun bug 1142109.  With the Sun compiler this
   3900 affects `S' symbol descriptor stabs (*note Statics::) and functions
   3901 (*note Procedures::).  In the latter case, to adopt the clean solution
   3902 (making the value of the stab relative to the start of the compilation
   3903 unit), it would be necessary to invent a `Ttext.text' symbol, analogous
   3904 to the `Bbss.bss', etc., symbols.  I recommend this rather than using a
   3905 zero value and getting the address from the ELF symbols.
   3906 
   3907    Finding the correct `Bbss.bss', etc., symbol is difficult, because
   3908 the linker simply concatenates the `.stab' sections from each `.o' file
   3909 without including any information about which part of a `.stab' section
   3910 comes from which `.o' file.  The way GDB does this is to look for an
   3911 ELF `STT_FILE' symbol which has the same name as the last component of
   3912 the file name from the `N_SO' symbol in the stabs (for example, if the
   3913 file name is `../../gdb/main.c', it looks for an ELF `STT_FILE' symbol
   3914 named `main.c').  This loses if different files have the same name
   3915 (they could be in different directories, a library could have been
   3916 copied from one system to another, etc.).  It would be much cleaner to
   3917 have the `Bbss.bss' symbols in the stabs themselves.  Having the linker
   3918 relocate them there is no more work than having the linker relocate ELF
   3919 symbols, and it solves the problem of having to associate the ELF and
   3920 stab symbols.  However, no one has yet designed or implemented such a
   3921 scheme.
   3922 
   3923 
   3924 File: stabs.info,  Node: GNU Free Documentation License,  Prev: Symbol Types Index,  Up: Top
   3925 
   3926 Appendix G GNU Free Documentation License
   3927 *****************************************
   3928 
   3929                       Version 1.2, November 2002
   3930 
   3931      Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
   3932      51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   3933 
   3934      Everyone is permitted to copy and distribute verbatim copies
   3935      of this license document, but changing it is not allowed.
   3936 
   3937   0. PREAMBLE
   3938 
   3939      The purpose of this License is to make a manual, textbook, or other
   3940      functional and useful document "free" in the sense of freedom: to
   3941      assure everyone the effective freedom to copy and redistribute it,
   3942      with or without modifying it, either commercially or
   3943      noncommercially.  Secondarily, this License preserves for the
   3944      author and publisher a way to get credit for their work, while not
   3945      being considered responsible for modifications made by others.
   3946 
   3947      This License is a kind of "copyleft", which means that derivative
   3948      works of the document must themselves be free in the same sense.
   3949      It complements the GNU General Public License, which is a copyleft
   3950      license designed for free software.
   3951 
   3952      We have designed this License in order to use it for manuals for
   3953      free software, because free software needs free documentation: a
   3954      free program should come with manuals providing the same freedoms
   3955      that the software does.  But this License is not limited to
   3956      software manuals; it can be used for any textual work, regardless
   3957      of subject matter or whether it is published as a printed book.
   3958      We recommend this License principally for works whose purpose is
   3959      instruction or reference.
   3960 
   3961   1. APPLICABILITY AND DEFINITIONS
   3962 
   3963      This License applies to any manual or other work, in any medium,
   3964      that contains a notice placed by the copyright holder saying it
   3965      can be distributed under the terms of this License.  Such a notice
   3966      grants a world-wide, royalty-free license, unlimited in duration,
   3967      to use that work under the conditions stated herein.  The
   3968      "Document", below, refers to any such manual or work.  Any member
   3969      of the public is a licensee, and is addressed as "you".  You
   3970      accept the license if you copy, modify or distribute the work in a
   3971      way requiring permission under copyright law.
   3972 
   3973      A "Modified Version" of the Document means any work containing the
   3974      Document or a portion of it, either copied verbatim, or with
   3975      modifications and/or translated into another language.
   3976 
   3977      A "Secondary Section" is a named appendix or a front-matter section
   3978      of the Document that deals exclusively with the relationship of the
   3979      publishers or authors of the Document to the Document's overall
   3980      subject (or to related matters) and contains nothing that could
   3981      fall directly within that overall subject.  (Thus, if the Document
   3982      is in part a textbook of mathematics, a Secondary Section may not
   3983      explain any mathematics.)  The relationship could be a matter of
   3984      historical connection with the subject or with related matters, or
   3985      of legal, commercial, philosophical, ethical or political position
   3986      regarding them.
   3987 
   3988      The "Invariant Sections" are certain Secondary Sections whose
   3989      titles are designated, as being those of Invariant Sections, in
   3990      the notice that says that the Document is released under this
   3991      License.  If a section does not fit the above definition of
   3992      Secondary then it is not allowed to be designated as Invariant.
   3993      The Document may contain zero Invariant Sections.  If the Document
   3994      does not identify any Invariant Sections then there are none.
   3995 
   3996      The "Cover Texts" are certain short passages of text that are
   3997      listed, as Front-Cover Texts or Back-Cover Texts, in the notice
   3998      that says that the Document is released under this License.  A
   3999      Front-Cover Text may be at most 5 words, and a Back-Cover Text may
   4000      be at most 25 words.
   4001 
   4002      A "Transparent" copy of the Document means a machine-readable copy,
   4003      represented in a format whose specification is available to the
   4004      general public, that is suitable for revising the document
   4005      straightforwardly with generic text editors or (for images
   4006      composed of pixels) generic paint programs or (for drawings) some
   4007      widely available drawing editor, and that is suitable for input to
   4008      text formatters or for automatic translation to a variety of
   4009      formats suitable for input to text formatters.  A copy made in an
   4010      otherwise Transparent file format whose markup, or absence of
   4011      markup, has been arranged to thwart or discourage subsequent
   4012      modification by readers is not Transparent.  An image format is
   4013      not Transparent if used for any substantial amount of text.  A
   4014      copy that is not "Transparent" is called "Opaque".
   4015 
   4016      Examples of suitable formats for Transparent copies include plain
   4017      ASCII without markup, Texinfo input format, LaTeX input format,
   4018      SGML or XML using a publicly available DTD, and
   4019      standard-conforming simple HTML, PostScript or PDF designed for
   4020      human modification.  Examples of transparent image formats include
   4021      PNG, XCF and JPG.  Opaque formats include proprietary formats that
   4022      can be read and edited only by proprietary word processors, SGML or
   4023      XML for which the DTD and/or processing tools are not generally
   4024      available, and the machine-generated HTML, PostScript or PDF
   4025      produced by some word processors for output purposes only.
   4026 
   4027      The "Title Page" means, for a printed book, the title page itself,
   4028      plus such following pages as are needed to hold, legibly, the
   4029      material this License requires to appear in the title page.  For
   4030      works in formats which do not have any title page as such, "Title
   4031      Page" means the text near the most prominent appearance of the
   4032      work's title, preceding the beginning of the body of the text.
   4033 
   4034      A section "Entitled XYZ" means a named subunit of the Document
   4035      whose title either is precisely XYZ or contains XYZ in parentheses
   4036      following text that translates XYZ in another language.  (Here XYZ
   4037      stands for a specific section name mentioned below, such as
   4038      "Acknowledgements", "Dedications", "Endorsements", or "History".)
   4039      To "Preserve the Title" of such a section when you modify the
   4040      Document means that it remains a section "Entitled XYZ" according
   4041      to this definition.
   4042 
   4043      The Document may include Warranty Disclaimers next to the notice
   4044      which states that this License applies to the Document.  These
   4045      Warranty Disclaimers are considered to be included by reference in
   4046      this License, but only as regards disclaiming warranties: any other
   4047      implication that these Warranty Disclaimers may have is void and
   4048      has no effect on the meaning of this License.
   4049 
   4050   2. VERBATIM COPYING
   4051 
   4052      You may copy and distribute the Document in any medium, either
   4053      commercially or noncommercially, provided that this License, the
   4054      copyright notices, and the license notice saying this License
   4055      applies to the Document are reproduced in all copies, and that you
   4056      add no other conditions whatsoever to those of this License.  You
   4057      may not use technical measures to obstruct or control the reading
   4058      or further copying of the copies you make or distribute.  However,
   4059      you may accept compensation in exchange for copies.  If you
   4060      distribute a large enough number of copies you must also follow
   4061      the conditions in section 3.
   4062 
   4063      You may also lend copies, under the same conditions stated above,
   4064      and you may publicly display copies.
   4065 
   4066   3. COPYING IN QUANTITY
   4067 
   4068      If you publish printed copies (or copies in media that commonly
   4069      have printed covers) of the Document, numbering more than 100, and
   4070      the Document's license notice requires Cover Texts, you must
   4071      enclose the copies in covers that carry, clearly and legibly, all
   4072      these Cover Texts: Front-Cover Texts on the front cover, and
   4073      Back-Cover Texts on the back cover.  Both covers must also clearly
   4074      and legibly identify you as the publisher of these copies.  The
   4075      front cover must present the full title with all words of the
   4076      title equally prominent and visible.  You may add other material
   4077      on the covers in addition.  Copying with changes limited to the
   4078      covers, as long as they preserve the title of the Document and
   4079      satisfy these conditions, can be treated as verbatim copying in
   4080      other respects.
   4081 
   4082      If the required texts for either cover are too voluminous to fit
   4083      legibly, you should put the first ones listed (as many as fit
   4084      reasonably) on the actual cover, and continue the rest onto
   4085      adjacent pages.
   4086 
   4087      If you publish or distribute Opaque copies of the Document
   4088      numbering more than 100, you must either include a
   4089      machine-readable Transparent copy along with each Opaque copy, or
   4090      state in or with each Opaque copy a computer-network location from
   4091      which the general network-using public has access to download
   4092      using public-standard network protocols a complete Transparent
   4093      copy of the Document, free of added material.  If you use the
   4094      latter option, you must take reasonably prudent steps, when you
   4095      begin distribution of Opaque copies in quantity, to ensure that
   4096      this Transparent copy will remain thus accessible at the stated
   4097      location until at least one year after the last time you
   4098      distribute an Opaque copy (directly or through your agents or
   4099      retailers) of that edition to the public.
   4100 
   4101      It is requested, but not required, that you contact the authors of
   4102      the Document well before redistributing any large number of
   4103      copies, to give them a chance to provide you with an updated
   4104      version of the Document.
   4105 
   4106   4. MODIFICATIONS
   4107 
   4108      You may copy and distribute a Modified Version of the Document
   4109      under the conditions of sections 2 and 3 above, provided that you
   4110      release the Modified Version under precisely this License, with
   4111      the Modified Version filling the role of the Document, thus
   4112      licensing distribution and modification of the Modified Version to
   4113      whoever possesses a copy of it.  In addition, you must do these
   4114      things in the Modified Version:
   4115 
   4116        A. Use in the Title Page (and on the covers, if any) a title
   4117           distinct from that of the Document, and from those of
   4118           previous versions (which should, if there were any, be listed
   4119           in the History section of the Document).  You may use the
   4120           same title as a previous version if the original publisher of
   4121           that version gives permission.
   4122 
   4123        B. List on the Title Page, as authors, one or more persons or
   4124           entities responsible for authorship of the modifications in
   4125           the Modified Version, together with at least five of the
   4126           principal authors of the Document (all of its principal
   4127           authors, if it has fewer than five), unless they release you
   4128           from this requirement.
   4129 
   4130        C. State on the Title page the name of the publisher of the
   4131           Modified Version, as the publisher.
   4132 
   4133        D. Preserve all the copyright notices of the Document.
   4134 
   4135        E. Add an appropriate copyright notice for your modifications
   4136           adjacent to the other copyright notices.
   4137 
   4138        F. Include, immediately after the copyright notices, a license
   4139           notice giving the public permission to use the Modified
   4140           Version under the terms of this License, in the form shown in
   4141           the Addendum below.
   4142 
   4143        G. Preserve in that license notice the full lists of Invariant
   4144           Sections and required Cover Texts given in the Document's
   4145           license notice.
   4146 
   4147        H. Include an unaltered copy of this License.
   4148 
   4149        I. Preserve the section Entitled "History", Preserve its Title,
   4150           and add to it an item stating at least the title, year, new
   4151           authors, and publisher of the Modified Version as given on
   4152           the Title Page.  If there is no section Entitled "History" in
   4153           the Document, create one stating the title, year, authors,
   4154           and publisher of the Document as given on its Title Page,
   4155           then add an item describing the Modified Version as stated in
   4156           the previous sentence.
   4157 
   4158        J. Preserve the network location, if any, given in the Document
   4159           for public access to a Transparent copy of the Document, and
   4160           likewise the network locations given in the Document for
   4161           previous versions it was based on.  These may be placed in
   4162           the "History" section.  You may omit a network location for a
   4163           work that was published at least four years before the
   4164           Document itself, or if the original publisher of the version
   4165           it refers to gives permission.
   4166 
   4167        K. For any section Entitled "Acknowledgements" or "Dedications",
   4168           Preserve the Title of the section, and preserve in the
   4169           section all the substance and tone of each of the contributor
   4170           acknowledgements and/or dedications given therein.
   4171 
   4172        L. Preserve all the Invariant Sections of the Document,
   4173           unaltered in their text and in their titles.  Section numbers
   4174           or the equivalent are not considered part of the section
   4175           titles.
   4176 
   4177        M. Delete any section Entitled "Endorsements".  Such a section
   4178           may not be included in the Modified Version.
   4179 
   4180        N. Do not retitle any existing section to be Entitled
   4181           "Endorsements" or to conflict in title with any Invariant
   4182           Section.
   4183 
   4184        O. Preserve any Warranty Disclaimers.
   4185 
   4186      If the Modified Version includes new front-matter sections or
   4187      appendices that qualify as Secondary Sections and contain no
   4188      material copied from the Document, you may at your option
   4189      designate some or all of these sections as invariant.  To do this,
   4190      add their titles to the list of Invariant Sections in the Modified
   4191      Version's license notice.  These titles must be distinct from any
   4192      other section titles.
   4193 
   4194      You may add a section Entitled "Endorsements", provided it contains
   4195      nothing but endorsements of your Modified Version by various
   4196      parties--for example, statements of peer review or that the text
   4197      has been approved by an organization as the authoritative
   4198      definition of a standard.
   4199 
   4200      You may add a passage of up to five words as a Front-Cover Text,
   4201      and a passage of up to 25 words as a Back-Cover Text, to the end
   4202      of the list of Cover Texts in the Modified Version.  Only one
   4203      passage of Front-Cover Text and one of Back-Cover Text may be
   4204      added by (or through arrangements made by) any one entity.  If the
   4205      Document already includes a cover text for the same cover,
   4206      previously added by you or by arrangement made by the same entity
   4207      you are acting on behalf of, you may not add another; but you may
   4208      replace the old one, on explicit permission from the previous
   4209      publisher that added the old one.
   4210 
   4211      The author(s) and publisher(s) of the Document do not by this
   4212      License give permission to use their names for publicity for or to
   4213      assert or imply endorsement of any Modified Version.
   4214 
   4215   5. COMBINING DOCUMENTS
   4216 
   4217      You may combine the Document with other documents released under
   4218      this License, under the terms defined in section 4 above for
   4219      modified versions, provided that you include in the combination
   4220      all of the Invariant Sections of all of the original documents,
   4221      unmodified, and list them all as Invariant Sections of your
   4222      combined work in its license notice, and that you preserve all
   4223      their Warranty Disclaimers.
   4224 
   4225      The combined work need only contain one copy of this License, and
   4226      multiple identical Invariant Sections may be replaced with a single
   4227      copy.  If there are multiple Invariant Sections with the same name
   4228      but different contents, make the title of each such section unique
   4229      by adding at the end of it, in parentheses, the name of the
   4230      original author or publisher of that section if known, or else a
   4231      unique number.  Make the same adjustment to the section titles in
   4232      the list of Invariant Sections in the license notice of the
   4233      combined work.
   4234 
   4235      In the combination, you must combine any sections Entitled
   4236      "History" in the various original documents, forming one section
   4237      Entitled "History"; likewise combine any sections Entitled
   4238      "Acknowledgements", and any sections Entitled "Dedications".  You
   4239      must delete all sections Entitled "Endorsements."
   4240 
   4241   6. COLLECTIONS OF DOCUMENTS
   4242 
   4243      You may make a collection consisting of the Document and other
   4244      documents released under this License, and replace the individual
   4245      copies of this License in the various documents with a single copy
   4246      that is included in the collection, provided that you follow the
   4247      rules of this License for verbatim copying of each of the
   4248      documents in all other respects.
   4249 
   4250      You may extract a single document from such a collection, and
   4251      distribute it individually under this License, provided you insert
   4252      a copy of this License into the extracted document, and follow
   4253      this License in all other respects regarding verbatim copying of
   4254      that document.
   4255 
   4256   7. AGGREGATION WITH INDEPENDENT WORKS
   4257 
   4258      A compilation of the Document or its derivatives with other
   4259      separate and independent documents or works, in or on a volume of
   4260      a storage or distribution medium, is called an "aggregate" if the
   4261      copyright resulting from the compilation is not used to limit the
   4262      legal rights of the compilation's users beyond what the individual
   4263      works permit.  When the Document is included in an aggregate, this
   4264      License does not apply to the other works in the aggregate which
   4265      are not themselves derivative works of the Document.
   4266 
   4267      If the Cover Text requirement of section 3 is applicable to these
   4268      copies of the Document, then if the Document is less than one half
   4269      of the entire aggregate, the Document's Cover Texts may be placed
   4270      on covers that bracket the Document within the aggregate, or the
   4271      electronic equivalent of covers if the Document is in electronic
   4272      form.  Otherwise they must appear on printed covers that bracket
   4273      the whole aggregate.
   4274 
   4275   8. TRANSLATION
   4276 
   4277      Translation is considered a kind of modification, so you may
   4278      distribute translations of the Document under the terms of section
   4279      4.  Replacing Invariant Sections with translations requires special
   4280      permission from their copyright holders, but you may include
   4281      translations of some or all Invariant Sections in addition to the
   4282      original versions of these Invariant Sections.  You may include a
   4283      translation of this License, and all the license notices in the
   4284      Document, and any Warranty Disclaimers, provided that you also
   4285      include the original English version of this License and the
   4286      original versions of those notices and disclaimers.  In case of a
   4287      disagreement between the translation and the original version of
   4288      this License or a notice or disclaimer, the original version will
   4289      prevail.
   4290 
   4291      If a section in the Document is Entitled "Acknowledgements",
   4292      "Dedications", or "History", the requirement (section 4) to
   4293      Preserve its Title (section 1) will typically require changing the
   4294      actual title.
   4295 
   4296   9. TERMINATION
   4297 
   4298      You may not copy, modify, sublicense, or distribute the Document
   4299      except as expressly provided for under this License.  Any other
   4300      attempt to copy, modify, sublicense or distribute the Document is
   4301      void, and will automatically terminate your rights under this
   4302      License.  However, parties who have received copies, or rights,
   4303      from you under this License will not have their licenses
   4304      terminated so long as such parties remain in full compliance.
   4305 
   4306  10. FUTURE REVISIONS OF THIS LICENSE
   4307 
   4308      The Free Software Foundation may publish new, revised versions of
   4309      the GNU Free Documentation License from time to time.  Such new
   4310      versions will be similar in spirit to the present version, but may
   4311      differ in detail to address new problems or concerns.  See
   4312      `http://www.gnu.org/copyleft/'.
   4313 
   4314      Each version of the License is given a distinguishing version
   4315      number.  If the Document specifies that a particular numbered
   4316      version of this License "or any later version" applies to it, you
   4317      have the option of following the terms and conditions either of
   4318      that specified version or of any later version that has been
   4319      published (not as a draft) by the Free Software Foundation.  If
   4320      the Document does not specify a version number of this License,
   4321      you may choose any version ever published (not as a draft) by the
   4322      Free Software Foundation.
   4323 
   4324 G.1 ADDENDUM: How to use this License for your documents
   4325 ========================================================
   4326 
   4327 To use this License in a document you have written, include a copy of
   4328 the License in the document and put the following copyright and license
   4329 notices just after the title page:
   4330 
   4331        Copyright (C)  YEAR  YOUR NAME.
   4332        Permission is granted to copy, distribute and/or modify this document
   4333        under the terms of the GNU Free Documentation License, Version 1.2
   4334        or any later version published by the Free Software Foundation;
   4335        with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
   4336        Texts.  A copy of the license is included in the section entitled ``GNU
   4337        Free Documentation License''.
   4338 
   4339    If you have Invariant Sections, Front-Cover Texts and Back-Cover
   4340 Texts, replace the "with...Texts." line with this:
   4341 
   4342          with the Invariant Sections being LIST THEIR TITLES, with
   4343          the Front-Cover Texts being LIST, and with the Back-Cover Texts
   4344          being LIST.
   4345 
   4346    If you have Invariant Sections without Cover Texts, or some other
   4347 combination of the three, merge those two alternatives to suit the
   4348 situation.
   4349 
   4350    If your document contains nontrivial examples of program code, we
   4351 recommend releasing these examples in parallel under your choice of
   4352 free software license, such as the GNU General Public License, to
   4353 permit their use in free software.
   4354 
   4355 
   4356 File: stabs.info,  Node: Symbol Types Index,  Next: GNU Free Documentation License,  Prev: Stab Sections,  Up: Top
   4357 
   4358 Symbol Types Index
   4359 ******************
   4360 
   4361 [index]
   4362 * Menu:
   4363 
   4364 * .bb:                                   Block Structure.      (line 26)
   4365 * .be:                                   Block Structure.      (line 26)
   4366 * C_BCOMM:                               Common Blocks.        (line 10)
   4367 * C_BINCL:                               Include Files.        (line 41)
   4368 * C_BLOCK:                               Block Structure.      (line 26)
   4369 * C_BSTAT:                               Statics.              (line 31)
   4370 * C_DECL, for types:                     Typedefs.             (line  6)
   4371 * C_ECOML:                               Common Blocks.        (line 17)
   4372 * C_ECOMM:                               Common Blocks.        (line 10)
   4373 * C_EINCL:                               Include Files.        (line 41)
   4374 * C_ENTRY:                               Alternate Entry Points.
   4375                                                                (line  6)
   4376 * C_ESTAT:                               Statics.              (line 31)
   4377 * C_FILE:                                Source Files.         (line 61)
   4378 * C_FUN:                                 Procedures.           (line 18)
   4379 * C_GSYM:                                Global Variables.     (line  6)
   4380 * C_LSYM:                                Stack Variables.      (line 11)
   4381 * C_PSYM:                                Parameters.           (line 12)
   4382 * C_RPSYM:                               Register Parameters.  (line 15)
   4383 * C_RSYM:                                Register Variables.   (line  6)
   4384 * C_STSYM:                               Statics.              (line 31)
   4385 * N_BCOMM:                               Common Blocks.        (line 10)
   4386 * N_BINCL:                               Include Files.        (line 17)
   4387 * N_BROWS:                               N_BROWS.              (line  7)
   4388 * N_BSLINE:                              Line Numbers.         (line 12)
   4389 * N_CATCH:                               N_CATCH.              (line  7)
   4390 * N_DEFD:                                N_DEFD.               (line  7)
   4391 * N_DSLINE:                              Line Numbers.         (line 12)
   4392 * N_ECOML:                               Common Blocks.        (line 17)
   4393 * N_ECOMM:                               Common Blocks.        (line 10)
   4394 * N_EHDECL:                              N_EHDECL.             (line  7)
   4395 * N_EINCL:                               Include Files.        (line 17)
   4396 * N_ENTRY:                               Alternate Entry Points.
   4397                                                                (line  6)
   4398 * N_EXCL:                                Include Files.        (line 17)
   4399 * N_FNAME:                               Procedures.           (line  6)
   4400 * N_FUN, for functions:                  Procedures.           (line  6)
   4401 * N_FUN, for variables:                  Statics.              (line 12)
   4402 * N_GSYM:                                Global Variables.     (line  6)
   4403 * N_GSYM, for functions (Sun acc):       Procedures.           (line  6)
   4404 * N_LBRAC:                               Block Structure.      (line  6)
   4405 * N_LCSYM:                               Statics.              (line 12)
   4406 * N_LENG:                                N_LENG.               (line  7)
   4407 * N_LSYM, for parameter:                 Local Variable Parameters.
   4408                                                                (line 35)
   4409 * N_LSYM, for stack variables:           Stack Variables.      (line 11)
   4410 * N_LSYM, for types:                     Typedefs.             (line  6)
   4411 * N_M2C:                                 N_M2C.                (line  7)
   4412 * N_MAC_DEFINE:                          Macro define and undefine.
   4413                                                                (line 11)
   4414 * N_MAC_UNDEF:                           Macro define and undefine.
   4415                                                                (line 14)
   4416 * N_MAIN:                                Main Program.         (line  6)
   4417 * N_MOD2:                                N_MOD2.               (line  7)
   4418 * N_NBBSS:                               Gould.                (line  9)
   4419 * N_NBDATA:                              Gould.                (line  8)
   4420 * N_NBLCS:                               Gould.                (line 11)
   4421 * N_NBSTS:                               Gould.                (line 10)
   4422 * N_NBTEXT:                              Gould.                (line  7)
   4423 * N_NOMAP:                               N_NOMAP.              (line  7)
   4424 * N_NSYMS:                               N_NSYMS.              (line  7)
   4425 * N_PC:                                  N_PC.                 (line  7)
   4426 * N_PSYM:                                Parameters.           (line 12)
   4427 * N_RBRAC:                               Block Structure.      (line  6)
   4428 * N_ROSYM:                               Statics.              (line 12)
   4429 * N_RSYM:                                Register Variables.   (line  6)
   4430 * N_RSYM, for parameters:                Register Parameters.  (line 15)
   4431 * N_SCOPE:                               N_SCOPE.              (line  7)
   4432 * N_SLINE:                               Line Numbers.         (line  6)
   4433 * N_SO:                                  Source Files.         (line  6)
   4434 * N_SOL:                                 Include Files.        (line 11)
   4435 * N_SSYM:                                N_SSYM.               (line  7)
   4436 * N_STSYM:                               Statics.              (line 12)
   4437 * N_STSYM, for functions (Sun acc):      Procedures.           (line  6)
   4438 
   4439 
   4440 
   4441 Tag Table:
   4442 Node: Top1611
   4443 Node: Overview2658
   4444 Node: Flow4073
   4445 Node: Stabs Format5599
   4446 Node: String Field7161
   4447 Node: C Example12592
   4448 Node: Assembly Code13137
   4449 Node: Program Structure15108
   4450 Node: Main Program15834
   4451 Node: Source Files16395
   4452 Node: Include Files18847
   4453 Node: Line Numbers21512
   4454 Node: Procedures23046
   4455 Node: Nested Procedures28936
   4456 Node: Block Structure30112
   4457 Node: Alternate Entry Points31518
   4458 Node: Constants32251
   4459 Node: Variables35363
   4460 Node: Stack Variables36051
   4461 Node: Global Variables37752
   4462 Node: Register Variables38908
   4463 Node: Common Blocks39730
   4464 Node: Statics40984
   4465 Node: Based Variables43563
   4466 Node: Parameters44948
   4467 Node: Register Parameters46560
   4468 Node: Local Variable Parameters48821
   4469 Node: Reference Parameters51736
   4470 Node: Conformant Arrays52356
   4471 Node: Types53073
   4472 Node: Builtin Types54020
   4473 Node: Traditional Builtin Types55166
   4474 Node: Traditional Integer Types55567
   4475 Node: Traditional Other Types57875
   4476 Node: Builtin Type Descriptors58789
   4477 Node: Negative Type Numbers62289
   4478 Node: Miscellaneous Types68644
   4479 Node: Cross-References70530
   4480 Node: Subranges72205
   4481 Node: Arrays73444
   4482 Node: Strings76669
   4483 Node: Enumerations77731
   4484 Node: Structures80116
   4485 Node: Typedefs82823
   4486 Node: Unions84147
   4487 Node: Function Types85728
   4488 Node: Macro define and undefine87310
   4489 Node: Symbol Tables88887
   4490 Node: Symbol Table Format89339
   4491 Node: Transformations On Symbol Tables90787
   4492 Node: Transformations On Static Variables92141
   4493 Node: Transformations On Global Variables92877
   4494 Node: Stab Section Transformations94120
   4495 Node: Cplusplus95503
   4496 Node: Class Names96086
   4497 Node: Nested Symbols96831
   4498 Node: Basic Cplusplus Types97677
   4499 Node: Simple Classes99237
   4500 Node: Class Instance103531
   4501 Node: Methods104248
   4502 Node: Method Type Descriptor106467
   4503 Node: Member Type Descriptor107667
   4504 Node: Protections108459
   4505 Node: Method Modifiers111549
   4506 Node: Virtual Methods113177
   4507 Node: Inheritance116978
   4508 Node: Virtual Base Classes120674
   4509 Node: Static Members122918
   4510 Node: Stab Types123388
   4511 Node: Non-Stab Symbol Types124012
   4512 Node: Stab Symbol Types125443
   4513 Node: Symbol Descriptors129374
   4514 Node: Type Descriptors132153
   4515 Node: Expanded Reference135365
   4516 Node: N_PC136783
   4517 Node: N_NSYMS137151
   4518 Node: N_NOMAP137392
   4519 Node: N_M2C137698
   4520 Node: N_BROWS138132
   4521 Node: N_DEFD138415
   4522 Node: N_EHDECL138872
   4523 Node: N_MOD2139123
   4524 Node: N_CATCH139361
   4525 Node: N_SSYM139855
   4526 Node: N_SCOPE140140
   4527 Node: Gould140330
   4528 Node: N_LENG141322
   4529 Node: Questions141550
   4530 Node: Stab Sections143194
   4531 Node: Stab Section Basics143792
   4532 Node: ELF Linker Relocation147133
   4533 Node: GNU Free Documentation License150543
   4534 Node: Symbol Types Index172977
   4535 
   4536 End Tag Table
   4537