stabs.texinfo

这个是LINUX下的GDB调度工具的源码

@c of C_RSYM.  I am skeptical; this should be verified.
Register variables have their own stab type, @code{N_RSYM}
(@code{C_RSYM} for XCOFF), and their own symbol descriptor, @samp{r}.
The stab's value is the number of the register where the variable data
will be stored.
@c .stabs "name:type",N_RSYM,0,RegSize,RegNumber (Sun doc)

AIX defines a separate symbol descriptor @samp{d} for floating point
registers.  This seems unnecessary; why not just just give floating
point registers different register numbers?  I have not verified whether
the compiler actually uses @samp{d}.

If the register is explicitly allocated to a global variable, but not
initialized, as in:

@example
register int g_bar asm ("%g5");
@end example

@noindent
then the stab may be emitted at the end of the object file, with
the other bss symbols.

@node Common Blocks
@section Common Blocks

A common block is a statically allocated section of memory which can be
referred to by several source files.  It may contain several variables.
I believe Fortran is the only language with this feature.

@findex N_BCOMM
@findex N_ECOMM
@findex C_BCOMM
@findex C_ECOMM
A @code{N_BCOMM} stab begins a common block and an @code{N_ECOMM} stab
ends it.  The only field that is significant in these two stabs is the
string, which names a normal (non-debugging) symbol that gives the
address of the common block.  According to IBM documentation, only the
@code{N_BCOMM} has the name of the common block (even though their
compiler actually puts it both places).

@findex N_ECOML
@findex C_ECOML
The stabs for the members of the common block are between the
@code{N_BCOMM} and the @code{N_ECOMM}; the value of each stab is the
offset within the common block of that variable.  IBM uses the
@code{C_ECOML} stab type, and there is a corresponding @code{N_ECOML}
stab type, but Sun's Fortran compiler uses @code{N_GSYM} instead.  The
variables within a common block use the @samp{V} symbol descriptor (I
believe this is true of all Fortran variables).  Other stabs (at least
type declarations using @code{C_DECL}) can also be between the
@code{N_BCOMM} and the @code{N_ECOMM}.

@node Statics
@section Static Variables

Initialized static variables are represented by the @samp{S} and
@samp{V} symbol descriptors.  @samp{S} means file scope static, and
@samp{V} means procedure scope static.  One exception: in XCOFF, IBM's
xlc compiler always uses @samp{V}, and whether it is file scope or not
is distinguished by whether the stab is located within a function.

@c This is probably not worth mentioning; it is only true on the sparc
@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 find the variables)
@findex N_STSYM
@findex N_LCSYM
@findex N_FUN, for variables
@findex N_ROSYM
In a.out files, @code{N_STSYM} means the data section, @code{N_FUN}
means the text section, and @code{N_LCSYM} means the bss section.  For
those systems with a read-only data section separate from the text
section (Solaris), @code{N_ROSYM} means the read-only data section.

For example, the source lines:

@example
static const int var_const = 5;
static int var_init = 2;
static int var_noinit;
@end example

@noindent
yield the following stabs:

@example
.stabs "var_const:S1",36,0,0,_var_const      # @r{36 is N_FUN}
@dots{}
.stabs "var_init:S1",38,0,0,_var_init        # @r{38 is N_STSYM}
@dots{}
.stabs "var_noinit:S1",40,0,0,_var_noinit    # @r{40 is N_LCSYM}
@end example

@findex C_STSYM
@findex C_BSTAT
@findex C_ESTAT
In XCOFF files, the stab type need not indicate the section;
@code{C_STSYM} can be used for all statics.  Also, each static variable
is enclosed in a static block.  A @code{C_BSTAT} (emitted with a
@samp{.bs} assembler directive) symbol begins the static block; its
value is the symbol number of the csect symbol whose value is the
address of the static block, its section is the section of the variables
in that static block, and its name is @samp{.bs}.  A @code{C_ESTAT}
(emitted with a @samp{.es} assembler directive) symbol ends the static
block; its name is @samp{.es} and its value and section are ignored.

In ECOFF files, the storage class is used to specify the section, so the
stab type need not indicate the section.

In ELF files, for the SunPRO compiler version 2.0.1, symbol descriptor
@samp{S} means that the address is absolute (the linker relocates it)
and symbol descriptor @samp{V} means that the address is relative to the
start of the relevant section for that compilation unit.  SunPRO has
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
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,
@xref{ELF Linker Relocation}.

@node Based Variables
@section Fortran Based Variables

Fortran (at least, the Sun and SGI dialects of FORTRAN-77) has a feature
which allows allocating arrays with @code{malloc}, but which avoids
blurring the line between arrays and pointers the way that C does.  In
stabs such a variable uses the @samp{b} symbol descriptor.

For example, the Fortran declarations

@example
real foo, foo10(10), foo10_5(10,5)
pointer (foop, foo)
pointer (foo10p, foo10)
pointer (foo105p, foo10_5)
@end example

produce the stabs

@example
foo:b6
foo10:bar3;1;10;6
foo10_5:bar3;1;5;ar3;1;10;6
@end example

In this example, @code{real} is type 6 and type 3 is an integral type
which is the type of the subscripts of the array (probably
@code{integer}).

The @samp{b} symbol descriptor is like @samp{V} in that it denotes a
statically allocated symbol whose scope is local to a function; see
@xref{Statics}.  The value of the symbol, instead of being the address
of the variable itself, is the address of a pointer to that variable.
So in the above example, the value of the @code{foo} stab is the address
of a pointer to a real, the value of the @code{foo10} stab is the
address of a pointer to a 10-element array of reals, and the value of
the @code{foo10_5} stab is the address of a pointer to a 5-element array
of 10-element arrays of reals.

@node Parameters
@section Parameters

Formal 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).  The exact form of the stab
depends on how the parameter is being passed.

@findex N_PSYM
@findex C_PSYM
Parameters passed on the stack use the symbol descriptor @samp{p} and
the @code{N_PSYM} symbol type (or @code{C_PSYM} for XCOFF).  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.

As a simple example, the code:

@example
main (argc, argv)
     int argc;
     char **argv;
@end example

produces the stabs:

@example
.stabs "main:F1",36,0,0,_main                 # @r{36 is N_FUN}
.stabs "argc:p1",160,0,0,68                   # @r{160 is N_PSYM}
.stabs "argv:p20=*21=*2",160,0,0,72
@end example

The type definition of @code{argv} is interesting because it contains
several type definitions.  Type 21 is pointer to type 2 (char) and
@code{argv} (type 20) is pointer to type 21.

@c FIXME: figure out what these mean and describe them coherently.
The following symbol descriptors are also said to go with @code{N_PSYM}.
The value of the symbol is said to be an offset from the argument
pointer (I'm not sure whether this is true or not).

@example
pP (<<??>>)
pF Fortran function parameter
X  (function result variable)
@end example

@menu
* Register Parameters::
* Local Variable Parameters::
* Reference Parameters::
* Conformant Arrays::
@end menu

@node Register Parameters
@subsection Passing Parameters in Registers

If the parameter is passed in a register, then traditionally there are
two symbols for each argument:

@example
.stabs "arg:p1" . . .       ; N_PSYM
.stabs "arg:r1" . . .       ; N_RSYM
@end example

Debuggers use the second one to find the value, and the first one to
know that it is an argument.

@findex C_RPSYM
@findex N_RSYM, for parameters
Because that approach is kind of ugly, some compilers use symbol
descriptor @samp{P} or @samp{R} to indicate an argument which is in a
register.  Symbol type @code{C_RPSYM} is used in XCOFF and @code{N_RSYM}
is used otherwise.  The symbol's value is the register number.  @samp{P}
and @samp{R} mean the same thing; the difference is that @samp{P} is a
GNU invention and @samp{R} is an IBM (XCOFF) invention.  As of version
4.9, GDB should handle either one.

There is at least one case where GCC uses a @samp{p} and @samp{r} pair
rather than @samp{P}; this is where the argument is passed in the
argument list and then loaded into a register.

According to the AIX documentation, symbol descriptor @samp{D} is for a
parameter passed in a floating point register.  This seems
unnecessary---why not just use @samp{R} with a register number which
indicates that it's a floating point register?  I haven't verified
whether the system actually does what the documentation indicates.

@c FIXME: On the hppa this is for any type > 8 bytes, I think, and not
@c for small structures (investigate).
On the sparc and hppa, for a @samp{P} symbol whose type is a structure
or union, the register contains the address of the structure.  On the
sparc, this is also true of a @samp{p} and @samp{r} pair (using Sun
@code{cc}) or a @samp{p} symbol.  However, if a (small) structure is
really in a register, @samp{r} is used.  And, to top it all off, on the
hppa it might be a structure which was passed on the stack and loaded
into a register and for which there is a @samp{p} and @samp{r} pair!  I
believe that symbol descriptor @samp{i} is supposed to deal with this
case (it is said to mean "value parameter by reference, indirect
access"; I don't know the source for this information), but I don't know
details or what compilers or debuggers use it, if any (not GDB or GCC).
It is not clear to me whether this case needs to be dealt with
differently than parameters passed by reference (@pxref{Reference Parameters}).

@node Local Variable Parameters
@subsection Storing Parameters as Local Variables

There is a case similar to an argument in a register, which is an
argument that 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.

If a parameter is passed as one type and converted to a smaller type by
the prologue (for example, the parameter is declared as a @code{float},
but the calling conventions specify that it is passed as a
@code{double}), then GCC2 (sometimes) uses a pair of symbols.  The first
symbol uses symbol descriptor @samp{p} and the type which is passed.
The second symbol has the type and location which the parameter actually
has after the prologue.  For example, suppose the following C code
appears with no prototypes involved:

@example
void
subr (f)
     float f;
@{
@end example

if @code{f} is passed as a double at stack offset 8, and the prologue
converts it to a float in register number 0, then the stabs look like:

@example
.stabs "f:p13",160,0,3,8   # @r{160 is @code{N_PSYM}, here 13 is @code{double}}
.stabs "f:r12",64,0,3,0    # @r{64 is @code{N_RSYM}, here 12 is @code{float}}
@end example

In both stabs 3 is the line number where @code{f} is declared
(@pxref{Line Numbers}).

@findex N_LSYM, for parameter
GCC, at least on the 960, has another solution to the same problem.  It
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.

@c This is mostly just background info; the part that logically belongs
@c here is the last sentence.  
On the VAX or on other machines in which the calling convention includes
the number of words of arguments actually passed, the debugger (GDB at