stabs.html

vxworks相关论文

</P>


<H3><A NAME="SEC28" HREF="stabs_toc.html#TOC28">Passing Conformant Array Parameters</A></H3>

<P>
Conformant arrays are a feature of Modula-2, and perhaps other
languages, in which the size of an array parameter is not known to the
called function until run-time.  Such parameters have two stabs: a
<SAMP>`x'</SAMP> for the array itself, and a <SAMP>`C'</SAMP>, which represents the size
of the array.  The value of the <SAMP>`x'</SAMP> stab is the offset in the
argument list where the address of the array is stored (it this right?
it is a guess); the value of the <SAMP>`C'</SAMP> stab is the offset in the
argument list where the size of the array (in elements? in bytes?) is
stored.

</P>


<H1><A NAME="SEC29" HREF="stabs_toc.html#TOC29">Defining Types</A></H1>

<P>
The examples so far have described types as references to previously
defined types, or defined in terms of subranges of or pointers to
previously defined types.  This chapter describes the other type
descriptors that may follow the <SAMP>`='</SAMP> in a type definition.

</P>



<H2><A NAME="SEC30" HREF="stabs_toc.html#TOC30">Builtin Types</A></H2>

<P>
Certain types are built in (<CODE>int</CODE>, <CODE>short</CODE>, <CODE>void</CODE>,
<CODE>float</CODE>, etc.); the debugger recognizes these types and knows how
to handle them.  Thus, don't be surprised if some of the following ways
of specifying builtin types do not specify everything that a debugger
would need to know about the type--in some cases they merely specify
enough information to distinguish the type from other types.

</P>
<P>
The traditional way to define builtin types is convoluted, so new ways
have been invented to describe them.  Sun's <CODE>acc</CODE> uses special
builtin type descriptors (<SAMP>`b'</SAMP> and <SAMP>`R'</SAMP>), and IBM uses negative
type numbers.  GDB accepts all three ways, 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.

</P>



<H3><A NAME="SEC31" HREF="stabs_toc.html#TOC31">Traditional Builtin Types</A></H3>

<P>
This is the traditional, convoluted method for defining builtin types.
There are several classes of such type definitions: integer, floating
point, and <CODE>void</CODE>.

</P>



<H4><A NAME="SEC32" HREF="stabs_toc.html#TOC32">Traditional Integer Types</A></H4>

<P>
Often types are defined as subranges of themselves.  If the bounding values
fit within an <CODE>int</CODE>, then they are given normally.  For example:

</P>

<PRE>
.stabs "int:t1=r1;-2147483648;2147483647;",128,0,0,0    
# 128 is N_LSYM
.stabs "char:t2=r2;0;127;",128,0,0,0
</PRE>

<P>
Builtin types can also be described as subranges of <CODE>int</CODE>:

</P>

<PRE>
.stabs "unsigned short:t6=r1;0;65535;",128,0,0,0
</PRE>

<P>
If the lower bound of a subrange is 0 and the upper bound is -1,
the type is an unsigned integral type whose bounds are too
big to describe in an <CODE>int</CODE>.  Traditionally this is only used for
<CODE>unsigned int</CODE> and <CODE>unsigned long</CODE>:

</P>

<PRE>
.stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
</PRE>

<P>
For larger types, GCC 2.4.5 puts out bounds in octal, with one or more
leading zeroes.  In this case a negative bound consists of a number
which is a 1 bit (for the sign bit) followed by a 0 bit for each bit in
the number (except the sign bit), and a positive bound is one which is a
1 bit for each bit in the number (except possibly the sign bit).  All
known versions of dbx and GDB version 4 accept this (at least in the
sense of not refusing to process the file), 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.  As an example of octal bounds, the string
fields of the stabs for 64 bit integer types look like:

</P>

<PRE>
long int:t3=r1;001000000000000000000000; \ 
        000777777777777777777777;
long unsigned int:t5=r1;000000000000000000000000; \ 
        001777777777777777777777;
</PRE>

<P>
If the lower bound of a subrange is 0 and the upper bound is negative,
the type is an unsigned integral type whose size in bytes is the
absolute value of the upper bound.  I believe this is a Convex
convention for <CODE>unsigned long long</CODE>.

</P>
<P>
If the lower bound of a subrange is negative and the upper bound is 0,
the type is a signed integral type whose size in bytes is
the absolute value of the lower bound.  I believe this is a Convex
convention for <CODE>long long</CODE>.  To distinguish this from a legitimate
subrange, the type should be a subrange of itself.  I'm not sure whether
this is the case for Convex.

</P>


<H4><A NAME="SEC33" HREF="stabs_toc.html#TOC33">Traditional Other Types</A></H4>

<P>
If the upper bound of a subrange is 0 and the lower bound is positive,
the type is a floating point type, and the lower bound of the subrange
indicates the number of bytes in the type:

</P>

<PRE>
.stabs "float:t12=r1;4;0;",128,0,0,0
.stabs "double:t13=r1;8;0;",128,0,0,0
</PRE>

<P>
However, GCC writes <CODE>long double</CODE> the same way it writes
<CODE>double</CODE>, so there is no way to distinguish.

</P>

<PRE>
.stabs "long double:t14=r1;8;0;",128,0,0,0
</PRE>

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

</P>
<P>
The C <CODE>void</CODE> type is defined as itself:

</P>

<PRE>
.stabs "void:t15=15",128,0,0,0
</PRE>

<P>
I'm not sure how a boolean type is represented.

</P>


<H3><A NAME="SEC34" HREF="stabs_toc.html#TOC34">Defining Builtin Types Using Builtin Type Descriptors</A></H3>

<P>
This is the method used by Sun's <CODE>acc</CODE> for defining builtin types.
These are the type descriptors to define builtin types:

</P>
<DL COMPACT>

<DT><CODE>b <VAR>signed</VAR> <VAR>char-flag</VAR> <VAR>width</VAR> ; <VAR>offset</VAR> ; <VAR>nbits</VAR> ;</CODE>
<DD>
Define an integral type.  <VAR>signed</VAR> is <SAMP>`u'</SAMP> for unsigned or
<SAMP>`s'</SAMP> for signed.  <VAR>char-flag</VAR> is <SAMP>`c'</SAMP> which indicates this
is a character type, or is omitted.  I assume this is to distinguish an
integral type from a character type of the same size, for example it
might make sense to set it for the C type <CODE>wchar_t</CODE> so the debugger
can print such variables differently (Solaris does not do this).  Sun
sets it on the C types <CODE>signed char</CODE> and <CODE>unsigned char</CODE> which
arguably is wrong.  <VAR>width</VAR> and <VAR>offset</VAR> appear to be for small
objects stored in larger ones, for example a <CODE>short</CODE> in an
<CODE>int</CODE> register.  <VAR>width</VAR> is normally the number of bytes in the
type.  <VAR>offset</VAR> seems to always be zero.  <VAR>nbits</VAR> is the number
of bits in the type.

Note that type descriptor <SAMP>`b'</SAMP> used for builtin types conflicts with
its use for Pascal space types (see section <A HREF="stabs.html#SEC36">Miscellaneous Types</A>); they can
be distinguished because the character following the type descriptor
will be a digit, <SAMP>`('</SAMP>, or <SAMP>`-'</SAMP> for a Pascal space type, or
<SAMP>`u'</SAMP> or <SAMP>`s'</SAMP> for a builtin type.

<DT><CODE>w</CODE>
<DD>
Documented by AIX to define a wide character type, but their compiler
actually uses negative type numbers (see section <A HREF="stabs.html#SEC35">Negative Type Numbers</A>).

<DT><CODE>R <VAR>fp-type</VAR> ; <VAR>bytes</VAR> ;</CODE>
<DD>
Define a floating point type.  <VAR>fp-type</VAR> has one of the following values:

<DL COMPACT>

<DT><CODE>1 (NF_SINGLE)</CODE>
<DD>
IEEE 32-bit (single precision) floating point format.

<DT><CODE>2 (NF_DOUBLE)</CODE>
<DD>
IEEE 64-bit (double precision) floating point format.

<DT><CODE>3 (NF_COMPLEX)</CODE>
<DD>
<DT><CODE>4 (NF_COMPLEX16)</CODE>
<DD>
<DT><CODE>5 (NF_COMPLEX32)</CODE>
<DD>
These are for complex numbers.  A comment in the GDB source describes
them as Fortran <CODE>complex</CODE>, <CODE>double complex</CODE>, and
<CODE>complex*16</CODE>, respectively, but what does that mean?  (i.e., Single
precision?  Double precision?).

<DT><CODE>6 (NF_LDOUBLE)</CODE>
<DD>
Long double.  This should probably only be used for Sun format
<CODE>long double</CODE>, and new codes should be used for other floating
point formats (<CODE>NF_DOUBLE</CODE> can be used if a <CODE>long double</CODE> is
really just an IEEE double, of course).
</DL>

<VAR>bytes</VAR> is the number of bytes occupied by the type.  This allows a
debugger to perform some operations with the type even if it doesn't
understand <VAR>fp-type</VAR>.

<DT><CODE>g <VAR>type-information</VAR> ; <VAR>nbits</VAR></CODE>
<DD>
Documented by AIX to define a floating type, but their compiler actually
uses negative type numbers (see section <A HREF="stabs.html#SEC35">Negative Type Numbers</A>).

<DT><CODE>c <VAR>type-information</VAR> ; <VAR>nbits</VAR></CODE>
<DD>
Documented by AIX to define a complex type, but their compiler actually
uses negative type numbers (see section <A HREF="stabs.html#SEC35">Negative Type Numbers</A>).
</DL>

<P>
The C <CODE>void</CODE> type is defined as a signed integral type 0 bits long:

<PRE>
.stabs "void:t19=bs0;0;0",128,0,0,0
</PRE>

<P>
The Solaris compiler seems to omit the trailing semicolon in this case.
Getting sloppy in this way is not a swift move because if a type is
embedded in a more complex expression it is necessary to be able to tell
where it ends.

</P>
<P>
I'm not sure how a boolean type is represented.

</P>


<H3><A NAME="SEC35" HREF="stabs_toc.html#TOC35">Negative Type Numbers</A></H3>

<P>
This is the method used in XCOFF for defining builtin types.
Since the debugger knows about the builtin types anyway, the idea of
negative type numbers is simply to give a special type number which
indicates the builtin type.  There is no stab defining these types.

</P>
<P>
There are several subtle issues with negative type numbers.

</P>
<P>
One is the size of the type.  A builtin type (for example the C types
<CODE>int</CODE> or <CODE>long</CODE>) might have different sizes depending on
compiler options, the target architecture, the ABI, etc.  This issue
doesn't come up for IBM tools since (so far) they just target the
RS/6000; the sizes indicated below for each size are what the IBM
RS/6000 tools use.  To deal with differing sizes, either define separate
negative type numbers for each size (which works but requires changing
the debugger, and, unless you get both AIX dbx and GDB to accept the
change, introduces an incompatibility), or use a type attribute
(see section <A HREF="stabs.html#SEC4">The String Field</A>) to define a new type with the appropriate size
(which merely requires a debugger which understands type attributes,
like AIX dbx or GDB).  For example,

</P>

<PRE>
.stabs "boolean:t10=@s8;-16",128,0,0,0
</PRE>

<P>
defines an 8-bit boolean type, and

</P>

<PRE>
.stabs "boolean:t10=@s64;-16",128,0,0,0
</PRE>

<P>
defines a 64-bit boolean type.

</P>
<P>
A similar issue is the format of the type.  This comes up most often for
floating-point types, which could have various formats (particularly
extended doubles, which vary quite a bit even among IEEE systems).
Again, it is best to define a new negative type number for each
different format; changing the format based on the target system has
various problems.  One such problem is that the Alpha has both VAX and
IEEE floating types.  One can easily imagine one library using the VAX
types and another library in the same executable using the IEEE types.
Another example is that the interpretation of whether a boolean is true
or false can be based on the least significant bit, most significant
bit, whether it is zero, etc., and different compilers (or different
options to the same compiler) might provide different kinds of boolean.

</P>
<P>
The last major issue is the names of the types.  The name of a given
type depends <EM>only</EM> on the negative type number given; these do not
vary depending on the language, the target system, or anything else.
One can always define separate type numbers--in the following list you
will see for example separate <C