247 lines
13 KiB
HTML
247 lines
13 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: Stab Sections</TITLE>
|
|
|
|
<META NAME="description" CONTENT="STABS: Stab Sections">
|
|
<META NAME="keywords" CONTENT="STABS: Stab Sections">
|
|
<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="SEC87"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_12.html#SEC86"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_13.html#SEC88"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[ >> ]</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> F. Using Stabs in Their Own Sections </H1>
|
|
<!--docid::SEC87::-->
|
|
<P>
|
|
|
|
Many object file formats allow tools to create object files with custom
|
|
sections containing any arbitrary data. For any such object file
|
|
format, stabs can be embedded in special sections. This is how stabs
|
|
are used with ELF and SOM, and aside from ECOFF and XCOFF, is how stabs
|
|
are used with COFF.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_13.html#SEC88">F.1 How to Embed Stabs in Sections</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">How to embed stabs in sections</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="stabs_13.html#SEC89">F.2 Having the Linker Relocate Stabs in ELF</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Sun ELF hacks</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Stab Section Basics"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC88"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_13.html#SEC87"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_13.html#SEC89"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_13.html#SEC87"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[ >> ]</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> F.1 How to Embed Stabs in Sections </H2>
|
|
<!--docid::SEC88::-->
|
|
<P>
|
|
|
|
The assembler creates two custom sections, a section named <CODE>.stab</CODE>
|
|
which contains an array of fixed length structures, one struct per stab,
|
|
and a section named <CODE>.stabstr</CODE> containing all the variable length
|
|
strings that are referenced by stabs in the <CODE>.stab</CODE> section. The
|
|
byte order of the stabs binary data depends on the object file format.
|
|
For ELF, it matches the byte order of the ELF file itself, as determined
|
|
from the <CODE>EI_DATA</CODE> field in the <CODE>e_ident</CODE> member of the ELF
|
|
header. For SOM, it is always big-endian (is this true??? FIXME). For
|
|
COFF, it matches the byte order of the COFF headers. The meaning of the
|
|
fields is the same as for a.out (see section <A HREF="stabs_6.html#SEC47">6.1 Symbol Table Format</A>), except
|
|
that the <CODE>n_strx</CODE> field is relative to the strings for the current
|
|
compilation unit (which can be found using the synthetic N_UNDF stab
|
|
described below), rather than the entire string table.
|
|
</P><P>
|
|
|
|
The first stab in the <CODE>.stab</CODE> section for each compilation unit is
|
|
synthetic, generated entirely by the assembler, with no corresponding
|
|
<CODE>.stab</CODE> directive as input to the assembler. This stab contains
|
|
the following fields:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>n_strx</CODE>
|
|
<DD>Offset in the <CODE>.stabstr</CODE> section to the source filename.
|
|
<P>
|
|
|
|
<DT><CODE>n_type</CODE>
|
|
<DD><CODE>N_UNDF</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>n_other</CODE>
|
|
<DD>Unused field, always zero.
|
|
This may eventually be used to hold overflows from the count in
|
|
the <CODE>n_desc</CODE> field.
|
|
<P>
|
|
|
|
<DT><CODE>n_desc</CODE>
|
|
<DD>Count of upcoming symbols, i.e., the number of remaining stabs for this
|
|
source file.
|
|
<P>
|
|
|
|
<DT><CODE>n_value</CODE>
|
|
<DD>Size of the string table fragment associated with this source file, in
|
|
bytes.
|
|
</DL>
|
|
<P>
|
|
|
|
The <CODE>.stabstr</CODE> section always starts with a null byte (so that string
|
|
offsets of zero reference a null string), followed by random length strings,
|
|
each of which is null byte terminated.
|
|
</P><P>
|
|
|
|
The ELF section header for the <CODE>.stab</CODE> section has its
|
|
<CODE>sh_link</CODE> member set to the section number of the <CODE>.stabstr</CODE>
|
|
section, and the <CODE>.stabstr</CODE> section has its ELF section
|
|
header <CODE>sh_type</CODE> member set to <CODE>SHT_STRTAB</CODE> to mark it as a
|
|
string table. SOM and COFF have no way of linking the sections together
|
|
or marking them as string tables.
|
|
</P><P>
|
|
|
|
For COFF, the <CODE>.stab</CODE> and <CODE>.stabstr</CODE> sections may be simply
|
|
concatenated by the linker. GDB then uses the <CODE>n_desc</CODE> fields to
|
|
figure out the extent of the original sections. Similarly, the
|
|
<CODE>n_value</CODE> fields of the header symbols are added together in order
|
|
to get the actual position of the strings in a desired <CODE>.stabstr</CODE>
|
|
section. Although this design obviates any need for the linker to
|
|
relocate or otherwise manipulate <CODE>.stab</CODE> and <CODE>.stabstr</CODE>
|
|
sections, it also requires some care to ensure that the offsets are
|
|
calculated correctly. For instance, if the linker were to pad in
|
|
between the <CODE>.stabstr</CODE> sections before concatenating, then the
|
|
offsets to strings in the middle of the executable's <CODE>.stabstr</CODE>
|
|
section would be wrong.
|
|
</P><P>
|
|
|
|
The GNU linker is able to optimize stabs information by merging
|
|
duplicate strings and removing duplicate header file information
|
|
(see section <A HREF="stabs_2.html#SEC10">2.3 Names of Include Files</A>). When some versions of the GNU linker optimize
|
|
stabs in sections, they remove the leading <CODE>N_UNDF</CODE> symbol and
|
|
arranges for all the <CODE>n_strx</CODE> fields to be relative to the start of
|
|
the <CODE>.stabstr</CODE> section.
|
|
</P><P>
|
|
|
|
<A NAME="ELF Linker Relocation"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC89"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_13.html#SEC88"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_14.html#SEC90"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="stabs_13.html#SEC87"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[ >> ]</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> F.2 Having the Linker Relocate Stabs in ELF </H2>
|
|
<!--docid::SEC89::-->
|
|
<P>
|
|
|
|
This section describes some Sun hacks for Stabs in ELF; it does not
|
|
apply to COFF or SOM.
|
|
</P><P>
|
|
|
|
To keep linking fast, you don't want the linker to have to relocate very
|
|
many stabs. Making sure this is done for <CODE>N_SLINE</CODE>,
|
|
<CODE>N_RBRAC</CODE>, and <CODE>N_LBRAC</CODE> stabs is the most important thing
|
|
(see the descriptions of those stabs for more information). But Sun's
|
|
stabs in ELF has taken this further, to make all addresses in the
|
|
<CODE>n_value</CODE> field (functions and static variables) relative to the
|
|
source file. For the <CODE>N_SO</CODE> symbol itself, Sun simply omits the
|
|
address. To find the address of each section corresponding to a given
|
|
source file, the compiler puts out symbols giving the address of each
|
|
section for a given source file. Since these are ELF (not stab)
|
|
symbols, the linker relocates them correctly without having to touch the
|
|
stabs section. They are named <CODE>Bbss.bss</CODE> for the bss section,
|
|
<CODE>Ddata.data</CODE> for the data section, and <CODE>Drodata.rodata</CODE> for
|
|
the rodata section. For the text section, there is no such symbol (but
|
|
there should be, see below). For an example of how these symbols work,
|
|
See section <A HREF="stabs_6.html#SEC51">6.2.3 Transformations of Stabs in separate sections</A>. GCC does not provide these symbols;
|
|
it instead relies on the stabs getting relocated. Thus addresses which
|
|
would normally be relative to <CODE>Bbss.bss</CODE>, etc., are already
|
|
relocated. The Sun linker provided with Solaris 2.2 and earlier
|
|
relocates stabs using normal ELF relocation information, as it would do
|
|
for any section. Sun has been threatening to kludge their linker to not
|
|
do this (to speed up linking), even though the correct way to avoid
|
|
having the linker do these relocations is to have the compiler no longer
|
|
output relocatable values. Last I heard they had been talked out of the
|
|
linker kludge. See Sun point patch 101052-01 and Sun bug 1142109. With
|
|
the Sun compiler this affects <SAMP>`S'</SAMP> symbol descriptor stabs
|
|
(see section <A HREF="stabs_4.html#SEC22">4.5 Static Variables</A>) and functions (see section <A HREF="stabs_2.html#SEC12">2.5 Procedures</A>). In the latter
|
|
case, to adopt the clean solution (making the value of the stab relative
|
|
to the start of the compilation unit), it would be necessary to invent a
|
|
<CODE>Ttext.text</CODE> symbol, analogous to the <CODE>Bbss.bss</CODE>, etc.,
|
|
symbols. I recommend this rather than using a zero value and getting
|
|
the address from the ELF symbols.
|
|
</P><P>
|
|
|
|
Finding the correct <CODE>Bbss.bss</CODE>, etc., symbol is difficult, because
|
|
the linker simply concatenates the <CODE>.stab</CODE> sections from each
|
|
<TT>`.o'</TT> file without including any information about which part of a
|
|
<CODE>.stab</CODE> section comes from which <TT>`.o'</TT> file. The way GDB does
|
|
this is to look for an ELF <CODE>STT_FILE</CODE> symbol which has the same
|
|
name as the last component of the file name from the <CODE>N_SO</CODE> symbol
|
|
in the stabs (for example, if the file name is <TT>`../../gdb/main.c'</TT>,
|
|
it looks for an ELF <CODE>STT_FILE</CODE> symbol named <CODE>main.c</CODE>). This
|
|
loses if different files have the same name (they could be in different
|
|
directories, a library could have been copied from one system to
|
|
another, etc.). It would be much cleaner to have the <CODE>Bbss.bss</CODE>
|
|
symbols in the stabs themselves. Having the linker relocate them there
|
|
is no more work than having the linker relocate ELF symbols, and it
|
|
solves the problem of having to associate the ELF and stab symbols.
|
|
However, no one has yet designed or implemented such a scheme.
|
|
</P><P>
|
|
|
|
<A NAME="Symbol Types Index"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[ >> ]</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>
|