mingw/info/stabs/Stab-Section-Basics.html

   1 <html lang="en">
   2 <head>
   3 <title>STABS</title>
   4 <meta http-equiv="Content-Type" content="text/html">
   5 <meta name="description" content="STABS">
   6 <meta name="generator" content="makeinfo 4.3">
   7 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
   8 </head>
   9 <body>
  10 <div class="node">
  11 <p>
  12 Node:<a name="Stab%20Section%20Basics">Stab Section Basics</a>,
  13 Next:<a rel="next" accesskey="n" href="ELF-Linker-Relocation.html#ELF%20Linker%20Relocation">ELF Linker Relocation</a>,
  14 Up:<a rel="up" accesskey="u" href="Stab-Sections.html#Stab%20Sections">Stab Sections</a>
  15 <hr><br>
  16 </div>
  17
  18 <h3 class="appendixsec">How to Embed Stabs in Sections</h3>
  19
  20    <p>The assembler creates two custom sections, a section named <code>.stab</code>
  21 which contains an array of fixed length structures, one struct per stab,
  22 and a section named <code>.stabstr</code> containing all the variable length
  23 strings that are referenced by stabs in the <code>.stab</code> section.  The
  24 byte order of the stabs binary data depends on the object file format.
  25 For ELF, it matches the byte order of the ELF file itself, as determined
  26 from the <code>EI_DATA</code> field in the <code>e_ident</code> member of the ELF
  27 header.  For SOM, it is always big-endian (is this true??? FIXME).  For
  28 COFF, it matches the byte order of the COFF headers.  The meaning of the
  29 fields is the same as for a.out (see <a href="Symbol-Table-Format.html#Symbol%20Table%20Format">Symbol Table Format</a>), except
  30 that the <code>n_strx</code> field is relative to the strings for the current
  31 compilation unit (which can be found using the synthetic N_UNDF stab
  32 described below), rather than the entire string table.
  33
  34    <p>The first stab in the <code>.stab</code> section for each compilation unit is
  35 synthetic, generated entirely by the assembler, with no corresponding
  36 <code>.stab</code> directive as input to the assembler.  This stab contains
  37 the following fields:
  38
  39      <dl>
  40 <dt><code>n_strx</code>
  41      <dd>Offset in the <code>.stabstr</code> section to the source filename.
  42
  43      <br><dt><code>n_type</code>
  44      <dd><code>N_UNDF</code>.
  45
  46      <br><dt><code>n_other</code>
  47      <dd>Unused field, always zero.
  48 This may eventually be used to hold overflows from the count in
  49 the <code>n_desc</code> field.
  50
  51      <br><dt><code>n_desc</code>
  52      <dd>Count of upcoming symbols, i.e., the number of remaining stabs for this
  53 source file.
  54
  55      <br><dt><code>n_value</code>
  56      <dd>Size of the string table fragment associated with this source file, in
  57 bytes.
  58 </dl>
  59
  60    <p>The <code>.stabstr</code> section always starts with a null byte (so that string
  61 offsets of zero reference a null string), followed by random length strings,
  62 each of which is null byte terminated.
  63
  64    <p>The ELF section header for the <code>.stab</code> section has its
  65 <code>sh_link</code> member set to the section number of the <code>.stabstr</code>
  66 section, and the <code>.stabstr</code> section has its ELF section
  67 header <code>sh_type</code> member set to <code>SHT_STRTAB</code> to mark it as a
  68 string table.  SOM and COFF have no way of linking the sections together
  69 or marking them as string tables.
  70
  71    <p>For COFF, the <code>.stab</code> and <code>.stabstr</code> sections may be simply
  72 concatenated by the linker.  GDB then uses the <code>n_desc</code> fields to
  73 figure out the extent of the original sections.  Similarly, the
  74 <code>n_value</code> fields of the header symbols are added together in order
  75 to get the actual position of the strings in a desired <code>.stabstr</code>
  76 section.  Although this design obviates any need for the linker to
  77 relocate or otherwise manipulate <code>.stab</code> and <code>.stabstr</code>
  78 sections, it also requires some care to ensure that the offsets are
  79 calculated correctly.  For instance, if the linker were to pad in
  80 between the <code>.stabstr</code> sections before concatenating, then the
  81 offsets to strings in the middle of the executable's <code>.stabstr</code>
  82 section would be wrong.
  83
  84    <p>The GNU linker is able to optimize stabs information by merging
  85 duplicate strings and removing duplicate header file information
  86 (see <a href="Include-Files.html#Include%20Files">Include Files</a>).  When some versions of the GNU linker optimize
  87 stabs in sections, they remove the leading <code>N_UNDF</code> symbol and
  88 arranges for all the <code>n_strx</code> fields to be relative to the start of
  89 the <code>.stabstr</code> section.
  90
  91    </body></html>
  92