567 lines
30 KiB
HTML
567 lines
30 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 13 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: Program Structure</TITLE>
|
|
|
|
<META NAME="description" CONTENT="STABS: Program Structure">
|
|
<META NAME="keywords" CONTENT="STABS: Program Structure">
|
|
<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="SEC7"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_1.html#SEC6"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC8"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2. Encoding the Structure of the Program </H1>
|
|
<!--docid::SEC7::-->
|
|
<P>
|
|
|
|
The elements of the program structure that stabs encode include the name
|
|
of the main function, the names of the source and include files, the
|
|
line numbers, procedure names and types, and the beginnings and ends of
|
|
blocks of code.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC8">2.1 Main Program</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Indicate what the main program is</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC9">2.2 Paths and Names of the Source Files</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">The path and name of the source file</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC10">2.3 Names of Include Files</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Names of include files</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC11">2.4 Line Numbers</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC12">2.5 Procedures</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC13">2.6 Nested Procedures</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC14">2.7 Block Structure</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP"></TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_2.html#SEC15">2.8 Alternate Entry Points</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Entering procedures except at the beginning.</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Main Program"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC8"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC9"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.1 Main Program </H2>
|
|
<!--docid::SEC8::-->
|
|
<P>
|
|
|
|
<A NAME="IDX1"></A>
|
|
Most languages allow the main program to have any name. The
|
|
<CODE>N_MAIN</CODE> stab type tells the debugger the name that is used in this
|
|
program. Only the string field is significant; it is the name of
|
|
a function which is the main program. Most C compilers do not use this
|
|
stab (they expect the debugger to assume that the name is <CODE>main</CODE>),
|
|
but some C compilers emit an <CODE>N_MAIN</CODE> stab for the <CODE>main</CODE>
|
|
function. I'm not sure how XCOFF handles this.
|
|
</P><P>
|
|
|
|
<A NAME="Source Files"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC9"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC8"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC10"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC10"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.2 Paths and Names of the Source Files </H2>
|
|
<!--docid::SEC9::-->
|
|
<P>
|
|
|
|
<A NAME="IDX2"></A>
|
|
Before any other stabs occur, there must be a stab specifying the source
|
|
file. This information is contained in a symbol of stab type
|
|
<CODE>N_SO</CODE>; the string field contains the name of the file. The
|
|
value of the symbol is the start address of the portion of the
|
|
text section corresponding to that file.
|
|
</P><P>
|
|
|
|
With the Sun Solaris2 compiler, the desc field contains a
|
|
source-language code.
|
|
</P><P>
|
|
|
|
Some compilers (for example, GCC2 and SunOS4 <TT>`/bin/cc'</TT>) also
|
|
include the directory in which the source was compiled, in a second
|
|
<CODE>N_SO</CODE> symbol preceding the one containing the file name. This
|
|
symbol can be distinguished by the fact that it ends in a slash. Code
|
|
from the <CODE>cfront</CODE> C++ compiler can have additional <CODE>N_SO</CODE> symbols for
|
|
nonexistent source files after the <CODE>N_SO</CODE> for the real source file;
|
|
these are believed to contain no useful information.
|
|
</P><P>
|
|
|
|
For example:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "/cygint/s1/users/jcm/play/",100,0,0,Ltext0 # 100 is N_SO
|
|
.stabs "hello.c",100,0,0,Ltext0
|
|
.text
|
|
Ltext0:
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="IDX3"></A>
|
|
Instead of <CODE>N_SO</CODE> symbols, XCOFF uses a <CODE>.file</CODE> assembler
|
|
directive which assembles to a <CODE>C_FILE</CODE> symbol; explaining this in
|
|
detail is outside the scope of this document.
|
|
</P><P>
|
|
|
|
If it is useful to indicate the end of a source file, this is done with
|
|
an <CODE>N_SO</CODE> symbol with an empty string for the name. The value is
|
|
the address of the end of the text section for the file. For some
|
|
systems, there is no indication of the end of a source file, and you
|
|
just need to figure it ended when you see an <CODE>N_SO</CODE> for a different
|
|
source file, or a symbol ending in <CODE>.o</CODE> (which at least some
|
|
linkers insert to mark the start of a new <CODE>.o</CODE> file).
|
|
</P><P>
|
|
|
|
<A NAME="Include Files"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC10"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC9"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC11"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC11"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.3 Names of Include Files </H2>
|
|
<!--docid::SEC10::-->
|
|
<P>
|
|
|
|
There are several schemes for dealing with include files: the
|
|
traditional <CODE>N_SOL</CODE> approach, Sun's <CODE>N_BINCL</CODE> approach, and the
|
|
XCOFF <CODE>C_BINCL</CODE> approach (which despite the similar name has little in
|
|
common with <CODE>N_BINCL</CODE>).
|
|
</P><P>
|
|
|
|
<A NAME="IDX4"></A>
|
|
An <CODE>N_SOL</CODE> symbol specifies which include file subsequent symbols
|
|
refer to. The string field is the name of the file and the value is the
|
|
text address corresponding to the end of the previous include file and
|
|
the start of this one. To specify the main source file again, use an
|
|
<CODE>N_SOL</CODE> symbol with the name of the main source file.
|
|
</P><P>
|
|
|
|
<A NAME="IDX5"></A>
|
|
<A NAME="IDX6"></A>
|
|
<A NAME="IDX7"></A>
|
|
The <CODE>N_BINCL</CODE> approach works as follows. An <CODE>N_BINCL</CODE> symbol
|
|
specifies the start of an include file. In an object file, only the
|
|
string is significant; the linker puts data into some of the other
|
|
fields. The end of the include file is marked by an <CODE>N_EINCL</CODE>
|
|
symbol (which has no string field). In an object file, there is no
|
|
significant data in the <CODE>N_EINCL</CODE> symbol. <CODE>N_BINCL</CODE> and
|
|
<CODE>N_EINCL</CODE> can be nested.
|
|
</P><P>
|
|
|
|
If the linker detects that two source files have identical stabs between
|
|
an <CODE>N_BINCL</CODE> and <CODE>N_EINCL</CODE> pair (as will generally be the case
|
|
for a header file), then it only puts out the stabs once. Each
|
|
additional occurrence is replaced by an <CODE>N_EXCL</CODE> symbol. I believe
|
|
the GNU linker and the Sun (both SunOS4 and Solaris) linker are the only
|
|
ones which supports this feature.
|
|
</P><P>
|
|
|
|
A linker which supports this feature will set the value of a
|
|
<CODE>N_BINCL</CODE> symbol to the total of all the characters in the stabs
|
|
strings included in the header file, omitting any file numbers. The
|
|
value of an <CODE>N_EXCL</CODE> symbol is the same as the value of the
|
|
<CODE>N_BINCL</CODE> symbol it replaces. This information can be used to
|
|
match up <CODE>N_EXCL</CODE> and <CODE>N_BINCL</CODE> symbols which have the same
|
|
filename. The <CODE>N_EINCL</CODE> value, and the values of the other and
|
|
description fields for all three, appear to always be zero.
|
|
</P><P>
|
|
|
|
<A NAME="IDX8"></A>
|
|
<A NAME="IDX9"></A>
|
|
For the start of an include file in XCOFF, use the <TT>`.bi'</TT> assembler
|
|
directive, which generates a <CODE>C_BINCL</CODE> symbol. A <TT>`.ei'</TT>
|
|
directive, which generates a <CODE>C_EINCL</CODE> symbol, denotes the end of
|
|
the include file. Both directives are followed by the name of the
|
|
source file in quotes, which becomes the string for the symbol.
|
|
The value of each symbol, produced automatically by the assembler
|
|
and linker, is the offset into the executable of the beginning
|
|
(inclusive, as you'd expect) or end (inclusive, as you would not expect)
|
|
of the portion of the COFF line table that corresponds to this include
|
|
file. <CODE>C_BINCL</CODE> and <CODE>C_EINCL</CODE> do not nest.
|
|
</P><P>
|
|
|
|
<A NAME="Line Numbers"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC11"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC10"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC12"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC12"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.4 Line Numbers </H2>
|
|
<!--docid::SEC11::-->
|
|
<P>
|
|
|
|
<A NAME="IDX10"></A>
|
|
An <CODE>N_SLINE</CODE> symbol represents the start of a source line. The
|
|
desc field contains the line number and the value contains the code
|
|
address for the start of that source line. On most machines the address
|
|
is absolute; for stabs in sections (see section <A HREF="stabs_13.html#SEC87">F. Using Stabs in Their Own Sections</A>), it is
|
|
relative to the function in which the <CODE>N_SLINE</CODE> symbol occurs.
|
|
</P><P>
|
|
|
|
<A NAME="IDX11"></A>
|
|
<A NAME="IDX12"></A>
|
|
GNU documents <CODE>N_DSLINE</CODE> and <CODE>N_BSLINE</CODE> symbols for line
|
|
numbers in the data or bss segments, respectively. They are identical
|
|
to <CODE>N_SLINE</CODE> but are relocated differently by the linker. They
|
|
were intended to be used to describe the source location of a variable
|
|
declaration, but I believe that GCC2 actually puts the line number in
|
|
the desc field of the stab for the variable itself. GDB has been
|
|
ignoring these symbols (unless they contain a string field) since
|
|
at least GDB 3.5.
|
|
</P><P>
|
|
|
|
For single source lines that generate discontiguous code, such as flow
|
|
of control statements, there may be more than one line number entry for
|
|
the same source line. In this case there is a line number entry at the
|
|
start of each code range, each with the same line number.
|
|
</P><P>
|
|
|
|
XCOFF does not use stabs for line numbers. Instead, it uses COFF line
|
|
numbers (which are outside the scope of this document). Standard COFF
|
|
line numbers cannot deal with include files, but in XCOFF this is fixed
|
|
with the <CODE>C_BINCL</CODE> method of marking include files (see section <A HREF="stabs_2.html#SEC10">2.3 Names of Include Files</A>).
|
|
</P><P>
|
|
|
|
<A NAME="Procedures"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC12"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC11"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC13"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC13"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.5 Procedures </H2>
|
|
<!--docid::SEC12::-->
|
|
<P>
|
|
|
|
<A NAME="IDX13"></A>
|
|
<A NAME="IDX14"></A>
|
|
<A NAME="IDX15"></A>
|
|
<A NAME="IDX16"></A>
|
|
All of the following stabs normally use the <CODE>N_FUN</CODE> symbol type.
|
|
However, Sun's <CODE>acc</CODE> compiler on SunOS4 uses <CODE>N_GSYM</CODE> and
|
|
<CODE>N_STSYM</CODE>, which means that the value of the stab for the function
|
|
is useless and the debugger must get the address of the function from
|
|
the non-stab symbols instead. On systems where non-stab symbols have
|
|
leading underscores, the stabs will lack underscores and the debugger
|
|
needs to know about the leading underscore to match up the stab and the
|
|
non-stab symbol. BSD Fortran is said to use <CODE>N_FNAME</CODE> with the
|
|
same restriction; the value of the symbol is not useful (I'm not sure it
|
|
really does use this, because GDB doesn't handle this and no one has
|
|
complained).
|
|
</P><P>
|
|
|
|
<A NAME="IDX17"></A>
|
|
A function is represented by an <SAMP>`F'</SAMP> symbol descriptor for a global
|
|
(extern) function, and <SAMP>`f'</SAMP> for a static (local) function. For
|
|
a.out, the value of the symbol is the address of the start of the
|
|
function; it is already relocated. For stabs in ELF, the SunPRO
|
|
compiler version 2.0.1 and GCC put out an address which gets relocated
|
|
by the linker. In a future release SunPRO is planning to put out zero,
|
|
in which case the address can be found from the ELF (non-stab) symbol.
|
|
Because looking things up in the ELF symbols would probably be slow, I'm
|
|
not sure how to find which symbol of that name is the right one, and
|
|
this doesn't provide any way to deal with nested functions, it would
|
|
probably be better to make the value of the stab an address relative to
|
|
the start of the file, or just absolute. See <A HREF="stabs_13.html#SEC89">F.2 Having the Linker Relocate Stabs in ELF</A> for more information on linker relocation of stabs in ELF
|
|
files. For XCOFF, the stab uses the <CODE>C_FUN</CODE> storage class and the
|
|
value of the stab is meaningless; the address of the function can be
|
|
found from the csect symbol (XTY_LD/XMC_PR).
|
|
</P><P>
|
|
|
|
The type information of the stab represents the return type of the
|
|
function; thus <SAMP>`foo:f5'</SAMP> means that foo is a function returning type
|
|
5. There is no need to try to get the line number of the start of the
|
|
function from the stab for the function; it is in the next
|
|
<CODE>N_SLINE</CODE> symbol.
|
|
</P><P>
|
|
|
|
Some compilers (such as Sun's Solaris compiler) support an extension for
|
|
specifying the types of the arguments. I suspect this extension is not
|
|
used for old (non-prototyped) function definitions in C. If the
|
|
extension is in use, the type information of the stab for the function
|
|
is followed by type information for each argument, with each argument
|
|
preceded by <SAMP>`;'</SAMP>. An argument type of 0 means that additional
|
|
arguments are being passed, whose types and number may vary (<SAMP>`...'</SAMP>
|
|
in ANSI C). GDB has tolerated this extension (parsed the syntax, if not
|
|
necessarily used the information) since at least version 4.8; I don't
|
|
know whether all versions of dbx tolerate it. The argument types given
|
|
here are not redundant with the symbols for the formal parameters
|
|
(see section <A HREF="stabs_4.html#SEC24">4.7 Parameters</A>); they are the types of the arguments as they are
|
|
passed, before any conversions might take place. For example, if a C
|
|
function which is declared without a prototype takes a <CODE>float</CODE>
|
|
argument, the value is passed as a <CODE>double</CODE> but then converted to a
|
|
<CODE>float</CODE>. Debuggers need to use the types given in the arguments
|
|
when printing values, but when calling the function they need to use the
|
|
types given in the symbol defining the function.
|
|
</P><P>
|
|
|
|
If the return type and types of arguments of a function which is defined
|
|
in another source file are specified (i.e., a function prototype in ANSI
|
|
C), traditionally compilers emit no stab; the only way for the debugger
|
|
to find the information is if the source file where the function is
|
|
defined was also compiled with debugging symbols. As an extension the
|
|
Solaris compiler uses symbol descriptor <SAMP>`P'</SAMP> followed by the return
|
|
type of the function, followed by the arguments, each preceded by
|
|
<SAMP>`;'</SAMP>, as in a stab with symbol descriptor <SAMP>`f'</SAMP> or <SAMP>`F'</SAMP>.
|
|
This use of symbol descriptor <SAMP>`P'</SAMP> can be distinguished from its use
|
|
for register parameters (see section <A HREF="stabs_4.html#SEC25">4.7.1 Passing Parameters in Registers</A>) by the fact that it has
|
|
symbol type <CODE>N_FUN</CODE>.
|
|
</P><P>
|
|
|
|
The AIX documentation also defines symbol descriptor <SAMP>`J'</SAMP> as an
|
|
internal function. I assume this means a function nested within another
|
|
function. It also says symbol descriptor <SAMP>`m'</SAMP> is a module in
|
|
Modula-2 or extended Pascal.
|
|
</P><P>
|
|
|
|
Procedures (functions which do not return values) are represented as
|
|
functions returning the <CODE>void</CODE> type in C. I don't see why this couldn't
|
|
be used for all languages (inventing a <CODE>void</CODE> type for this purpose if
|
|
necessary), but the AIX documentation defines <SAMP>`I'</SAMP>, <SAMP>`P'</SAMP>, and
|
|
<SAMP>`Q'</SAMP> for internal, global, and static procedures, respectively.
|
|
These symbol descriptors are unusual in that they are not followed by
|
|
type information.
|
|
</P><P>
|
|
|
|
The following example shows a stab for a function <CODE>main</CODE> which
|
|
returns type number <CODE>1</CODE>. The <CODE>_main</CODE> specified for the value
|
|
is a reference to an assembler label which is used to fill in the start
|
|
address of the function.
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>.stabs "main:F1",36,0,0,_main # 36 is N_FUN
|
|
</pre></td></tr></table></P><P>
|
|
|
|
The stab representing a procedure is located immediately following the
|
|
code of the procedure. This stab is in turn directly followed by a
|
|
group of other stabs describing elements of the procedure. These other
|
|
stabs describe the procedure's parameters, its block local variables, and
|
|
its block structure.
|
|
</P><P>
|
|
|
|
If functions can appear in different sections, then the debugger may not
|
|
be able to find the end of a function. Recent versions of GCC will mark
|
|
the end of a function with an <CODE>N_FUN</CODE> symbol with an empty string
|
|
for the name. The value is the address of the end of the current
|
|
function. Without such a symbol, there is no indication of the address
|
|
of the end of a function, and you must assume that it ended at the
|
|
starting address of the next function or at the end of the text section
|
|
for the program.
|
|
</P><P>
|
|
|
|
<A NAME="Nested Procedures"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC13"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC12"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC14"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC14"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.6 Nested Procedures </H2>
|
|
<!--docid::SEC13::-->
|
|
<P>
|
|
|
|
For any of the symbol descriptors representing procedures, after the
|
|
symbol descriptor and the type information is optionally a scope
|
|
specifier. This consists of a comma, the name of the procedure, another
|
|
comma, and the name of the enclosing procedure. The first name is local
|
|
to the scope specified, and seems to be redundant with the name of the
|
|
symbol (before the <SAMP>`:'</SAMP>). This feature is used by GCC, and
|
|
presumably Pascal, Modula-2, etc., compilers, for nested functions.
|
|
</P><P>
|
|
|
|
If procedures are nested more than one level deep, only the immediately
|
|
containing scope is specified. For example, this code:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>int
|
|
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></td></tr></table></P><P>
|
|
|
|
produces the stabs:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><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></td></tr></table></P><P>
|
|
|
|
<A NAME="Block Structure"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC14"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC13"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC15"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC15"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.7 Block Structure </H2>
|
|
<!--docid::SEC14::-->
|
|
<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_13.html#SEC87">F. 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><P>
|
|
|
|
<A NAME="Alternate Entry Points"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC15"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC14"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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> 2.8 Alternate Entry Points </H2>
|
|
<!--docid::SEC15::-->
|
|
<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><P>
|
|
|
|
<A NAME="Constants"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_2.html#SEC7"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_3.html#SEC16"> >> </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">
|
|
This document was generated
|
|
by <I>GDB Administrator</I> on <I>March, 13 2002</I>
|
|
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
|
|
"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|