stabs.html

vxworks相关论文

foo (int x)
{
  int bar (int y)
    {
      int baz (int z)
        {
          return x + y + z;
        }
      return baz (x + 2 * y);
    }
  return x + bar (3 * x);
}
</PRE>

<P>
produces the stabs:

</P>

<PRE>
.stabs "baz:f1,baz,bar",36,0,0,_baz.15         
# 36 is N_FUN
.stabs "bar:f1,bar,foo",36,0,0,_bar.12
.stabs "foo:F1",36,0,0,_foo
</PRE>



<H2><A NAME="SEC14" HREF="stabs_toc.html#TOC14">Block Structure</A></H2>

<P>
<A NAME="IDX18"></A>
<A NAME="IDX19"></A>
The program's block structure is represented by the <CODE>N_LBRAC</CODE> (left
brace) and the <CODE>N_RBRAC</CODE> (right brace) stab types.  The variables
defined inside a block precede the <CODE>N_LBRAC</CODE> symbol for most
compilers, including GCC.  Other compilers, such as the Convex, Acorn
RISC machine, and Sun <CODE>acc</CODE> compilers, put the variables after the
<CODE>N_LBRAC</CODE> symbol.  The values of the <CODE>N_LBRAC</CODE> and
<CODE>N_RBRAC</CODE> symbols are the start and end addresses of the code of
the block, respectively.  For most machines, they are relative to the
starting address of this source file.  For the Gould NP1, they are
absolute.  For stabs in sections (see section <A HREF="stabs.html#SEC87">Using Stabs in Their Own Sections</A>), they are
relative to the function in which they occur.

</P>
<P>
The <CODE>N_LBRAC</CODE> and <CODE>N_RBRAC</CODE> stabs that describe the block
scope of a procedure are located after the <CODE>N_FUN</CODE> stab that
represents the procedure itself.

</P>
<P>
Sun documents the desc field of <CODE>N_LBRAC</CODE> and
<CODE>N_RBRAC</CODE> symbols as containing the nesting level of the block.
However, dbx seems to not care, and GCC always sets desc to
zero.

</P>
<P>
<A NAME="IDX20"></A>
<A NAME="IDX21"></A>
<A NAME="IDX22"></A>
For XCOFF, block scope is indicated with <CODE>C_BLOCK</CODE> symbols.  If the
name of the symbol is <SAMP>`.bb'</SAMP>, then it is the beginning of the block;
if the name of the symbol is <SAMP>`.be'</SAMP>; it is the end of the block.

</P>


<H2><A NAME="SEC15" HREF="stabs_toc.html#TOC15">Alternate Entry Points</A></H2>

<P>
<A NAME="IDX23"></A>
<A NAME="IDX24"></A>
Some languages, like Fortran, have the ability to enter procedures at
some place other than the beginning.  One can declare an alternate entry
point.  The <CODE>N_ENTRY</CODE> stab is for this; however, the Sun FORTRAN
compiler doesn't use it.  According to AIX documentation, only the name
of a <CODE>C_ENTRY</CODE> stab is significant; the address of the alternate
entry point comes from the corresponding external symbol.  A previous
revision of this document said that the value of an <CODE>N_ENTRY</CODE> stab
was the address of the alternate entry point, but I don't know the
source for that information.

</P>


<H1><A NAME="SEC16" HREF="stabs_toc.html#TOC16">Constants</A></H1>

<P>
The <SAMP>`c'</SAMP> symbol descriptor indicates that this stab represents a
constant.  This symbol descriptor is an exception to the general rule
that symbol descriptors are followed by type information.  Instead, it
is followed by <SAMP>`='</SAMP> and one of the following:

</P>
<DL COMPACT>

<DT><CODE>b <VAR>value</VAR></CODE>
<DD>
Boolean constant.  <VAR>value</VAR> is a numeric value; I assume it is 0 for
false or 1 for true.

<DT><CODE>c <VAR>value</VAR></CODE>
<DD>
Character constant.  <VAR>value</VAR> is the numeric value of the constant.

<DT><CODE>e <VAR>type-information</VAR> , <VAR>value</VAR></CODE>
<DD>
Constant whose value can be represented as integral.
<VAR>type-information</VAR> is the type of the constant, as it would appear
after a symbol descriptor (see section <A HREF="stabs.html#SEC4">The String Field</A>).  <VAR>value</VAR> is the
numeric value of the constant.  GDB 4.9 does not actually get the right
value if <VAR>value</VAR> does not fit in a host <CODE>int</CODE>, but it does not
do anything violent, and future debuggers could be extended to accept
integers of any size (whether unsigned or not).  This constant type is
usually documented as being only for enumeration constants, but GDB has
never imposed that restriction; I don't know about other debuggers.

<DT><CODE>i <VAR>value</VAR></CODE>
<DD>
Integer constant.  <VAR>value</VAR> is the numeric value.  The type is some
sort of generic integer type (for GDB, a host <CODE>int</CODE>); to specify
the type explicitly, use <SAMP>`e'</SAMP> instead.

<DT><CODE>r <VAR>value</VAR></CODE>
<DD>
Real constant.  <VAR>value</VAR> is the real value, which can be <SAMP>`INF'</SAMP>
(optionally preceded by a sign) for infinity, <SAMP>`QNAN'</SAMP> for a quiet
NaN (not-a-number), or <SAMP>`SNAN'</SAMP> for a signalling NaN.  If it is a
normal number the format is that accepted by the C library function
<CODE>atof</CODE>.

<DT><CODE>s <VAR>string</VAR></CODE>
<DD>
String constant.  <VAR>string</VAR> is a string enclosed in either <SAMP>`''</SAMP>
(in which case <SAMP>`''</SAMP> characters within the string are represented as
<SAMP>`\''</SAMP> or <SAMP>`"'</SAMP> (in which case <SAMP>`"'</SAMP> characters within the
string are represented as <SAMP>`\"'</SAMP>).

<DT><CODE>S <VAR>type-information</VAR> , <VAR>elements</VAR> , <VAR>bits</VAR> , <VAR>pattern</VAR></CODE>
<DD>
Set constant.  <VAR>type-information</VAR> is the type of the constant, as it
would appear after a symbol descriptor (see section <A HREF="stabs.html#SEC4">The String Field</A>).
<VAR>elements</VAR> is the number of elements in the set (does this means
how many bits of <VAR>pattern</VAR> are actually used, which would be
redundant with the type, or perhaps the number of bits set in
<VAR>pattern</VAR>?  I don't get it), <VAR>bits</VAR> is the number of bits in the
constant (meaning it specifies the length of <VAR>pattern</VAR>, I think),
and <VAR>pattern</VAR> is a hexadecimal representation of the set.  AIX
documentation refers to a limit of 32 bytes, but I see no reason why
this limit should exist.  This form could probably be used for arbitrary
constants, not just sets; the only catch is that <VAR>pattern</VAR> should be
understood to be target, not host, byte order and format.
</DL>

<P>
The boolean, character, string, and set constants are not supported by
GDB 4.9, but it ignores them.  GDB 4.8 and earlier gave an error
message and refused to read symbols from the file containing the
constants.

</P>
<P>
The above information is followed by <SAMP>`;'</SAMP>.

</P>


<H1><A NAME="SEC17" HREF="stabs_toc.html#TOC17">Variables</A></H1>

<P>
Different types of stabs describe the various ways that variables can be
allocated: on the stack, globally, in registers, in common blocks,
statically, or as arguments to a function.

</P>



<H2><A NAME="SEC18" HREF="stabs_toc.html#TOC18">Automatic Variables Allocated on the Stack</A></H2>

<P>
If a variable's scope is local to a function and its lifetime is only as
long as that function executes (C calls such variables
<EM>automatic</EM>), it can be allocated in a register (see section <A HREF="stabs.html#SEC20">Register Variables</A>) or on the stack.

</P>
<P>
<A NAME="IDX25"></A>
<A NAME="IDX26"></A>
Each variable allocated on the stack has a stab with the symbol
descriptor omitted.  Since type information should begin with a digit,
<SAMP>`-'</SAMP>, or <SAMP>`('</SAMP>, only those characters precluded from being used
for symbol descriptors.  However, the Acorn RISC machine (ARM) is said
to get this wrong: it puts out a mere type definition here, without the
preceding <SAMP>`<VAR>type-number</VAR>='</SAMP>.  This is a bad idea; there is no
guarantee that type descriptors are distinct from symbol descriptors.
Stabs for stack variables use the <CODE>N_LSYM</CODE> stab type, or
<CODE>C_LSYM</CODE> for XCOFF.

</P>
<P>
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 location of the stab specifies which block
it is defined in; see section <A HREF="stabs.html#SEC14">Block Structure</A>.

</P>
<P>
For example, the following C code:

</P>

<PRE>
int
main ()
{
  int x;
}
</PRE>

<P>
produces the following stabs:

</P>

<PRE>
.stabs "main:F1",36,0,0,_main   # 36 is N_FUN
.stabs "x:1",128,0,0,-12        # 128 is N_LSYM
.stabn 192,0,0,LBB2             # 192 is N_LBRAC
.stabn 224,0,0,LBE2             # 224 is N_RBRAC
</PRE>

<P>
See section <A HREF="stabs.html#SEC12">Procedures</A> for more information on the <CODE>N_FUN</CODE> stab, and
section <A HREF="stabs.html#SEC14">Block Structure</A> for more information on the <CODE>N_LBRAC</CODE> and
<CODE>N_RBRAC</CODE> stabs.

</P>


<H2><A NAME="SEC19" HREF="stabs_toc.html#TOC19">Global Variables</A></H2>

<P>
<A NAME="IDX27"></A>
<A NAME="IDX28"></A>
A variable whose scope is not specific to just one source file is
represented by the <SAMP>`G'</SAMP> symbol descriptor.  These stabs use the
<CODE>N_GSYM</CODE> stab type (C_GSYM for XCOFF).  The type information for
the stab (see section <A HREF="stabs.html#SEC4">The String Field</A>) gives the type of the variable.

</P>
<P>
For example, the following source code:

</P>

<PRE>
char g_foo = 'c';
</PRE>

<P>
yields the following assembly code:

</P>

<PRE>
.stabs "g_foo:G2",32,0,0,0     # 32 is N_GSYM
     .global _g_foo
     .data
_g_foo:
     .byte 99
</PRE>

<P>
The address of the variable represented by the <CODE>N_GSYM</CODE> is not
contained in the <CODE>N_GSYM</CODE> stab.  The debugger gets this information
from the external symbol for the global variable.  In the example above,
the <CODE>.global _g_foo</CODE> and <CODE>_g_foo:</CODE> lines tell the assembler to
produce an external symbol.

</P>
<P>
Some compilers, like GCC, output <CODE>N_GSYM</CODE> stabs only once, where
the variable is defined.  Other compilers, like SunOS4 /bin/cc, output a
<CODE>N_GSYM</CODE> stab for each compilation unit which references the
variable.

</P>


<H2><A NAME="SEC20" HREF="stabs_toc.html#TOC20">Register Variables</A></H2>

<P>
<A NAME="IDX29"></A>
<A NAME="IDX30"></A>
Register variables have their own stab type, <CODE>N_RSYM</CODE>
(<CODE>C_RSYM</CODE> for XCOFF), and their own symbol descriptor, <SAMP>`r'</SAMP>.
The stab's value is the number of the register where the variable data
will be stored.

</P>
<P>
AIX defines a separate symbol descriptor <SAMP>`d'</SAMP> for floating point
registers.  This seems unnecessary; why not just give floating
point registers different register numbers?  I have not verified whether
the compiler actually uses <SAMP>`d'</SAMP>.

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

</P>

<PRE>
register int g_bar asm ("%g5");
</PRE>

<P>
then the stab may be emitted at the end of the object file, with
the other bss symbols.

</P>


<H2><A NAME="SEC21" HREF="stabs_toc.html#TOC21">Common Blocks</A></H2>

<P>
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.

</P>
<P>
<A NAME="IDX31"></A>
<A NAME="IDX32"></A>
<A NAME="IDX33"></A>
<A NAME="IDX34"></A>
A <CODE>N_BCOMM</CODE> stab begins a common block and an <CODE>N_ECOMM</CODE> 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</CODE> has the name of the common block (even though their
compiler actually puts it both places).

</P>
<P>
<A NAME="IDX35"></A>
<A NAME="IDX36"></A>
The stabs for the members of the common block are between the
<CODE>N_BCOMM</CODE> and the <CODE>N_ECOMM</CODE>; the value of each stab is the
offset within the common block of that variable.  IBM uses the
<CODE>C_ECOML</CODE> stab type, and there is a corresponding <CODE>N_ECOML</CODE>
stab type, but Sun's Fortran compiler uses <CODE>N_GSYM</CODE> instead.  The
variables within a common block use the <SAMP>`V'</SAMP> symbol descriptor (I
believe this is true of all Fortran variables).  Other stabs (at least