* stabs.texinfo (XCOFF-differences): Remove references to

	non-existent types N_DECL and N_RPSYM.

	* stabs.texinfo (String Field): Say that type attributes bug is
	fixed in GDB 4.10, since it is.

	* stabs.texinfo: Clean up djm cleanups, and more cleanups of my own.

2 files changed, 174 insertions, 152 deletions

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index e04e08e..681ec0e 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,17 @@
+Sun Aug 22 12:15:18 1993  Jim Kingdon  (kingdon@lioth.cygnus.com)
+
+	* stabs.texinfo (XCOFF-differences): Remove references to
+	non-existent types N_DECL and N_RPSYM.
+
+	* stabs.texinfo (String Field): Say that type attributes bug is
+	fixed in GDB 4.10, since it is.
+
+	* stabs.texinfo: Clean up djm cleanups, and more cleanups of my own.
+
+Sat Aug 21 04:32:28 1993  David MacKenzie  (djm@cygnus.com)
+
+	* stabs.texinfo: Formatting cleanups.
+
 Fri Aug 20 20:49:53 1993  Jim Kingdon  (kingdon@lioth.cygnus.com)
 
 	* stabs.texinfo: When explaining the n_type of a stab, standardize
diff --git a/gdb/doc/stabs.texinfo b/gdb/doc/stabs.texinfo
index d831a41..c997150 100644
--- a/gdb/doc/stabs.texinfo
+++ b/gdb/doc/stabs.texinfo
@@ -101,19 +101,18 @@ the University of California at Berkeley, for the @code{pdx} Pascal
 debugger; the format has spread widely since then.
 
 This document is one of the few published sources of documentation on
-stabs.  It is believed to be completely comprehensive for stabs used by
-C.  The lists of symbol descriptors (@pxref{Symbol Descriptors}) and
-type descriptors (@pxref{Type Descriptors}) are believed to be completely
-comprehensive.  There are known to be stabs for C++ and COBOL which are
-poorly documented here.  Stabs specific to other languages (e.g., Pascal,
-Modula-2) are probably not as well documented as they should be.
-
-Other sources of information on stabs are @cite{dbx and dbxtool
-interfaces}, 2nd edition, by Sun, circa 1988, and @cite{AIX Version 3.2
-Files Reference}, Fourth Edition, September 1992, "dbx Stabstring
-Grammar" in the a.out section, page 2-31.  This document is believed to
-incorporate the information from those two sources except where it
-explictly directs you to them for more information.
+stabs.  It is believed to be comprehensive for stabs used by C.  The
+lists of symbol descriptors (@pxref{Symbol Descriptors}) and type
+descriptors (@pxref{Type Descriptors}) are believed to be completely
+comprehensive.  Stabs for COBOL-specific features and for variant
+records (used by Pascal and Modula-2) are poorly documented here.
+
+Other sources of information on stabs are @cite{Dbx and Dbxtool
+Interfaces}, 2nd edition, by Sun, 1988, and @cite{AIX Version 3.2 Files
+Reference}, Fourth Edition, September 1992, "dbx Stabstring Grammar" in
+the a.out section, page 2-31.  This document is believed to incorporate
+the information from those two sources except where it explictly directs
+you to them for more information.
 
 @menu
 * Flow::			Overview of debugging information flow
@@ -207,7 +206,7 @@ The overall format is of the @var{string} field is:
 @var{name} can be omitted, which means the stab represents an unnamed
 object.  For example, @samp{:t10=*2} defines type 10 as a pointer to
 type 2, but does not give the type a name.  Omitting the @var{name}
-field is supported by AIX DBX and GDB after about version 4.8, but not
+field is supported by AIX dbx and GDB after about version 4.8, but not
 other debuggers.  GCC sometimes uses a single space as the name instead
 of omitting the name altogether; apparently that is supported by most
 debuggers.
@@ -240,10 +239,9 @@ Descriptors}, for a list of
 
 There is an AIX extension for type attributes.  Following the @samp{=}
 is any number of type attributes.  Each one starts with @samp{@@} and
-ends with @samp{;}.  Debuggers, including AIX's DBX, skip any type
-attributes they do not recognize.  GDB 4.9 does not do this---it will
-ignore the entire symbol containing a type attribute.  Hopefully this
-will be fixed in the next GDB release.  Because of a conflict with C++
+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++
 (@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:
@@ -267,9 +265,9 @@ expense of speed.
 @end table
 
 All this can make the @var{string} field quite long.  All
-versions of GDB, and some versions of DBX, can handle arbitrarily long
-strings.  But many versions of DBX cretinously limit the strings to
-about 80 characters, so compilers which must work with such DBX's need
+versions of GDB, and some versions of dbx, can handle arbitrarily long
+strings.  But many versions of dbx cretinously limit the strings to
+about 80 characters, so compilers which must work with such dbx's need
 to split the @code{.stabs} directive into several @code{.stabs}
 directives.  Each stab duplicates exactly all but the
 @var{string} field.  The @var{string} field of
@@ -360,9 +358,6 @@ types used to describe C language source files.
 @node Program structure
 @chapter Encoding for the structure of the program
 
-For the numeric values of the symbolic stab types, see @ref{Stab Types}.
-For a reference to them, see @ref{Expanded reference}.
-
 @menu
 * Main Program::		Indicate what the main program is
 * Source Files::		The path and name of the source file
@@ -474,7 +469,7 @@ since GDB 3.5.
 
 XCOFF uses COFF line numbers instead, which are outside the scope of
 this document, ammeliorated by adequate marking of include files
-(@pxref{Source Files}).
+(@pxref{Include Files}).
 
 For single source lines that generate discontiguous code, such as flow
 of control statements, there may be more than one line number entry for
@@ -486,14 +481,14 @@ start of each code range, each with the same line number.
 
 All of the following stabs use the @code{N_FUN} symbol type.
 
-A function is represented by an @samp{F} symbol descriptor (@var{desc}
-field) for a global (extern) function, and @samp{f} for a static (local)
-function.  The next @code{N_SLINE} symbol can be used to find the line
-number of the start of the function.  The value field is the address of
-the start of the function (absolute for @code{a.out}; relative to the
-start of the file for Sun's stabs-in-ELF).  The type information of the
-stab represents the return type of the function; thus @samp{foo:f5}
-means that foo is a function returning type 5.
+A function is represented by an @samp{F} symbol descriptor for a global
+(extern) function, and @samp{f} for a static (local) function.  The next
+@code{N_SLINE} symbol can be used to find the line number of the start
+of the function.  The value field is the address of the start of the
+function (absolute for @code{a.out}; relative to the start of the file
+for Sun's stabs-in-ELF).  The type information of the stab represents
+the return type of the function; thus @samp{foo:f5} means that foo is a
+function returning type 5.
 
 The type information of the stab is optionally followed by type
 information for each argument, with each argument preceded by @samp{;}.
@@ -501,7 +496,7 @@ An argument type of 0 means that additional arguments are being passed,
 whose types and number may vary (@samp{...} in ANSI C).  This extension
 is used by Sun's Solaris compiler.  GDB has tolerated it (i.e., at least
 parsed the syntax, if not necessarily used the information) at least
-since version 4.8; I don't know whether all versions of DBX will
+since version 4.8; I don't know whether all versions of dbx will
 tolerate it.  The argument types given here are not redundant
 with the symbols for the arguments themselves (@pxref{Parameters}), they
 are the types of the arguments as they are passed, before any
@@ -613,7 +608,7 @@ followed by line 50 of our sample assembly output, which has this form:
 
 The program's block structure is represented by the @code{N_LBRAC} (left
 brace) and the @code{N_RBRAC} (right brace) stab types.  The variables
-defined inside a block preceded the @code{N_LBRAC} symbol for most
+defined inside a block precede the @code{N_LBRAC} symbol for most
 compilers, including GCC.  Other compilers, such as the Convex, Acorn
 RISC machine, and Sun @code{acc} compilers, put the variables after the
 @code{N_LBRAC} symbol.  The values of the @code{N_LBRAC} and
@@ -629,7 +624,7 @@ represents the procedure itself.
 
 Sun documents the @code{desc} field of @code{N_LBRAC} and
 @code{N_RBRAC} symbols as containing the nesting level of the block.
-However, DBX seems not to care, and GCC always sets @code{desc} to
+However, dbx seems not to care, and GCC always sets @code{desc} to
 zero.
 
 @node Constants
@@ -651,7 +646,7 @@ Character constant.  @var{value} is the numeric value of the constant.
 @item e @var{type-information} , @var{value}
 Constant whose value can be represented as integral.
 @var{type-information} is the type of the constant, as it would appear
-after a symbol descriptor (@pxref{Stabs Format}).  @var{value} is the
+after a symbol descriptor (@pxref{String Field}).  @var{value} is the
 numeric value of the constant.  GDB 4.9 does not actually get the right
 value if @var{value} does not fit in a host @code{int}, but it does not
 do anything violent, and future debuggers could be extended to accept
@@ -679,7 +674,7 @@ string are represented as @samp{\"}).
 
 @item S @var{type-information} , @var{elements} , @var{bits} , @var{pattern}
 Set constant.  @var{type-information} is the type of the constant, as it
-would appear after a symbol descriptor (@pxref{Stabs Format}).
+would appear after a symbol descriptor (@pxref{String Field}).
 @var{elements} is the number of elements in the set (Does this means
 how many bits of @var{pattern} are actually used, which would be
 redundant with the type, or perhaps the number of bits set in
@@ -880,12 +875,9 @@ that type descriptors are distinct from symbol descriptors.
 
 These stabs have the @code{N_LSYM} stab type.  The value of the stab is
 the offset of the variable within the local variables.  On most machines
-this is an offset from the frame pointer and is negative.
-
-The stab for an automatic variable is located just before the
-@code{N_LBRAC} stab describing the open brace of the block to which it
-is scoped, except for some compilers which put the automatic variables
-after the @code{N_LBRAC} (see @code{VARIABLES_INSIDE_BLOCK} in GDB).
+this is an offset from the frame pointer and is negative.  The location
+of the stab specifies what block it is defined in; see @ref{Block
+Structure}.
 
 For example, the following C code
 
@@ -916,7 +908,7 @@ stabs.
 A variable whose scope which is not specific to just one source file is
 represented by the @samp{G} symbol descriptor.  These stabs use the
 @code{N_GSYM} stab type.  The type information for the stab
-(@pxref{Stabs Format}) gives the type of the variable.
+(@pxref{String Field}) gives the type of the variable.
 
 For example, the following source code:
 
@@ -997,7 +989,7 @@ Initialized static variables are represented by the @samp{S} and
 @c for `double' variables which although declared const are actually in
 @c the data segment (the text segment can't guarantee 8 byte alignment).
 @c (although GCC
-@c 2.4.5 has a bug in that it uses @code{N_FUN}, so neither DBX nor GDB can
+@c 2.4.5 has a bug in that it uses @code{N_FUN}, so neither dbx nor GDB can
 @c find the variables)
 In a.out files, @code{N_STSYM} means the data segment, @code{N_FUN}
 means the text segment, and @code{N_LCSYM} means the bss segment.
@@ -1039,11 +1031,14 @@ yield the following stabs:
 Parameters to a function are represented by a stab (or sometimes two,
 see below) for each parameter.  The stabs are in the order in which the
 debugger should print the parameters (i.e., the order in which the
-parameters are declared in the source file).
+parameters are declared in the source file).  The exact form of the stab
+depends on how the parameter is being passed.
 
-The symbol descriptor @samp{p} is used to refer to parameters which are
-in the arglist.  Symbols have symbol type @code{N_PSYM}.  The value of
-the symbol is the offset relative to the argument list.
+Parameters passed on the stack use the symbol descriptor @samp{p}, and
+the @code{N_PSYM} symbol type.  The value of the symbol is an offset
+used to locate the parameter on the stack; its exact meaning is
+machine-dependent but on most machines it is an offset from the frame
+pointer.
 
 If the parameter is passed in a register, then the traditional way to do
 this is to provide two symbols for each argument:
@@ -1093,17 +1088,18 @@ argument which is actually stored as a local variable.  Sometimes this
 happens when the argument was passed in a register and then the compiler
 stores it as a local variable.  If possible, the compiler should claim
 that it's in a register, but this isn't always done.  Some compilers use
-the pair of symbols approach described above (@samp{@var{arg}:p} followed by
-@samp{@var{arg}:}); this includes GCC1 (not GCC2) on the sparc when passing a small
-structure and GCC2 (sometimes) when the argument type is float and it is
-passed as a double and converted to float by the prologue (in the latter
-case the type of the @samp{@var{arg}:p} symbol is double and the type of the @samp{@var{arg}:}
-symbol is float).  GCC, at least on the 960, uses a single @samp{p}
-symbol descriptor for an argument which is stored as a local variable
-but uses @code{N_LSYM} instead of @code{N_PSYM}.  In this case the value
-of the symbol is an offset relative to the local variables for that
-function, not relative to the arguments (on some machines those are the
-same thing, but not on all).
+the pair of symbols approach described above (@samp{@var{arg}:p}
+followed by @samp{@var{arg}:}); this includes GCC1 (not GCC2) on the
+sparc when passing a small structure and GCC2 (sometimes) when the
+argument type is float and it is passed as a double and converted to
+float by the prologue (in the latter case the type of the
+@samp{@var{arg}:p} symbol is double and the type of the
+@samp{@var{arg}:} symbol is float).  GCC, at least on the 960, uses a
+single @samp{p} symbol descriptor for an argument which is stored as a
+local variable but uses @code{N_LSYM} instead of @code{N_PSYM}.  In this
+case the value of the symbol is an offset relative to the local
+variables for that function, not relative to the arguments (on some
+machines those are the same thing, but not on all).
 
 If the parameter is passed by reference (e.g., Pascal VAR parameters),
 then type symbol descriptor is @samp{v} if it is in the argument list,
@@ -1159,7 +1155,7 @@ type definitions.  Type 21 is pointer to type 2 (char) and argv (type 20) is
 pointer to type 21.
 
 @node Types
-@chapter Defining types
+@chapter Defining Types
 
 Now let's look at some variable definitions involving complex types.
 This involves understanding better how types are described.  In the
@@ -1194,11 +1190,11 @@ 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
-have been invented to describe them.  Sun's ACC uses the @samp{b} and
-@samp{R} type descriptors (@pxref{Builtin Type Descriptors}), and IBM
-uses negative type numbers (@pxref{Negative Type Numbers}).  GDB can
-accept all three, as of version 4.8; DBX just accepts the traditional
-builtin types and perhaps one of the other two formats.
+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 can accept all three, as of version 4.8; dbx just
+accepts the traditional builtin types and perhaps one of the other two
+formats.  The following sections describe each of these formats.
 
 @menu
 * Traditional Builtin Types::	Put on your seatbelts and prepare for kludgery
@@ -1226,13 +1222,15 @@ Builtin types can also be described as subranges of @code{int}:
 If the lower bound of a subrange is 0 and the upper bound is -1, it
 means that the type is an unsigned integral type whose bounds are too
 big to describe in an int.  Traditionally this is only used for
-@code{unsigned int} and @code{unsigned long}; GCC also sometimes uses it
-for @code{long long} and @code{unsigned long long}, and the only way to
-tell those types apart is to look at their names.  On other machines GCC
-puts out bounds in octal, with a leading 0.  In this case a negative
-bound consists of a number which is a 1 bit followed by a bunch of 0
-bits, and a positive bound is one in which a bunch of bits are 1.
+@code{unsigned int} and @code{unsigned long}.  For larger types, GCC
+2.4.5 puts out bounds in octal, with a leading 0.  In this case a
+negative bound consists of a number which is a 1 bit followed by a bunch
+of 0 bits, and a positive bound is one in which a bunch of bits are 1.
+All known versions of dbx and GDB version 4 accept this, but GDB 3.5
+refuses to read the whole file containing such symbols.  So GCC 2.3.3
+did not output the proper size for these types.
 
+@c FIXME: Update this for the 2.4.5 output, not 2.3.3
 @example
 .stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
 .stabs "long long int:t7=r1;0;-1;",128,0,0,0
@@ -1260,15 +1258,15 @@ bytes in the type:
 @end example
 
 However, GCC writes @code{long double} the same way it writes
-@code{double}; the only way to distinguish them is by the name:
+@code{double}, so there is no way to distinguish.
 
 @example
 .stabs "long double:t14=r1;8;0;",128,0,0,0
 @end example
 
-Complex types are defined the same way as floating-point types; the only
-way to distinguish a single-precision complex from a double-precision
-floating-point type is by the name.
+Complex types are defined the same way as floating-point types; there is
+no way to distinguish a single-precision complex from a double-precision
+floating-point type.
 
 The C @code{void} type is defined as itself:
 
@@ -1391,7 +1389,7 @@ different names have different negative type numbers.
 @code{int}, 32 bit signed integral type.
 
 @item -2
-@code{char}, 8 bit type holding a character.   Both GDB and DBX on AIX
+@code{char}, 8 bit type holding a character.   Both GDB and dbx on AIX
 treat this as signed.  GCC uses this type whether @code{char} is signed
 or not, which seems like a bad idea.  The AIX compiler (xlc) seems to
 avoid this type; it uses -5 instead for @code{char}.
@@ -1581,7 +1579,7 @@ the type (This differs from merely naming the type (@pxref{Typedefs}) in
 that it identifies the module; I don't understand whether the name of
 the type given here is always just the same as the name we are giving
 it, or whether this type descriptor is used with a nameless stab
-(@pxref{Stabs Format}), or what).  The symbol ends with @samp{;}.
+(@pxref{String Field}), or what).  The symbol ends with @samp{;}.
 
 @node Subranges
 @section Subrange types
@@ -1639,7 +1637,7 @@ range anyway; I'm not sure about dbx.
 
 It is well established, and widely used, that the type of the index,
 unlike most types found in the stabs, is merely a type definition, not
-type information (@pxref{Stabs Format}) (that is, it need not start with
+type information (@pxref{String Field}) (that is, it need not start with
 @var{type-number}@code{=} if it is defining a new type).  According to a
 comment in GDB, this is also true of the type of the array elements; it
 gives @samp{ar1;1;10;ar1;1;10;4} as a legitimate way to express a two
@@ -1677,7 +1675,7 @@ closely than normal, saving memory at the expense of speed.  For
 example, an array of 3-byte objects might, if unpacked, have each
 element aligned on a 4-byte boundary, but if packed, have no padding.
 One way to specify that something is packed is with type attributes
-(@pxref{Stabs Format}), in the case of arrays another is to use the
+(@pxref{String Field}), in the case of arrays another is to use the
 @samp{P} type descriptor instead of @samp{a}.  Other than specifying a
 packed array, @samp{P} is identical to @samp{a}.
 
@@ -1762,7 +1760,7 @@ generates the following stab
 @end example
 
 The symbol descriptor (T) says that the stab describes a structure,
-enumeration, or type tag.  The type descriptor e, following the 22= of
+enumeration, or union tag.  The type descriptor e, following the 22= of
 the type definition narrows it down to an enumeration type.  Following
 the e is a list of the elements of the enumeration.  The format is
 @var{name:value,}. The list of elements ends with a @samp{;}.
@@ -1848,7 +1846,7 @@ definition for an element which is a pointer to type 16.
 @section Giving a Type a Name
 
 To give a type a name, use the @samp{t} symbol descriptor.  The type
-specified by the type information (@pxref{Stabs Format}) for the stab.
+specified by the type information (@pxref{String Field}) for the stab.
 For example,
 
 @example
@@ -1866,7 +1864,7 @@ If the type is an opaque type (I believe this is a Modula-2 feature),
 AIX provides a type descriptor to specify it.  The type descriptor is
 @samp{o} and is followed by a name.  I don't know what the name
 means---is it always the same as the name of the type, or is this type
-descriptor used with a nameless stab (@pxref{Stabs Format})?  There
+descriptor used with a nameless stab (@pxref{String Field})?  There
 optionally follows a comma followed by type information which defines
 the type of this type.  If omitted, a semicolon is used in place of the
 comma and the type information, and the type is much like a generic
@@ -1916,7 +1914,7 @@ scope.
 @end smallexample
 
 The symbol descriptor, @samp{T}, following the @samp{name:} means that the stab
-describes an enumeration, struct or type tag.  The type descriptor @samp{u},
+describes an enumeration, struct or union tag.  The type 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
@@ -1992,6 +1990,7 @@ symbol table entry for that stab points to a string table entry
 containing the string data from the stab.  Assembler labels become
 relocatable addresses.  Symbol table entries in a.out have the format:
 
+@c FIXME: should refer to external, not internal.
 @example
 struct internal_nlist @{
   unsigned long n_strx;         /* index into string table of name */
@@ -2128,7 +2127,7 @@ the field being pointed to.  (FIXME: this is acknowledged to be
 gibberish.  Can anyone say what really goes here?).
 
 Note that there is a conflict between this and type attributes
-(@pxref{Stabs Format}); both use type descriptor @samp{@@}.
+(@pxref{String Field}); both use type descriptor @samp{@@}.
 Fortunately, the @samp{@@} type descriptor used in this C++ sense always
 will be followed by a digit, @samp{(}, or @samp{-}, and type attributes
 never start with those things.
@@ -2227,22 +2226,25 @@ then the method description goes on to give the vtable index of the
 method, and the type number of the first base class defining the
 method.
 
-When the field name is a method name it is followed by two colons
-rather than one.  This is followed by a new type definition for the
-method.  This is a number followed by an equal sign and then the
-symbol descriptor @samp{##}, indicating a method type.  This is followed by
-a type reference showing the return type of the method and a
+When the field name is a method name it is followed by two colons rather
+than one.  This is followed by a new type definition for the method.
+This is a number followed by an equal sign and the type descriptor
+@samp{#}, indicating a method type, and a second @samp{#}, indicating
+that this is the @dfn{minimal} type of method definition used by GCC2,
+not larger method definitions used by earlier versions of GCC.  This is
+followed by a type reference showing the return type of the method and a
 semi-colon.
 
-The format of an overloaded operator method name differs from that
-of other methods.  It is @samp{op$::@var{XXXX}.} where @var{XXXX} is the operator name
-such as @samp{+} or @samp{+=}.  The name ends with a period, and any characters except
-the period can occur in the @var{XXXX} string.
+The format of an overloaded operator method name differs from that of
+other methods.  It is @samp{op$::@var{operator-name}.} where
+@var{operator-name} is the operator name such as @samp{+} or @samp{+=}.
+The name ends with a period, and any characters except the period can
+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 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}
+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
+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}
 map to @samp{ic}.
 
 This is followed by a number, a letter, and an asterisk or period,
@@ -2377,11 +2379,13 @@ 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.
 
+@c FIXME:  What does "part of the string" mean?
 Protections for class member data are signified by two characters
-embeded in the stab defining the class type.  These characters are
-located after the name: part of the string.  @samp{/0} means private, @samp{/1}
-means protected, and @samp{/2} means public.  If these characters are omited
-this means that the member is public.  The following C++ source:
+embedded in the stab defining the class type.  These characters are
+located after the name: part of the string.  @samp{/0} means private,
+@samp{/1} means protected, and @samp{/2} means public.  If these
+characters are omited this means that the member is public.  The
+following C++ source:
 
 @example
 class all_data @{
@@ -2678,19 +2682,20 @@ the derivation of this class is encoded as follows.
 @node Virtual Base Classes
 @section Virtual Base Classes
 
-A derived class object consists of a concatination 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} 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.
+A derived class object consists of a concatination 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}
+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.
 
 In a derived class stab, the base offset part of the derivation
 information, described above, shows how the base class parts are
-ordered.  The base offset for a virtual base class is always given as
-0.  Notice that the base offset for @code{B} is given as 0 even though @code{B} is
-not the first base class.  The first base class @code{A} starts at offset 0.
+ordered.  The base offset for a virtual base class is always given as 0.
+Notice that the base offset for @code{B} is given as 0 even though
+@code{B} is not the first base class.  The first base class @code{A}
+starts at offset 0.
 
 The field information part of the stab for class @code{D} describes the field
 which is the pointer to the virtual base class @code{B}. The vbase pointer
@@ -2938,8 +2943,8 @@ The following are all the possible values for the stab type field, for
 The symbolic names are defined in the file @file{include/aout/stabs.def}.
 
 @menu
-* Non-stab symbol types::
-* Stab symbol types::
+* Non-stab symbol types::	Types from 0 to 0x1f
+* Stab symbol types::		Types from 0x20 to 0xff
 @end menu
 
 @node Non-stab symbol types
@@ -2990,7 +2995,7 @@ Same as @code{N_FN}, for Sequent compilers
 Symbol is indirected to another symbol
 
 @item 0x12    N_COMM
-Common sym -- visable after shared lib dynamic link
+Common---visible after shared library dynamic link
 
 @item 0x14 N_SETA
 Absolute set element
@@ -3020,7 +3025,6 @@ File name of a @file{.o} file
 The following symbol types indicate that this is a stab.  This is the
 full list of stab numbers, including stab types that are used in
 languages other than C.
-@xref{Expanded reference}, for more information about the stab types.
 
 @table @code
 @item 0x20     N_GSYM
@@ -3111,16 +3115,16 @@ Path and name of source file; see @ref{Source Files}.
 Stack variable (@pxref{Stack Variables}) or type (@pxref{Typedefs}).
 
 @item 0x82     N_BINCL
-Beginning of an include file (Sun only); see @ref{Source Files}.
+Beginning of an include file (Sun only); see @ref{Include Files}.
 
 @item 0x84     N_SOL
-Name of include file; see @ref{Source Files}.
+Name of include file; see @ref{Include Files}.
 
 @item 0xa0     N_PSYM
 Parameter variable; see @ref{Parameters}.
 
 @item 0xa2     N_EINCL
-End of an include file; see @ref{Source Files}.
+End of an include file; see @ref{Include Files}.
 
 @item 0xa4     N_ENTRY
 Alternate entry point; see @ref{N_ENTRY}.
@@ -3129,7 +3133,7 @@ Alternate entry point; see @ref{N_ENTRY}.
 Beginning of a lexical block; see @ref{Block Structure}.
 
 @item 0xc2     N_EXCL
-Place holder for a deleted include file; see @ref{Source Files}.
+Place holder for a deleted include file; see @ref{Include Files}.
 
 @item 0xc4     N_SCOPE
 Modula2 scope information (Sun linker); see @ref{N_SCOPE}.
@@ -3174,9 +3178,9 @@ Gould non-base registers; see @ref{Gould}.
 @node Symbol Descriptors
 @appendix Table of Symbol Descriptors
 
-These tell in the @code{.stabs} @var{string} field what kind of symbol the stab
-represents.  They follow the symbol name and a colon.  @xref{String
-Field}, for more information about their use.
+These tell in the @code{.stabs} @var{string} field what kind of symbol
+the stab represents.  They follow the colon which follows the symbol
+name.  @xref{String Field}, for more information about their use.
 
 @c Please keep this alphabetical
 @table @code
@@ -3289,7 +3293,7 @@ defined.  They follow the type number and an equals sign.
 @table @code
 @item @var{digit}
 @itemx (
-Type reference; see @ref{Stabs Format}.
+Type reference; see @ref{String Field}.
 
 @item -
 Reference to builtin type; see @ref{Negative Type Numbers}.
@@ -3304,7 +3308,7 @@ Pointer; see @ref{Miscellaneous Types}.
 Reference (C++).
 
 @item @@
-Type Attributes (AIX); see @ref{Stabs Format}.  Member (class and variable)
+Type Attributes (AIX); see @ref{String Field}.  Member (class and variable)
 type (GNU C++); see @ref{Cplusplus}.
 
 @item a
@@ -3563,8 +3567,8 @@ GNU Modula2 definition module dependency
 
 GNU Modula-2 definition module dependency.  Value is the modification
 time of the definition file.  Other is non-zero if it is imported with
-the GNU M2 keyword @code{%INITIALIZE}.  Perhaps @code{N_M2C} can be used if there
-are enough empty fields?
+the GNU M2 keyword @code{%INITIALIZE}.  Perhaps @code{N_M2C} can be used
+if there are enough empty fields?
 
 @node N_EHDECL
 @section 80 - 0x50 - N_EHDECL
@@ -3642,13 +3646,15 @@ The value is the length.
 
 @itemize @bullet
 @item
+@c I think this is changed in GCC 2.4.5 to put the line number there.
 For GNU C stabs defining local and global variables (@code{N_LSYM} and
-@code{N_GSYM}), the @var{desc} field is supposed to contain the source line number
-on which the variable is defined.  In reality the @var{desc} field is always
-0.  (This behavior is defined in @file{dbxout.c} and putting a line number in
-@var{desc} is controlled by @samp{#ifdef WINNING_GDB}, which defaults to false). GDB
-supposedly uses this information if you say @samp{list @var{var}}.  In reality,
-@var{var} can be a variable defined in the program and GDB says @samp{function
+@code{N_GSYM}), the @var{desc} field is supposed to contain the source
+line number on which the variable is defined.  In reality the @var{desc}
+field is always 0.  (This behavior is defined in @file{dbxout.c} and
+putting a line number in @var{desc} is controlled by @samp{#ifdef
+WINNING_GDB}, which defaults to false). GDB supposedly uses this
+information if you say @samp{list @var{var}}.  In reality, @var{var} can
+be a variable defined in the program and GDB says @samp{function
 @var{var} not defined}.
 
 @item
@@ -3679,11 +3685,12 @@ knows that external symbols have leading underbars).
 
 @c FIXME: This is absurdly vague; there all kinds of differences, some
 @c of which are the same between gnu & sun, and some of which aren't.
-@item
-Can GCC be configured to output stabs the way the Sun compiler
-does, so that their native debugging tools work? <NO?> It doesn't by
-default.  GDB reads either format of stab. (GCC or SunC).  How about
-DBX?
+@c In particular, I'm pretty sure GCC works with Sun dbx by default.
+@c @item
+@c Can GCC be configured to output stabs the way the Sun compiler
+@c does, so that their native debugging tools work? <NO?> It doesn't by
+@c default.  GDB reads either format of stab. (GCC or SunC).  How about
+@c dbx?
 @end itemize
 
 @node XCOFF-differences
@@ -3696,24 +3703,25 @@ body of this document.
 
 @itemize @bullet
 @item
-BSD a.out stab types correspond to AIX XCOFF storage classes. In general the
-mapping is @code{N_STABTYPE} becomes @code{C_STABTYPE}.  Some stab types in a.out
-are not supported in XCOFF.
+BSD a.out stab types correspond to AIX XCOFF storage classes. In general
+the mapping is @code{N_@var{stabtype}} becomes @code{C_@var{stabtype}}.
+Some stab types in a.out are not supported in XCOFF; most of these use
+@code{C_DECL}.
 
 @c FIXME: Get C_* types for the block, figure out whether it is always
 @c used (I suspect not), explain clearly, and move to node Statics.
-Exception:
-initialised static @code{N_STSYM} and un-initialized static @code{N_LCSYM} both map
-to the @code{C_STSYM} storage class.  But the destinction is preserved
-because in XCOFF @code{N_STSYM} and @code{N_LCSYM} must be emited in a named static
-block.  Begin the block with @samp{.bs s[RW] data_section_name} for @code{N_STSYM}
-or @samp{.bs s bss_section_name} for @code{N_LCSYM}.  End the block with @samp{.es}.
+Exception: initialised static @code{N_STSYM} and un-initialized static
+@code{N_LCSYM} both map to the @code{C_STSYM} storage class.  But the
+destinction is preserved because in XCOFF @code{N_STSYM} and
+@code{N_LCSYM} must be emited in a named static block.  Begin the block
+with @samp{.bs s[RW] data_section_name} for @code{N_STSYM} or @samp{.bs
+s bss_section_name} for @code{N_LCSYM}.  End the block with @samp{.es}.
 
 @c FIXME: I think they are trying to say something about whether the
 @c assembler defaults the value to the location counter.
 @item
-If the XCOFF stab is a @code{N_FUN} (@code{C_FUN}) then follow the string field with
-@samp{,.} instead of just @samp{,}.
+If the XCOFF stab is a @code{N_FUN} (@code{C_FUN}) then follow the
+string field with @samp{,.} instead of just @samp{,}.
 @end itemize
 
 I think that's it for @file{.s} file differences.  They could stand to be
@@ -3734,7 +3742,7 @@ N_LCSYM         C_STSYM
 N_MAIN          unkown
 N_PC            unknown
 N_RSYM          C_RSYM
-N_RPSYM (0x8e)  C_RPSYM
+unknown         C_RPSYM
 N_M2C           unknown
 N_SLINE         unknown
 N_DSLINE        unknown
@@ -3744,7 +3752,7 @@ N_CATCH         unknown
 N_SSYM          unknown
 N_SO            unknown
 N_LSYM          C_LSYM
-N_DECL  (0x8c)  C_DECL
+various         C_DECL
 N_BINCL         unknown
 N_SOL           unknown
 N_PSYM          C_PSYM