stabs_13.html   [plain text]


<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.51
     from /mnt/apple/gdb/source/gdb.apple/source/gdb/gdb/doc/stabs.texinfo on 23 November 1999 -->

<TITLE>STABS - Using Stabs in Their Own Sections</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="stabs_1.html">first</A>, <A HREF="stabs_12.html">previous</A>, <A HREF="stabs_14.html">next</A>, <A HREF="stabs_14.html">last</A> section, <A HREF="stabs_toc.html">table of contents</A>.
<P><HR><P>


<H1><A NAME="SEC87" HREF="stabs_toc.html#TOC87">Using Stabs in Their Own Sections</A></H1>

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



<H2><A NAME="SEC88" HREF="stabs_toc.html#TOC88">How to Embed Stabs in Sections</A></H2>

<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">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>
<DL COMPACT>

<DT><CODE>n_strx</CODE>
<DD>
Offset in the <CODE>.stabstr</CODE> section to the source filename.

<DT><CODE>n_type</CODE>
<DD>
<CODE>N_UNDF</CODE>.

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

<DT><CODE>n_desc</CODE>
<DD>
Count of upcoming symbols, i.e., the number of remaining stabs for this
source file.

<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">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>


<H2><A NAME="SEC89" HREF="stabs_toc.html#TOC89">Having the Linker Relocate Stabs in ELF</A></H2>

<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">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">Static Variables</A>) and functions (see section <A HREF="stabs_2.html#SEC12">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><HR><P>
Go to the <A HREF="stabs_1.html">first</A>, <A HREF="stabs_12.html">previous</A>, <A HREF="stabs_14.html">next</A>, <A HREF="stabs_14.html">last</A> section, <A HREF="stabs_toc.html">table of contents</A>.
</BODY>
</HTML>