\input texinfo
@setfilename stabs.info
+@setchapternewpage odd
+@settitle STABS
+
+@c man begin INCLUDE
+@include gdb-cfg.texi
+@c man end
@c @finalout
-@ifinfo
-@format
-START-INFO-DIR-ENTRY
-* Stabs: (stabs). The "stabs" debugging information format.
-END-INFO-DIR-ENTRY
-@end format
-@end ifinfo
+@c This is a dir.info fragment to support semi-automated addition of
+@c manuals to an info tree.
+@dircategory Software development
+@direntry
+* Stabs: (stabs). The "stabs" debugging information format.
+@end direntry
-@ifinfo
-This document describes the stabs debugging symbol tables.
-
-Copyright 1992, 93, 94, 95, 97, 1998 Free Software Foundation, Inc.
+@copying
+Copyright @copyright{} 1992-2019 Free Software Foundation, Inc.
Contributed by Cygnus Support. Written by Julia Menapace, Jim Kingdon,
and David MacKenzie.
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
+Texts. A copy of the license is included in the section entitled ``GNU
+Free Documentation License''.
+@end copying
-@ignore
-Permission is granted to process this file through Tex and print the
-results, provided the printed document carries copying permission
-notice identical to this one except for the removal of this paragraph
-(this paragraph not being relevant to the printed manual).
+@ifnottex
+This document describes the stabs debugging symbol tables.
-@end ignore
-Permission is granted to copy or distribute modified versions of this
-manual under the terms of the GPL (for which purpose this text may be
-regarded as a program in the language TeX).
-@end ifinfo
+@insertcopying
+@end ifnottex
-@setchapternewpage odd
-@settitle STABS
@titlepage
@title The ``stabs'' debug format
@author Julia Menapace, Jim Kingdon, David MacKenzie
@author Cygnus Support
@page
@tex
-\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
+\def\$#1${{#1}} % Kludge: collect RCS revision info without $...$
\xdef\manvers{\$Revision$} % For use in headers, footers too
{\parskip=0pt
\hfill Cygnus Support\par
@end tex
@vskip 0pt plus 1filll
-Copyright @copyright{} 1992, 93, 94, 95, 97, 1998 Free Software Foundation, Inc.
-Contributed by Cygnus Support.
-
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
+@insertcopying
@end titlepage
-@ifinfo
+@ifnottex
@node Top
@top The "stabs" representation of debugging information
* Constants:: Constants
* Variables::
* Types:: Type definitions
+* Macro define and undefine:: Representation of #define and #undef
* Symbol Tables:: Symbol information in symbol tables
* Cplusplus:: Stabs specific to C++
* Stab Types:: Symbol types in a.out files
* Symbol Descriptors:: Table of symbol descriptors
* Type Descriptors:: Table of type descriptors
* Expanded Reference:: Reference information by stab type
-* Questions:: Questions and anomolies
+* Questions:: Questions and anomalies
* Stab Sections:: In some object file formats, stabs are
in sections.
+* GNU Free Documentation License:: The license for this documentation
* Symbol Types Index:: Index of symbolic stab symbol type names.
@end menu
-@end ifinfo
+@end ifnottex
+@contents
@node Overview
@chapter Overview of Stabs
additionally permit a @var{type-number} to be a pair
(@var{file-number},@var{filetype-number}) (the parentheses appear in the
string, and serve to distinguish the two cases). The @var{file-number}
-is a number starting with 1 which is incremented for each seperate
-source file in the compilation (e.g., in C, each header file gets a
-different number). The @var{filetype-number} is a number starting with
+is 0 for the base source file, 1 for the first included file, 2 for the
+next, and so on. The @var{filetype-number} is a number starting with
1 which is incremented for each new type defined in the file.
(Separating the file number and the type number permits the
@code{N_BINCL} optimization to succeed more often; see @ref{Include
are any number of type attributes. Each one starts with @samp{@@} and
ends with @samp{;}. Debuggers, including AIX's dbx and GDB 4.10, skip
any type attributes they do not recognize. GDB 4.9 and other versions
-of dbx may not do this. Because of a conflict with C++
+of dbx may not do this. Because of a conflict with C@t{++}
(@pxref{Cplusplus}), new attributes should not be defined which begin
with a digit, @samp{(}, or @samp{-}; GDB may be unable to distinguish
-those from the C++ type descriptor @samp{@@}. The attributes are:
+those from the C@t{++} type descriptor @samp{@@}. The attributes are:
@table @code
@item a@var{boundary}
or a bitstring instead of a set. It doesn't change the layout of the
data being represented, but does enable the debugger to know which type
it is.
+
+@item V
+Indicate that this type is a vector instead of an array. The only
+major difference between vectors and arrays is that vectors are
+passed by value instead of by reference (vector coprocessor extension).
+
@end table
All of this can make the string field quite long. All versions of GDB,
value of the symbol is the start address of the portion of the
text section corresponding to that file.
-With the Sun Solaris2 compiler, the desc field contains a
-source-language code.
-@c Do the debuggers use it? What are the codes? -djm
+Some compilers use the desc field to indicate the language of the
+source file. Sun's compilers started this usage, and the first
+constants are derived from their documentation. Languages added
+by gcc/gdb start at 0x32 to avoid conflict with languages Sun may
+add in the future. A desc field with a value 0 indicates that no
+language has been specified via this mechanism.
+
+@table @asis
+@item @code{N_SO_AS} (0x1)
+Assembly language
+@item @code{N_SO_C} (0x2)
+K&R traditional C
+@item @code{N_SO_ANSI_C} (0x3)
+ANSI C
+@item @code{N_SO_CC} (0x4)
+C++
+@item @code{N_SO_FORTRAN} (0x5)
+Fortran
+@item @code{N_SO_PASCAL} (0x6)
+Pascal
+@item @code{N_SO_FORTRAN90} (0x7)
+Fortran90
+@item @code{N_SO_OBJC} (0x32)
+Objective-C
+@item @code{N_SO_OBJCPLUS} (0x33)
+Objective-C++
+@end table
Some compilers (for example, GCC2 and SunOS4 @file{/bin/cc}) also
include the directory in which the source was compiled, in a second
@code{N_SO} symbol preceding the one containing the file name. This
symbol can be distinguished by the fact that it ends in a slash. Code
-from the @code{cfront} C++ compiler can have additional @code{N_SO} symbols for
+from the @code{cfront} C@t{++} compiler can have additional @code{N_SO} symbols for
nonexistent source files after the @code{N_SO} for the real source file;
these are believed to contain no useful information.
If the linker detects that two source files have identical stabs between
an @code{N_BINCL} and @code{N_EINCL} pair (as will generally be the case
for a header file), then it only puts out the stabs once. Each
-additional occurance is replaced by an @code{N_EXCL} symbol. I believe
+additional occurrence is replaced by an @code{N_EXCL} symbol. I believe
the GNU linker and the Sun (both SunOS4 and Solaris) linker are the only
ones which supports this feature.
.stabn 224,0,0,LBE2 # @r{224 is N_RBRAC}
@end example
-@xref{Procedures} for more information on the @code{N_FUN} stab, and
+See @ref{Procedures} for more information on the @code{N_FUN} stab, and
@ref{Block Structure} for more information on the @code{N_LBRAC} and
@code{N_RBRAC} stabs.
plans to have the linker stop relocating stabs; I suspect that their the
debugger gets the address from the corresponding ELF (not stab) symbol.
I'm not sure how to find which symbol of that name is the right one.
-The clean way to do all this would be to have a the value of a symbol
+The clean way to do all this would be to have the value of a symbol
descriptor @samp{S} symbol be an offset relative to the start of the
file, just like everything else, but that introduces obvious
compatibility problems. For more information on linker stab relocation,
would need to know about the type---in some cases they merely specify
enough information to distinguish the type from other types.
-The traditional way to define builtin types is convolunted, so new ways
+The traditional way to define builtin types is convoluted, so new ways
have been invented to describe them. Sun's @code{acc} uses special
builtin type descriptors (@samp{b} and @samp{R}), and IBM uses negative
type numbers. GDB accepts all three ways, as of version 4.8; dbx just
formats. The following sections describe each of these formats.
@menu
-* Traditional Builtin Types:: Put on your seatbelts and prepare for kludgery
+* Traditional Builtin Types:: Put on your seat belts and prepare for kludgery
* Builtin Type Descriptors:: Builtin types with special type descriptors
* Negative Type Numbers:: Builtin types using negative type numbers
@end menu
These are for complex numbers. A comment in the GDB source describes
them as Fortran @code{complex}, @code{double complex}, and
@code{complex*16}, respectively, but what does that mean? (i.e., Single
-precision? Double precison?).
+precision? Double precision?).
@item 6 (NF_LDOUBLE)
Long double. This should probably only be used for Sun format
@samp{s} for a structure tag, @samp{u} for a union tag, or @samp{e} for
a enumerator tag, followed by the name of the tag, followed by @samp{:}.
If the name contains @samp{::} between a @samp{<} and @samp{>} pair (for
-C++ templates), such a @samp{::} does not end the name---only a single
+C@t{++} templates), such a @samp{::} does not end the name---only a single
@samp{:} ends the name; see @ref{Nested Symbols}.
For example, the following C declarations:
the argument list.
@item a @var{register-number}
-The bound is pased by reference in register number
+The bound is passed by reference in register number
@var{register-number}.
@item t @var{register-number}
The following source code declares a structure tag and defines an
instance of the structure in global scope. Then a @code{typedef} equates the
-structure tag with a new type. Seperate stabs are generated for the
+structure tag with a new type. Separate stabs are generated for the
structure tag, the structure @code{typedef}, and the structure instance. The
-stabs for the tag and the @code{typedef} are emited when the definitions are
+stabs for the tag and the @code{typedef} are emitted when the definitions are
encountered. Since the structure elements are not initialized, the
stab and code for the structure variable itself is located at the end
of the program in the bss section.
Following the @samp{s} type descriptor is the number of bytes the
structure occupies, followed by a description of each structure element.
-The structure element descriptions are of the form @var{name:type, bit
-offset from the start of the struct, number of bits in the element}.
+The structure element descriptions are of the form
+@samp{@var{name}:@var{type}, @var{bit offset from the start of the
+struct}, @var{number of bits in the element}}.
@c FIXME: phony line break. Can probably be fixed by using an example
@c with fewer fields.
element description is a simple type reference. The other two structure
elements are new types. In this case there is a type definition
embedded after the @samp{@var{name}:}. The type definition for the
-array element looks just like a type definition for a standalone array.
+array element looks just like a type definition for a stand-alone array.
The @code{s_next} field is a pointer to the same kind of structure that
the field is an element of. So the definition of structure type 16
contains a type definition for an element which is a pointer to type 16.
-If a field is a static member (this is a C++ feature in which a single
+If a field is a static member (this is a C@t{++} feature in which a single
variable appears to be a field of every structure of a given type) it
still starts out with the field name, a colon, and the type, but then
instead of a comma, bit position, comma, and bit size, there is a colon
followed by the name of the variable which each such field refers to.
-If the structure has methods (a C++ feature), they follow the non-method
+If the structure has methods (a C@t{++} feature), they follow the non-method
fields; see @ref{Cplusplus}.
@node Typedefs
the procedure in which it is defined. The stab type is @code{N_LSYM}. This
would seem to imply that the union type is file scope, like the struct
type @code{s_tag}. This is not true. The contents and position of the stab
-for @code{u_type} do not convey any infomation about its procedure local
+for @code{u_type} do not convey any information about its procedure local
scope.
@c FIXME: phony line break. Can probably be fixed by using an example
descriptor @samp{u}, following the @samp{23=} of the type definition,
narrows it down to a union type definition. Following the @samp{u} is
the number of bytes in the union. After that is a list of union element
-descriptions. Their format is @var{name:type, bit offset into the
-union, number of bytes for the element;}.
+descriptions. Their format is @samp{@var{name}:@var{type}, @var{bit
+offset into the union}, @var{number of bytes for the element};}.
The stab for the union variable is:
The variable defines a new type, 24, which is a pointer to another new
type, 25, which is a function returning @code{int}.
+@node Macro define and undefine
+@chapter Representation of #define and #undef
+
+This section describes the stabs support for macro define and undefine
+information, supported on some systems. (e.g., with @option{-g3}
+@option{-gstabs} when using GCC).
+
+A @code{#define @var{macro-name} @var{macro-body}} is represented with
+an @code{N_MAC_DEFINE} stab with a string field of
+@code{@var{macro-name} @var{macro-body}}.
+@findex N_MAC_DEFINE
+
+An @code{#undef @var{macro-name}} is represented with an
+@code{N_MAC_UNDEF} stabs with a string field of simply
+@code{@var{macro-name}}.
+@findex N_MAC_UNDEF
+
+For both @code{N_MAC_DEFINE} and @code{N_MAC_UNDEF}, the desc field is
+the line number within the file where the corresponding @code{#define}
+or @code{#undef} occurred.
+
+For example, the following C code:
+
+@example
+ #define NONE 42
+ #define TWO(a, b) (a + (a) + 2 * b)
+ #define ONE(c) (c + 19)
+
+ main(int argc, char *argv[])
+ @{
+ func(NONE, TWO(10, 11));
+ func(NONE, ONE(23));
+
+ #undef ONE
+ #define ONE(c) (c + 23)
+
+ func(NONE, ONE(-23));
+
+ return (0);
+ @}
+
+ int global;
+
+ func(int arg1, int arg2)
+ @{
+ global = arg1 + arg2;
+ @}
+@end example
+
+@noindent
+produces the following stabs (as well as many others):
+
+@example
+ .stabs "NONE 42",54,0,1,0
+ .stabs "TWO(a,b) (a + (a) + 2 * b)",54,0,2,0
+ .stabs "ONE(c) (c + 19)",54,0,3,0
+ .stabs "ONE",58,0,10,0
+ .stabs "ONE(c) (c + 23)",54,0,11,0
+@end example
+
+@noindent
+NOTE: In the above example, @code{54} is @code{N_MAC_DEFINE} and
+@code{58} is @code{N_MAC_UNDEF}.
+
@node Symbol Tables
@chapter Symbol Information in Symbol Tables
@end example
@node Cplusplus
-@chapter GNU C++ Stabs
+@chapter GNU C@t{++} Stabs
@menu
* Class Names:: C++ class names are both tags and typedefs.
* Protections::
* Method Modifiers::
* Virtual Methods::
-* Inheritence::
+* Inheritance::
* Virtual Base Classes::
* Static Members::
@end menu
@node Class Names
-@section C++ Class Names
+@section C@t{++} Class Names
-In C++, a class name which is declared with @code{class}, @code{struct},
+In C@t{++}, a class name which is declared with @code{class}, @code{struct},
or @code{union}, is not only a tag, as in C, but also a type name. Thus
there should be stabs with both @samp{t} and @samp{T} symbol descriptors
(@pxref{Typedefs}).
@samp{T} symbol descriptor is followed by @samp{t}, then the stab
defines both a type name and a tag.
-For example, the C++ code
+For example, the C@t{++} code
@example
struct foo @{int x;@};
@node Nested Symbols
@section Defining a Symbol Within Another Type
-In C++, a symbol (such as a type name) can be defined within another type.
+In C@t{++}, a symbol (such as a type name) can be defined within another type.
@c FIXME: Needs example.
In stabs, this is sometimes represented by making the name of a symbol
symbol descriptor, and @samp{5=*6} is the type information.
@node Basic Cplusplus Types
-@section Basic Types For C++
+@section Basic Types For C@t{++}
<< the examples that follow are based on a01.C >>
-C++ adds two more builtin types to the set defined for C. These are
+C@t{++} adds two more builtin types to the set defined for C. These are
the unknown type and the vtable record type. The unknown type, type
16, is defined in terms of itself like the void type.
<< In boilerplate $vtbl_ptr_type, what are the fields delta,
index, and delta2 used for? >>
-This basic type is present in all C++ programs even if there are no
+This basic type is present in all C@t{++} programs even if there are no
virtual methods defined.
@display
@node Simple Classes
@section Simple Class Definition
-The stabs describing C++ language features are an extension of the
-stabs describing C. Stabs representing C++ class types elaborate
+The stabs describing C@t{++} language features are an extension of the
+stabs describing C. Stabs representing C@t{++} class types elaborate
extensively on the stab format used to describe structure types in C.
Stabs representing class type variables look just like stabs
representing C language variables.
that the class is defined at file scope. If it were, then the @code{N_LSYM}
would signify a local variable.
-A stab describing a C++ class type is similar in format to a stab
+A stab describing a C@t{++} class type is similar in format to a stab
describing a C struct, with each class member shown as a field in the
structure. The part of the struct format describing fields is
-expanded to include extra information relevent to C++ class members.
+expanded to include extra information relevant to C@t{++} class members.
In addition, if the class has multiple base classes or virtual
functions the struct format outside of the field parts is also
augmented.
-In this simple example the field part of the C++ class stab
+In this simple example the field part of the C@t{++} class stab
representing member data looks just like the field part of a C struct
stab. The section on protections describes how its format is
sometimes extended for member data.
-The field part of a C++ class stab representing a member function
+The field part of a C@t{++} class stab representing a member function
differs substantially from the field part of a C struct stab. It
still begins with @samp{name:} but then goes on to define a new type number
for the member function, describe its return type, its argument types,
occur in the @var{operator-name} string.
The next part of the method description represents the arguments to the
-method, preceeded by a colon and ending with a semi-colon. The types of
+method, preceded by a colon and ending with a semi-colon. The types of
the arguments are expressed in the same way argument types are expressed
-in C++ name mangling. In this example an @code{int} and a @code{char}
+in C@t{++} name mangling. In this example an @code{int} and a @code{char}
map to @samp{ic}.
This is followed by a number, a letter, and an asterisk or period,
@node Class Instance
@section Class Instance
-As shown above, describing even a simple C++ class definition is
+As shown above, describing even a simple C@t{++} class definition is
accomplished by massively extending the stab format used in C to
describe structure types. However, once the class is defined, C stabs
with no modifications can be used to describe class instances. The
@node Methods
@section Method Definition
-The class definition shown above declares Ameth. The C++ source below
+The class definition shown above declares Ameth. The C@t{++} source below
defines Ameth:
@example
@c GDB. But gpcompare.texi doesn't seem to be in the FSF GCC.
@example
-.stabs "name:symbol_desriptor(global function)return_type(int)",
+.stabs "name:symbol_descriptor(global function)return_type(int)",
N_FUN, NIL, NIL, code_addr_of_method_start
.stabs "Ameth__5baseAic:F1",36,0,0,_Ameth__5baseAic
Here is the stab for the @code{this} pointer implicit argument. The
name of the @code{this} pointer is always @code{this}. Type 19, the
@code{this} pointer is defined as a pointer to type 20, @code{baseA},
-but a stab defining @code{baseA} has not yet been emited. Since the
-compiler knows it will be emited shortly, here it just outputs a cross
+but a stab defining @code{baseA} has not yet been emitted. Since the
+compiler knows it will be emitted shortly, here it just outputs a cross
reference to the undefined symbol, by prefixing the symbol name with
@samp{xs}.
@node Member Type Descriptor
@section The @samp{@@} Type Descriptor
-The @samp{@@} type descriptor is for a member (class and variable) type.
-It is followed by type information for the offset basetype, a comma, and
-type information for the type of the field being pointed to. (FIXME:
-this is acknowledged to be gibberish. Can anyone say what really goes
-here?).
+The @samp{@@} type descriptor is used for a
+pointer-to-non-static-member-data type. It is followed
+by type information for the class (or union), a comma, and type
+information for the member data.
+
+The following C@t{++} source:
+
+@smallexample
+typedef int A::*int_in_a;
+@end smallexample
+
+generates the following stab:
+
+@smallexample
+.stabs "int_in_a:t20=21=@@19,1",128,0,0,0
+@end smallexample
Note that there is a conflict between this and type attributes
(@pxref{String Field}); both use type descriptor @samp{@@}.
-Fortunately, the @samp{@@} type descriptor used in this C++ sense always
+Fortunately, the @samp{@@} type descriptor used in this C@t{++} sense always
will be followed by a digit, @samp{(}, or @samp{-}, and type attributes
never start with those things.
@section Protections
In the simple class definition shown above all member data and
-functions were publicly accessable. The example that follows
-contrasts public, protected and privately accessable fields and shows
-how these protections are encoded in C++ stabs.
+functions were publicly accessible. The example that follows
+contrasts public, protected and privately accessible fields and shows
+how these protections are encoded in C@t{++} stabs.
If the character following the @samp{@var{field-name}:} part of the
string is @samp{/}, then the next character is the visibility. @samp{0}
Visibility @samp{9} is not supported by GDB 4.11; this should be fixed
in the next GDB release.
-The following C++ source:
+The following C@t{++} source:
@example
class vis @{
(@samp{2}) and offset and size @samp{,32,8;}. The @code{pub} field has
type float (@samp{12}), and offset and size @samp{,64,32;}.
-Protections for member functions are signified by one digit embeded in
+Protections for member functions are signified by one digit embedded in
the field part of the stab describing the method. The digit is 0 if
-private, 1 if protected and 2 if public. Consider the C++ class
+private, 1 if protected and 2 if public. Consider the C@t{++} class
definition below:
@example
meth_name::type_def(22)=sym_desc(method)returning(int);
:args(int);protection(private)modifier(normal)virtual(no);
meth_name::type_def(23)=sym_desc(method)returning(char);
- :args(char);protection(protected)modifier(normal)virual(no);
+ :args(char);protection(protected)modifier(normal)virtual(no);
meth_name::type_def(24)=sym_desc(method)returning(float);
:args(float);protection(public)modifier(normal)virtual(no);;",
N_LSYM,NIL,NIL,NIL
meth_name(VolatileMeth)::type_def(22)=sym_desc(method)
returning(char);:arg(char);protection(public)modifier(volatile)virt(no)
meth_name(ConstVolMeth)::type_def(23)=sym_desc(method)
- returning(float);:arg(float);protection(public)modifer(const volatile)
+ returning(float);:arg(float);protection(public)modifier(const volatile)
virtual(no);;", @dots{}
@end display
occupying 32 bits.
The second field in the class struct is not explicitly defined by the
-C++ class definition but is implied by the fact that the class
+C@t{++} class definition but is implied by the fact that the class
contains a virtual method. This field is the vtable pointer. The
name of the vtable pointer field starts with @samp{$vf} and continues with a
type reference to the class it is part of. In this example the type
Type 22 is the vtable itself, which is defined as an array, indexed by
a range of integers between 0 and 1, and whose elements are of type
-17. Type 17 was the vtable record type defined by the boilerplate C++
+17. Type 17 was the vtable record type defined by the boilerplate C@t{++}
type definitions, as shown earlier.
The bit offset of the vtable pointer field is 32. The number of bits
semi-colon.
The second number is a type reference to the first base class in the
-inheritence hierarchy defining the virtual member function. In this
+inheritance hierarchy defining the virtual member function. In this
case the class stab describes a base class so the virtual function is
not overriding any other definition of the method. Therefore the
reference is to the type number of the class that the stab is
For classes containing virtual functions the very last section of the
string part of the stab holds a type reference to the first base
-class. This is preceeded by @samp{~%} and followed by a final semi-colon.
+class. This is preceded by @samp{~%} and followed by a final semi-colon.
@display
.stabs "class_name(A):type_def(20)=sym_desc(struct)struct_bytes(8)
A_virt::23=##1;:i;2A*-2147483647;20;;;~%20;",128,0,0,0
@end example
-@node Inheritence
-@section Inheritence
+@node Inheritance
+@section Inheritance
-Stabs describing C++ derived classes include additional sections that
-describe the inheritence hierarchy of the class. A derived class stab
+Stabs describing C@t{++} derived classes include additional sections that
+describe the inheritance hierarchy of the class. A derived class stab
also encodes the number of base classes. For each base class it tells
-if the base class is virtual or not, and if the inheritence is private
+if the base class is virtual or not, and if the inheritance is private
or public. It also gives the offset into the object of the portion of
the object corresponding to each base class.
-This additional information is embeded in the class stab following the
+This additional information is embedded in the class stab following the
number of bytes in the struct. First the number of base classes
appears bracketed by an exclamation point and a comma.
Then for each base type there repeats a series: a virtual character, a
-visibilty character, a number, a comma, another number, and a
+visibility character, a number, a comma, another number, and a
semi-colon.
The virtual character is @samp{1} if the base class is virtual and
@display
.stabs "derived_class_name:symbol_descriptors(struct tag&type)=
type_descriptor(struct)struct_bytes(32)!num_bases(3),
- base_virtual(no)inheritence_public(no)base_offset(0),
+ base_virtual(no)inheritance_public(no)base_offset(0),
base_class_type_ref(A);
- base_virtual(yes)inheritence_public(no)base_offset(NIL),
+ base_virtual(yes)inheritance_public(no)base_offset(NIL),
base_class_type_ref(B);
- base_virtual(no)inheritence_public(yes)base_offset(64),
+ base_virtual(no)inheritance_public(yes)base_offset(64),
base_class_type_ref(C); @dots{}
@end display
@node Virtual Base Classes
@section Virtual Base Classes
-A derived class object consists of a concatination in memory of the data
+A derived class object consists of a concatenation in memory of the data
areas defined by each base class, starting with the leftmost and ending
with the rightmost in the list of base classes. The exception to this
-rule is for virtual inheritence. In the example above, class @code{D}
+rule is for virtual inheritance. In the example above, class @code{D}
inherits virtually from base class @code{B}. This means that an
instance of a @code{D} object will not contain its own @code{B} part but
merely a pointer to a @code{B} part, known as a virtual base pointer.
@item 0x34 N_NOMAP
No DST map; see @ref{N_NOMAP}.
+@item 0x36 N_MAC_DEFINE
+Name and body of a @code{#define}d macro; see @ref{Macro define and undefine}.
+
@c FIXME: describe this solaris feature in the body of the text (see
@c comments in include/aout/stab.def).
@item 0x38 N_OBJ
Object file (Solaris2).
+@item 0x3a N_MAC_UNDEF
+Name of an @code{#undef}ed macro; see @ref{Macro define and undefine}.
+
@c See include/aout/stab.def for (a little) more info.
@item 0x3c N_OPT
Debugger options (Solaris2).
Function start/body/end line numbers (Solaris2).
@item 0x50 N_EHDECL
-GNU C++ exception variable; see @ref{N_EHDECL}.
+GNU C@t{++} exception variable; see @ref{N_EHDECL}.
@item 0x50 N_MOD2
Modula2 info "for imc" (according to Ultrix V4.0); see @ref{N_MOD2}.
@item 0x54 N_CATCH
-GNU C++ @code{catch} clause; see @ref{N_CATCH}.
+GNU C@t{++} @code{catch} clause; see @ref{N_CATCH}.
@item 0x60 N_SSYM
Structure of union element; see @ref{N_SSYM}.
Variable on the stack; see @ref{Stack Variables}.
@item :
-C++ nested symbol; see @xref{Nested Symbols}
+C@t{++} nested symbol; see @xref{Nested Symbols}.
@item a
Parameter passed by reference in register; see @ref{Reference Parameters}.
@item C
Conformant array bound (Pascal, maybe other languages); @ref{Conformant
-Arrays}. Name of a caught exception (GNU C++). These can be
+Arrays}. Name of a caught exception (GNU C@t{++}). These can be
distinguished because the latter uses @code{N_CATCH} and the former uses
another symbol type.
Reference to builtin type; see @ref{Negative Type Numbers}.
@item #
-Method (C++); see @ref{Method Type Descriptor}.
+Method (C@t{++}); see @ref{Method Type Descriptor}.
@item *
Pointer; see @ref{Miscellaneous Types}.
@item &
-Reference (C++).
+Reference (C@t{++}).
@item @@
Type Attributes (AIX); see @ref{String Field}. Member (class and variable)
-type (GNU C++); see @ref{Member Type Descriptor}.
+type (GNU C@t{++}); see @ref{Member Type Descriptor}.
@item a
Array; see @ref{Arrays}.
@item b
Pascal space type (AIX); see @ref{Miscellaneous Types}. Builtin integer
type (Sun); see @ref{Builtin Type Descriptors}. Const and volatile
-qualfied type (OS9000).
+qualified type (OS9000).
@item B
Volatile-qualified type; see @ref{Miscellaneous Types}.
Cross-reference; see @ref{Cross-References}.
@item Y
-Used by IBM's xlC C++ compiler (for structures, I think).
+Used by IBM's xlC C@t{++} compiler (for structures, I think).
@item z
gstring; see @ref{Strings}.
@deffn @code{.stabs} N_EHDECL
@findex N_EHDECL
-GNU C++ exception variable <<?>>.
+GNU C@t{++} exception variable <<?>>.
"@var{string} is variable name"
@deffn @code{.stabn} N_CATCH
@findex N_CATCH
-GNU C++ @code{catch} clause
+GNU C@t{++} @code{catch} clause
-GNU C++ @code{catch} clause. The value is its address. The desc field
+GNU C@t{++} @code{catch} clause. The value is its address. The desc field
is nonzero if this entry is immediately followed by a @code{CAUGHT} stab
saying what exception was caught. Multiple @code{CAUGHT} stabs means
that multiple exceptions can be caught here. If desc is 0, it means all
structures, unions, and enums (symbol descriptor @samp{T}) and typedefs
(symbol descriptor @samp{t}) defined at file scope from types defined locally
to a procedure or other more local scope. They all use the @code{N_LSYM}
-stab type. Types defined at procedure scope are emited after the
+stab type. Types defined at procedure scope are emitted after the
@code{N_RBRAC} of the preceding function and before the code of the
procedure in which they are defined. This is exactly the same as
types defined in the source file between the two procedure bodies.
-GDB overcompensates by placing all types in block #1, the block for
+GDB over-compensates by placing all types in block #1, the block for
symbols of file scope. This is true for default, @samp{-ansi} and
@samp{-traditional} compiler options. (Bugs gcc/1063, gdb/1066.)
@appendixsec Having the Linker Relocate Stabs in ELF
This section describes some Sun hacks for Stabs in ELF; it does not
-apply to COFF or SOM.
+apply to COFF or SOM. While @value{GDBN} no longer supports this hack
+for Sun Stabs in ELF, this section is kept to document the issue.
To keep linking fast, you don't want the linker to have to relocate very
many stabs. Making sure this is done for @code{N_SLINE},
Finding the correct @code{Bbss.bss}, etc., symbol is difficult, because
the linker simply concatenates the @code{.stab} sections from each
@file{.o} file without including any information about which part of a
-@code{.stab} section comes from which @file{.o} file. The way GDB does
-this is to look for an ELF @code{STT_FILE} symbol which has the same
+@code{.stab} section comes from which @file{.o} file. The way GDB use to
+do this is to look for an ELF @code{STT_FILE} symbol which has the same
name as the last component of the file name from the @code{N_SO} symbol
in the stabs (for example, if the file name is @file{../../gdb/main.c},
it looks for an ELF @code{STT_FILE} symbol named @code{main.c}). This
solves the problem of having to associate the ELF and stab symbols.
However, no one has yet designed or implemented such a scheme.
+@node GNU Free Documentation License
+@appendix GNU Free Documentation License
+@include fdl.texi
+
@node Symbol Types Index
@unnumbered Symbol Types Index
@printindex fn
-@contents
@bye
projects / deliverable / binutils-gdb.git / blobdiff