add directory study
This commit is contained in:
gohigh
246
study/Ref-docs/manual gdb/stabs/stabs_13.html
Normal file
246
study/Ref-docs/manual gdb/stabs/stabs_13.html
Normal file
@@ -0,0 +1,246 @@
|
||||
<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>
|
||||
Reference in New Issue
Block a user