1316 lines
62 KiB
HTML
1316 lines
62 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on August, 1 2002 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>STABS: Types</TITLE>
|
|
|
|
<META NAME="description" CONTENT="STABS: Types">
|
|
<META NAME="keywords" CONTENT="STABS: Types">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC29"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_4.html#SEC28"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC30"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 5. Defining Types </H1>
|
|
<!--docid::SEC29::-->
|
|
<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><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC30">5.1 Builtin Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Integers, floating point, void, etc.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC36">5.2 Miscellaneous Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Pointers, sets, files, etc.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC37">5.3 Cross-References to Other Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Referring to a type not yet defined.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC38">5.4 Subrange Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">A type with a specific range.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC39">5.5 Array Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">An aggregate type of same-typed elements.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC40">5.6 Strings</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Like an array but also has a length.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC41">5.7 Enumerations</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Like an integer but the values have names.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC42">5.8 Structures</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">An aggregate type of different-typed elements.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC43">5.9 Giving a Type a Name</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Giving a type a name.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC44">5.10 Unions</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Different types sharing storage.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC45">5.11 Function Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Builtin Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC30"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC31"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.1 Builtin Types </H2>
|
|
<!--docid::SEC30::-->
|
|
<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><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC31">5.1.1 Traditional Builtin Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Put on your seat belts and prepare for kludgery</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC34">5.1.2 Defining Builtin Types Using Builtin Type Descriptors</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Builtin types with special type descriptors</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC35">5.1.3 Negative Type Numbers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Builtin types using negative type numbers</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Traditional Builtin Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC31"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC30"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC32"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC30"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC34"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 5.1.1 Traditional Builtin Types </H3>
|
|
<!--docid::SEC31::-->
|
|
<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><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC32">5.1.1.1 Traditional Integer Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_5.html#SEC33">5.1.1.2 Traditional Other Types</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Traditional Integer Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC32"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC31"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC33"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC31"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC34"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H4> 5.1.1.1 Traditional Integer Types </H4>
|
|
<!--docid::SEC32::-->
|
|
<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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><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></td></tr></table></P><P>
|
|
|
|
Builtin types can also be described as subranges of <CODE>int</CODE>:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "unsigned short:t6=r1;0;65535;",128,0,0,0
|
|
</pre></td></tr></table></P><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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "unsigned int:t4=r1;0;-1;",128,0,0,0
|
|
</pre></td></tr></table></P><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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>long int:t3=r1;001000000000000000000000;000777777777777777777777;
|
|
long unsigned int:t5=r1;000000000000000000000000;001777777777777777777777;
|
|
</pre></td></tr></table></P><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><P>
|
|
|
|
<A NAME="Traditional Other Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC33"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC32"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC34"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC31"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC34"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H4> 5.1.1.2 Traditional Other Types </H4>
|
|
<!--docid::SEC33::-->
|
|
<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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "float:t12=r1;4;0;",128,0,0,0
|
|
.stabs "double:t13=r1;8;0;",128,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
However, GCC writes <CODE>long double</CODE> the same way it writes
|
|
<CODE>double</CODE>, so there is no way to distinguish.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "long double:t14=r1;8;0;",128,0,0,0
|
|
</pre></td></tr></table></P><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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "void:t15=15",128,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
I'm not sure how a boolean type is represented.
|
|
</P><P>
|
|
|
|
<A NAME="Builtin Type Descriptors"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC34"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC33"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC35"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC35"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC30"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 5.1.2 Defining Builtin Types Using Builtin Type Descriptors </H3>
|
|
<!--docid::SEC34::-->
|
|
<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><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.
|
|
<P>
|
|
|
|
Note that type descriptor <SAMP>`b'</SAMP> used for builtin types conflicts with
|
|
its use for Pascal space types (see section <A HREF="stabs_5.html#SEC36">5.2 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.
|
|
</P><P>
|
|
|
|
<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_5.html#SEC35">5.1.3 Negative Type Numbers</A>).
|
|
<P>
|
|
|
|
<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:
|
|
<P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>1 (NF_SINGLE)</CODE>
|
|
<DD>IEEE 32-bit (single precision) floating point format.
|
|
<P>
|
|
|
|
<DT><CODE>2 (NF_DOUBLE)</CODE>
|
|
<DD>IEEE 64-bit (double precision) floating point format.
|
|
<P>
|
|
|
|
<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?).
|
|
<P>
|
|
|
|
<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>
|
|
<P>
|
|
|
|
<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>.
|
|
</P><P>
|
|
|
|
<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_5.html#SEC35">5.1.3 Negative Type Numbers</A>).
|
|
<P>
|
|
|
|
<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_5.html#SEC35">5.1.3 Negative Type Numbers</A>).
|
|
</DL>
|
|
<P>
|
|
|
|
The C <CODE>void</CODE> type is defined as a signed integral type 0 bits long:
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "void:t19=bs0;0;0",128,0,0,0
|
|
</pre></td></tr></table>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><P>
|
|
|
|
<A NAME="Negative Type Numbers"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC35"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC34"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC30"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 5.1.3 Negative Type Numbers </H3>
|
|
<!--docid::SEC35::-->
|
|
<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_1.html#SEC4">1.3 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><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "boolean:t10=@s8;-16",128,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
defines an 8-bit boolean type, and
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "boolean:t10=@s64;-16",128,0,0,0
|
|
</pre></td></tr></table></P><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 <CODE>int</CODE> and <CODE>integer*4</CODE> types
|
|
which are identical except for the name. But compatibility can be
|
|
maintained by not inventing new negative type numbers and instead just
|
|
defining a new type with a new name. For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "CARDINAL:t10=-8",128,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Here is the list of negative type numbers. The phrase <EM>integral
|
|
type</EM> is used to mean twos-complement (I strongly suspect that all
|
|
machines which use stabs use twos-complement; most machines use
|
|
twos-complement these days).
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>-1</CODE>
|
|
<DD><CODE>int</CODE>, 32 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-2</CODE>
|
|
<DD><CODE>char</CODE>, 8 bit type holding a character. Both GDB and dbx on AIX
|
|
treat this as signed. GCC uses this type whether <CODE>char</CODE> is signed
|
|
or not, which seems like a bad idea. The AIX compiler (<CODE>xlc</CODE>) seems to
|
|
avoid this type; it uses -5 instead for <CODE>char</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>-3</CODE>
|
|
<DD><CODE>short</CODE>, 16 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-4</CODE>
|
|
<DD><CODE>long</CODE>, 32 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-5</CODE>
|
|
<DD><CODE>unsigned char</CODE>, 8 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-6</CODE>
|
|
<DD><CODE>signed char</CODE>, 8 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-7</CODE>
|
|
<DD><CODE>unsigned short</CODE>, 16 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-8</CODE>
|
|
<DD><CODE>unsigned int</CODE>, 32 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-9</CODE>
|
|
<DD><CODE>unsigned</CODE>, 32 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-10</CODE>
|
|
<DD><CODE>unsigned long</CODE>, 32 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-11</CODE>
|
|
<DD><CODE>void</CODE>, type indicating the lack of a value.
|
|
<P>
|
|
|
|
<DT><CODE>-12</CODE>
|
|
<DD><CODE>float</CODE>, IEEE single precision.
|
|
<P>
|
|
|
|
<DT><CODE>-13</CODE>
|
|
<DD><CODE>double</CODE>, IEEE double precision.
|
|
<P>
|
|
|
|
<DT><CODE>-14</CODE>
|
|
<DD><CODE>long double</CODE>, IEEE double precision. The compiler claims the size
|
|
will increase in a future release, and for binary compatibility you have
|
|
to avoid using <CODE>long double</CODE>. I hope when they increase it they
|
|
use a new negative type number.
|
|
<P>
|
|
|
|
<DT><CODE>-15</CODE>
|
|
<DD><CODE>integer</CODE>. 32 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-16</CODE>
|
|
<DD><CODE>boolean</CODE>. 32 bit type. GDB and GCC assume that zero is false,
|
|
one is true, and other values have unspecified meaning. I hope this
|
|
agrees with how the IBM tools use the type.
|
|
<P>
|
|
|
|
<DT><CODE>-17</CODE>
|
|
<DD><CODE>short real</CODE>. IEEE single precision.
|
|
<P>
|
|
|
|
<DT><CODE>-18</CODE>
|
|
<DD><CODE>real</CODE>. IEEE double precision.
|
|
<P>
|
|
|
|
<DT><CODE>-19</CODE>
|
|
<DD><CODE>stringptr</CODE>. See section <A HREF="stabs_5.html#SEC40">5.6 Strings</A>.
|
|
<P>
|
|
|
|
<DT><CODE>-20</CODE>
|
|
<DD><CODE>character</CODE>, 8 bit unsigned character type.
|
|
<P>
|
|
|
|
<DT><CODE>-21</CODE>
|
|
<DD><CODE>logical*1</CODE>, 8 bit type. This Fortran type has a split
|
|
personality in that it is used for boolean variables, but can also be
|
|
used for unsigned integers. 0 is false, 1 is true, and other values are
|
|
non-boolean.
|
|
<P>
|
|
|
|
<DT><CODE>-22</CODE>
|
|
<DD><CODE>logical*2</CODE>, 16 bit type. This Fortran type has a split
|
|
personality in that it is used for boolean variables, but can also be
|
|
used for unsigned integers. 0 is false, 1 is true, and other values are
|
|
non-boolean.
|
|
<P>
|
|
|
|
<DT><CODE>-23</CODE>
|
|
<DD><CODE>logical*4</CODE>, 32 bit type. This Fortran type has a split
|
|
personality in that it is used for boolean variables, but can also be
|
|
used for unsigned integers. 0 is false, 1 is true, and other values are
|
|
non-boolean.
|
|
<P>
|
|
|
|
<DT><CODE>-24</CODE>
|
|
<DD><CODE>logical</CODE>, 32 bit type. This Fortran type has a split
|
|
personality in that it is used for boolean variables, but can also be
|
|
used for unsigned integers. 0 is false, 1 is true, and other values are
|
|
non-boolean.
|
|
<P>
|
|
|
|
<DT><CODE>-25</CODE>
|
|
<DD><CODE>complex</CODE>. A complex type consisting of two IEEE single-precision
|
|
floating point values.
|
|
<P>
|
|
|
|
<DT><CODE>-26</CODE>
|
|
<DD><CODE>complex</CODE>. A complex type consisting of two IEEE double-precision
|
|
floating point values.
|
|
<P>
|
|
|
|
<DT><CODE>-27</CODE>
|
|
<DD><CODE>integer*1</CODE>, 8 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-28</CODE>
|
|
<DD><CODE>integer*2</CODE>, 16 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-29</CODE>
|
|
<DD><CODE>integer*4</CODE>, 32 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-30</CODE>
|
|
<DD><CODE>wchar</CODE>. Wide character, 16 bits wide, unsigned (what format?
|
|
Unicode?).
|
|
<P>
|
|
|
|
<DT><CODE>-31</CODE>
|
|
<DD><CODE>long long</CODE>, 64 bit signed integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-32</CODE>
|
|
<DD><CODE>unsigned long long</CODE>, 64 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-33</CODE>
|
|
<DD><CODE>logical*8</CODE>, 64 bit unsigned integral type.
|
|
<P>
|
|
|
|
<DT><CODE>-34</CODE>
|
|
<DD><CODE>integer*8</CODE>, 64 bit signed integral type.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Miscellaneous Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC36"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC35"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC37"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC37"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.2 Miscellaneous Types </H2>
|
|
<!--docid::SEC36::-->
|
|
<P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>b <VAR>type-information</VAR> ; <VAR>bytes</VAR></CODE>
|
|
<DD>Pascal space type. This is documented by IBM; what does it mean?
|
|
<P>
|
|
|
|
This use of the <SAMP>`b'</SAMP> type descriptor can be distinguished
|
|
from its use for builtin integral types (see section <A HREF="stabs_5.html#SEC34">5.1.2 Defining Builtin Types Using Builtin Type Descriptors</A>) because the character following the type descriptor is
|
|
always a digit, <SAMP>`('</SAMP>, or <SAMP>`-'</SAMP>.
|
|
</P><P>
|
|
|
|
<DT><CODE>B <VAR>type-information</VAR></CODE>
|
|
<DD>A volatile-qualified version of <VAR>type-information</VAR>. This is
|
|
a Sun extension. References and stores to a variable with a
|
|
volatile-qualified type must not be optimized or cached; they
|
|
must occur as the user specifies them.
|
|
<P>
|
|
|
|
<DT><CODE>d <VAR>type-information</VAR></CODE>
|
|
<DD>File of type <VAR>type-information</VAR>. As far as I know this is only used
|
|
by Pascal.
|
|
<P>
|
|
|
|
<DT><CODE>k <VAR>type-information</VAR></CODE>
|
|
<DD>A const-qualified version of <VAR>type-information</VAR>. This is a Sun
|
|
extension. A variable with a const-qualified type cannot be modified.
|
|
<P>
|
|
|
|
<DT><CODE>M <VAR>type-information</VAR> ; <VAR>length</VAR></CODE>
|
|
<DD>Multiple instance type. The type seems to composed of <VAR>length</VAR>
|
|
repetitions of <VAR>type-information</VAR>, for example <CODE>character*3</CODE> is
|
|
represented by <SAMP>`M-2;3'</SAMP>, where <SAMP>`-2'</SAMP> is a reference to a
|
|
character type (see section <A HREF="stabs_5.html#SEC35">5.1.3 Negative Type Numbers</A>). I'm not sure how this
|
|
differs from an array. This appears to be a Fortran feature.
|
|
<VAR>length</VAR> is a bound, like those in range types; see <A HREF="stabs_5.html#SEC38">5.4 Subrange Types</A>.
|
|
<P>
|
|
|
|
<DT><CODE>S <VAR>type-information</VAR></CODE>
|
|
<DD>Pascal set type. <VAR>type-information</VAR> must be a small type such as an
|
|
enumeration or a subrange, and the type is a bitmask whose length is
|
|
specified by the number of elements in <VAR>type-information</VAR>.
|
|
<P>
|
|
|
|
In CHILL,
|
|
if it is a bitstring instead of a set, also use the <SAMP>`S'</SAMP>
|
|
type attribute (see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>).
|
|
</P><P>
|
|
|
|
<DT><CODE>* <VAR>type-information</VAR></CODE>
|
|
<DD>Pointer to <VAR>type-information</VAR>.
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="Cross-References"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC37"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC38"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC38"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.3 Cross-References to Other Types </H2>
|
|
<!--docid::SEC37::-->
|
|
<P>
|
|
|
|
A type can be used before it is defined; one common way to deal with
|
|
that situation is just to use a type reference to a type which has not
|
|
yet been defined.
|
|
</P><P>
|
|
|
|
Another way is with the <SAMP>`x'</SAMP> type descriptor, which is followed by
|
|
<SAMP>`s'</SAMP> for a structure tag, <SAMP>`u'</SAMP> for a union tag, or <SAMP>`e'</SAMP> for
|
|
a enumerator tag, followed by the name of the tag, followed by <SAMP>`:'</SAMP>.
|
|
If the name contains <SAMP>`::'</SAMP> between a <SAMP>`<'</SAMP> and <SAMP>`>'</SAMP> pair (for
|
|
C++ templates), such a <SAMP>`::'</SAMP> does not end the name--only a single
|
|
<SAMP>`:'</SAMP> ends the name; see <A HREF="stabs_7.html#SEC54">7.2 Defining a Symbol Within Another Type</A>.
|
|
</P><P>
|
|
|
|
For example, the following C declarations:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct foo;
|
|
struct foo *bar;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
produce:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "bar:G16=*17=xsfoo:",32,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
Not all debuggers support the <SAMP>`x'</SAMP> type descriptor, so on some
|
|
machines GCC does not use it. I believe that for the above example it
|
|
would just emit a reference to type 17 and never define it, but I
|
|
haven't verified that.
|
|
</P><P>
|
|
|
|
Modula-2 imported types, at least on AIX, use the <SAMP>`i'</SAMP> type
|
|
descriptor, which is followed by the name of the module from which the
|
|
type is imported, followed by <SAMP>`:'</SAMP>, followed by the name of the
|
|
type. There is then optionally a comma followed by type information for
|
|
the type. This differs from merely naming the type (see section <A HREF="stabs_5.html#SEC43">5.9 Giving a Type a Name</A>) 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
|
|
(see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>), or what. The symbol ends with <SAMP>`;'</SAMP>.
|
|
</P><P>
|
|
|
|
<A NAME="Subranges"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC38"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC37"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC39"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC39"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.4 Subrange Types </H2>
|
|
<!--docid::SEC38::-->
|
|
<P>
|
|
|
|
The <SAMP>`r'</SAMP> type descriptor defines a type as a subrange of another
|
|
type. It is followed by type information for the type of which it is a
|
|
subrange, a semicolon, an integral lower bound, a semicolon, an
|
|
integral upper bound, and a semicolon. The AIX documentation does not
|
|
specify the trailing semicolon, in an effort to specify array indexes
|
|
more cleanly, but a subrange which is not an array index has always
|
|
included a trailing semicolon (see section <A HREF="stabs_5.html#SEC39">5.5 Array Types</A>).
|
|
</P><P>
|
|
|
|
Instead of an integer, either bound can be one of the following:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>A <VAR>offset</VAR></CODE>
|
|
<DD>The bound is passed by reference on the stack at offset <VAR>offset</VAR>
|
|
from the argument list. See section <A HREF="stabs_4.html#SEC24">4.7 Parameters</A>, for more information on such
|
|
offsets.
|
|
<P>
|
|
|
|
<DT><CODE>T <VAR>offset</VAR></CODE>
|
|
<DD>The bound is passed by value on the stack at offset <VAR>offset</VAR> from
|
|
the argument list.
|
|
<P>
|
|
|
|
<DT><CODE>a <VAR>register-number</VAR></CODE>
|
|
<DD>The bound is passed by reference in register number
|
|
<VAR>register-number</VAR>.
|
|
<P>
|
|
|
|
<DT><CODE>t <VAR>register-number</VAR></CODE>
|
|
<DD>The bound is passed by value in register number <VAR>register-number</VAR>.
|
|
<P>
|
|
|
|
<DT><CODE>J</CODE>
|
|
<DD>There is no bound.
|
|
</DL>
|
|
<P>
|
|
|
|
Subranges are also used for builtin types; see <A HREF="stabs_5.html#SEC31">5.1.1 Traditional Builtin Types</A>.
|
|
</P><P>
|
|
|
|
<A NAME="Arrays"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC39"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC38"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC40"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC40"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.5 Array Types </H2>
|
|
<!--docid::SEC39::-->
|
|
<P>
|
|
|
|
Arrays use the <SAMP>`a'</SAMP> type descriptor. Following the type descriptor
|
|
is the type of the index and the type of the array elements. If the
|
|
index type is a range type, it ends in a semicolon; otherwise
|
|
(for example, if it is a type reference), there does not
|
|
appear to be any way to tell where the types are separated. In an
|
|
effort to clean up this mess, IBM documents the two types as being
|
|
separated by a semicolon, and a range type as not ending in a semicolon
|
|
(but this is not right for range types which are not array indexes,
|
|
see section <A HREF="stabs_5.html#SEC38">5.4 Subrange Types</A>). I think probably the best solution is to specify
|
|
that a semicolon ends a range type, and that the index type and element
|
|
type of an array are separated by a semicolon, but that if the index
|
|
type is a range type, the extra semicolon can be omitted. GDB (at least
|
|
through version 4.9) doesn't support any kind of index type other than a
|
|
range anyway; I'm not sure about dbx.
|
|
</P><P>
|
|
|
|
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 (see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>) (that is, it need not start with
|
|
<SAMP>`<VAR>type-number</VAR>='</SAMP> 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'</SAMP> as a legitimate way to express a two
|
|
dimensional array. According to AIX documentation, the element type
|
|
must be type information. GDB accepts either.
|
|
</P><P>
|
|
|
|
The type of the index is often a range type, expressed as the type
|
|
descriptor <SAMP>`r'</SAMP> and some parameters. It defines the size of the
|
|
array. In the example below, the range <SAMP>`r1;0;2;'</SAMP> defines an index
|
|
type which is a subrange of type 1 (integer), with a lower bound of 0
|
|
and an upper bound of 2. This defines the valid range of subscripts of
|
|
a three-element C array.
|
|
</P><P>
|
|
|
|
For example, the definition:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>char char_vec[3] = {'a','b','c'};
|
|
</pre></td></tr></table></P><P>
|
|
|
|
produces the output:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "char_vec:G19=ar1;0;2;2",32,0,0,0
|
|
.global _char_vec
|
|
.align 4
|
|
_char_vec:
|
|
.byte 97
|
|
.byte 98
|
|
.byte 99
|
|
</pre></td></tr></table></P><P>
|
|
|
|
If an array is <EM>packed</EM>, the elements are spaced more
|
|
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
|
|
(see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>). In the case of arrays, another is to use the
|
|
<SAMP>`P'</SAMP> type descriptor instead of <SAMP>`a'</SAMP>. Other than specifying a
|
|
packed array, <SAMP>`P'</SAMP> is identical to <SAMP>`a'</SAMP>.
|
|
</P><P>
|
|
|
|
An open array is represented by the <SAMP>`A'</SAMP> type descriptor followed by
|
|
type information specifying the type of the array elements.
|
|
</P><P>
|
|
|
|
An N-dimensional dynamic array is represented by
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>D <VAR>dimensions</VAR> ; <VAR>type-information</VAR>
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<VAR>dimensions</VAR> is the number of dimensions; <VAR>type-information</VAR>
|
|
specifies the type of the array elements.
|
|
</P><P>
|
|
|
|
A subarray of an N-dimensional array is represented by
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>E <VAR>dimensions</VAR> ; <VAR>type-information</VAR>
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<VAR>dimensions</VAR> is the number of dimensions; <VAR>type-information</VAR>
|
|
specifies the type of the array elements.
|
|
</P><P>
|
|
|
|
<A NAME="Strings"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC40"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC39"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC41"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC41"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.6 Strings </H2>
|
|
<!--docid::SEC40::-->
|
|
<P>
|
|
|
|
Some languages, like C or the original Pascal, do not have string types,
|
|
they just have related things like arrays of characters. But most
|
|
Pascals and various other languages have string types, which are
|
|
indicated as follows:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>n <VAR>type-information</VAR> ; <VAR>bytes</VAR></CODE>
|
|
<DD><VAR>bytes</VAR> is the maximum length. I'm not sure what
|
|
<VAR>type-information</VAR> is; I suspect that it means that this is a string
|
|
of <VAR>type-information</VAR> (thus allowing a string of integers, a string
|
|
of wide characters, etc., as well as a string of characters). Not sure
|
|
what the format of this type is. This is an AIX feature.
|
|
<P>
|
|
|
|
<DT><CODE>z <VAR>type-information</VAR> ; <VAR>bytes</VAR></CODE>
|
|
<DD>Just like <SAMP>`n'</SAMP> except that this is a gstring, not an ordinary
|
|
string. I don't know the difference.
|
|
<P>
|
|
|
|
<DT><CODE>N</CODE>
|
|
<DD>Pascal Stringptr. What is this? This is an AIX feature.
|
|
</DL>
|
|
<P>
|
|
|
|
Languages, such as CHILL
|
|
which have a string type which is basically
|
|
just an array of characters use the <SAMP>`S'</SAMP> type attribute
|
|
(see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>).
|
|
</P><P>
|
|
|
|
<A NAME="Enumerations"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC41"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC40"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC42"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC42"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.7 Enumerations </H2>
|
|
<!--docid::SEC41::-->
|
|
<P>
|
|
|
|
Enumerations are defined with the <SAMP>`e'</SAMP> type descriptor.
|
|
</P><P>
|
|
|
|
The source line below declares an enumeration type at file scope.
|
|
The type definition is located after the <CODE>N_RBRAC</CODE> that marks the end of
|
|
the previous procedure's block scope, and before the <CODE>N_FUN</CODE> that marks
|
|
the beginning of the next procedure's block scope. Therefore it does not
|
|
describe a block local symbol, but a file local one.
|
|
</P><P>
|
|
|
|
The source line:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>enum e_places {first,second=3,last};
|
|
</pre></td></tr></table></P><P>
|
|
|
|
generates the following stab:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "e_places:T22=efirst:0,second:3,last:4,;",128,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The symbol descriptor (<SAMP>`T'</SAMP>) says that the stab describes a
|
|
structure, enumeration, or union tag. The type descriptor <SAMP>`e'</SAMP>,
|
|
following the <SAMP>`22='</SAMP> of the type definition narrows it down to an
|
|
enumeration type. Following the <SAMP>`e'</SAMP> is a list of the elements of
|
|
the enumeration. The format is <SAMP>`<VAR>name</VAR>:<VAR>value</VAR>,'</SAMP>. The
|
|
list of elements ends with <SAMP>`;'</SAMP>. The fact that <VAR>value</VAR> is
|
|
specified as an integer can cause problems if the value is large. GCC
|
|
2.5.2 tries to output it in octal in that case with a leading zero,
|
|
which is probably a good thing, although GDB 4.11 supports octal only in
|
|
cases where decimal is perfectly good. Negative decimal values are
|
|
supported by both GDB and dbx.
|
|
</P><P>
|
|
|
|
There is no standard way to specify the size of an enumeration type; it
|
|
is determined by the architecture (normally all enumerations types are
|
|
32 bits). Type attributes can be used to specify an enumeration type of
|
|
another size for debuggers which support them; see <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>.
|
|
</P><P>
|
|
|
|
Enumeration types are unusual in that they define symbols for the
|
|
enumeration values (<CODE>first</CODE>, <CODE>second</CODE>, and <CODE>third</CODE> in the
|
|
above example), and even though these symbols are visible in the file as
|
|
a whole (rather than being in a more local namespace like structure
|
|
member names), they are defined in the type definition for the
|
|
enumeration type rather than each having their own symbol. In order to
|
|
be fast, GDB will only get symbols from such types (in its initial scan
|
|
of the stabs) if the type is the first thing defined after a <SAMP>`T'</SAMP> or
|
|
<SAMP>`t'</SAMP> symbol descriptor (the above example fulfills this
|
|
requirement). If the type does not have a name, the compiler should
|
|
emit it in a nameless stab (see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>); GCC does this.
|
|
</P><P>
|
|
|
|
<A NAME="Structures"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC42"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC41"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC43"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC43"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.8 Structures </H2>
|
|
<!--docid::SEC42::-->
|
|
<P>
|
|
|
|
The encoding of structures in stabs can be shown with an example.
|
|
</P><P>
|
|
|
|
The following source code declares a structure tag and defines an
|
|
instance of the structure in global scope. Then a <CODE>typedef</CODE> equates the
|
|
structure tag with a new type. Separate stabs are generated for the
|
|
structure tag, the structure <CODE>typedef</CODE>, and the structure instance. The
|
|
stabs for the tag and the <CODE>typedef</CODE> 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.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>struct s_tag {
|
|
int s_int;
|
|
float s_float;
|
|
char s_char_vec[8];
|
|
struct s_tag* s_next;
|
|
} g_an_s;
|
|
|
|
typedef struct s_tag s_typedef;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The structure tag has an <CODE>N_LSYM</CODE> stab type because, like the
|
|
enumeration, the symbol has file scope. Like the enumeration, the
|
|
symbol descriptor is <SAMP>`T'</SAMP>, for enumeration, structure, or tag type.
|
|
The type descriptor <SAMP>`s'</SAMP> following the <SAMP>`16='</SAMP> of the type
|
|
definition narrows the symbol type to structure.
|
|
</P><P>
|
|
|
|
Following the <SAMP>`s'</SAMP> 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</VAR>.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre># 128 is N_LSYM
|
|
.stabs "s_tag:T16=s20s_int:1,0,32;s_float:12,32,32;
|
|
s_char_vec:17=ar1;0;7;2,64,64;s_next:18=*16,128,32;;",128,0,0,0
|
|
</pre></td></tr></table></P><P>
|
|
|
|
In this example, the first two structure elements are previously defined
|
|
types. For these, the type following the <SAMP>`<VAR>name</VAR>:'</SAMP> part of the
|
|
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</VAR>:'</SAMP>. The type definition for the
|
|
array element looks just like a type definition for a stand-alone array.
|
|
The <CODE>s_next</CODE> 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.
|
|
</P><P>
|
|
|
|
If a field is a static member (this is a C++ 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.
|
|
</P><P>
|
|
|
|
If the structure has methods (a C++ feature), they follow the non-method
|
|
fields; see <A HREF="stabs_7.html#SEC52">7. GNU C++ Stabs</A>.
|
|
</P><P>
|
|
|
|
<A NAME="Typedefs"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC43"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC42"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC44"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.9 Giving a Type a Name </H2>
|
|
<!--docid::SEC43::-->
|
|
<P>
|
|
|
|
<A NAME="IDX49"></A>
|
|
<A NAME="IDX50"></A>
|
|
To give a type a name, use the <SAMP>`t'</SAMP> symbol descriptor. The type
|
|
is specified by the type information (see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>) for the stab.
|
|
For example,
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "s_typedef:t16",128,0,0,0 # 128 is N_LSYM
|
|
</pre></td></tr></table></P><P>
|
|
|
|
specifies that <CODE>s_typedef</CODE> refers to type number 16. Such stabs
|
|
have symbol type <CODE>N_LSYM</CODE> (or <CODE>C_DECL</CODE> for XCOFF). (The Sun
|
|
documentation mentions using <CODE>N_GSYM</CODE> in some cases).
|
|
</P><P>
|
|
|
|
If you are specifying the tag name for a structure, union, or
|
|
enumeration, use the <SAMP>`T'</SAMP> symbol descriptor instead. I believe C is
|
|
the only language with this feature.
|
|
</P><P>
|
|
|
|
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'</SAMP> 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 (see section <A HREF="stabs_1.html#SEC4">1.3 The String Field</A>)? 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
|
|
pointer type--it has a known size but little else about it is
|
|
specified.
|
|
</P><P>
|
|
|
|
<A NAME="Unions"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC44"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC43"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC45"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.10 Unions </H2>
|
|
<!--docid::SEC44::-->
|
|
<P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>union u_tag {
|
|
int u_int;
|
|
float u_float;
|
|
char* u_char;
|
|
} an_u;
|
|
</pre></td></tr></table></P><P>
|
|
|
|
This code generates a stab for a union tag and a stab for a union
|
|
variable. Both use the <CODE>N_LSYM</CODE> stab type. If a union variable is
|
|
scoped locally to the procedure in which it is defined, its stab is
|
|
located immediately preceding the <CODE>N_LBRAC</CODE> for the procedure's block
|
|
start.
|
|
</P><P>
|
|
|
|
The stab for the union tag, however, is located preceding the code for
|
|
the procedure in which it is defined. The stab type is <CODE>N_LSYM</CODE>. This
|
|
would seem to imply that the union type is file scope, like the struct
|
|
type <CODE>s_tag</CODE>. This is not true. The contents and position of the stab
|
|
for <CODE>u_type</CODE> do not convey any information about its procedure local
|
|
scope.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre># 128 is N_LSYM
|
|
.stabs "u_tag:T23=u4u_int:1,0,32;u_float:12,0,32;u_char:21,0,32;;",
|
|
128,0,0,0
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
The symbol descriptor <SAMP>`T'</SAMP>, following the <SAMP>`name:'</SAMP> means that
|
|
the stab describes an enumeration, structure, or union tag. The type
|
|
descriptor <SAMP>`u'</SAMP>, following the <SAMP>`23='</SAMP> of the type definition,
|
|
narrows it down to a union type definition. Following the <SAMP>`u'</SAMP> 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;</VAR>.
|
|
</P><P>
|
|
|
|
The stab for the union variable is:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "an_u:23",128,0,0,-20 # 128 is N_LSYM
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<SAMP>`-20'</SAMP> specifies where the variable is stored (see section <A HREF="stabs_4.html#SEC18">4.1 Automatic Variables Allocated on the Stack</A>).
|
|
</P><P>
|
|
|
|
<A NAME="Function Types"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC45"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC44"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC29"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 5.11 Function Types </H2>
|
|
<!--docid::SEC45::-->
|
|
<P>
|
|
|
|
Various types can be defined for function variables. These types are
|
|
not used in defining functions (see section <A HREF="stabs_2.html#SEC12">2.5 Procedures</A>); they are used for
|
|
things like pointers to functions.
|
|
</P><P>
|
|
|
|
The simple, traditional, type is type descriptor <SAMP>`f'</SAMP> is followed by
|
|
type information for the return type of the function, followed by a
|
|
semicolon.
|
|
</P><P>
|
|
|
|
This does not deal with functions for which the number and types of the
|
|
parameters are part of the type, as in Modula-2 or ANSI C. AIX provides
|
|
extensions to specify these, using the <SAMP>`f'</SAMP>, <SAMP>`F'</SAMP>, <SAMP>`p'</SAMP>, and
|
|
<SAMP>`R'</SAMP> type descriptors.
|
|
</P><P>
|
|
|
|
First comes the type descriptor. If it is <SAMP>`f'</SAMP> or <SAMP>`F'</SAMP>, this
|
|
type involves a function rather than a procedure, and the type
|
|
information for the return type of the function follows, followed by a
|
|
comma. Then comes the number of parameters to the function and a
|
|
semicolon. Then, for each parameter, there is the name of the parameter
|
|
followed by a colon (this is only present for type descriptors <SAMP>`R'</SAMP>
|
|
and <SAMP>`F'</SAMP> which represent Pascal function or procedure parameters),
|
|
type information for the parameter, a comma, 0 if passed by reference or
|
|
1 if passed by value, and a semicolon. The type definition ends with a
|
|
semicolon.
|
|
</P><P>
|
|
|
|
For example, this variable definition:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int (*g_pf)();
|
|
</pre></td></tr></table></P><P>
|
|
|
|
generates the following code:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "g_pf:G24=*25=f1",32,0,0,0
|
|
.common _g_pf,4,"bss"
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The variable defines a new type, 24, which is a pointer to another new
|
|
type, 25, which is a function returning <CODE>int</CODE>.
|
|
</P><P>
|
|
|
|
<A NAME="Symbol Tables"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_5.html#SEC36"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_6.html#SEC46"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
|
|
<address>
|
|
|
|
<p>Please send FSF & GNU inquiries & questions to <a
|
|
href="mailto:gnu@gnu.org">gnu@gnu.org</a>. There are also <a
|
|
href="http://www.gnu.org/home.html#ContactInfo">other ways to
|
|
contact</a> the FSF.</p>
|
|
|
|
<p>These pages are maintained by <a
|
|
href="http://www.gnu.org/software/gdb/">the GDB developers</a>.</p>
|
|
|
|
<p>Copyright Free Software Foundation, Inc., 59 Temple Place - Suite
|
|
330, Boston, MA 02111, USA.</p>
|
|
|
|
<p>Verbatim copying and distribution of this entire article is
|
|
permitted in any medium, provided this notice is preserved.</p>
|
|
|
|
</address>
|
|
|
|
This document was generated
|
|
by <I>GDB Administrator</I> on <I>August, 1 2002</I>
|
|
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
|
|
"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|