(stabs.info)Stabs In ELF


Next: Symbol Types Index Prev: Sun Differences Up: Top

Using Stabs With The ELF Object File Format
*******************************************

   The ELF object file format allows tools to create object files with
custom sections containing any arbitrary data.  To use stabs in ELF
object files, the tools create two custom sections, a section named
`.stab' which contains an array of fixed length structures, one struct
per stab, and a section named `.stabstr' containing all the variable
length strings that are referenced by stabs in the `.stab' section.
The byte order of the stabs binary data matches the byte order of the
ELF file itself, as determined from the `EI_DATA' field in the
`e_ident' member of the ELF header.

   The first stab in the `.stab' section for each compilation unit is
synthetic, generated entirely by the assembler, with no corresponding
`.stab' directive as input to the assembler.  This stab contains the
following fields:

`n_strx'
     Offset in the `.stabstr' section to the source filename.

`n_type'
     `N_UNDF'.

`n_other'
     Unused field, always zero.

`n_desc'
     Count of upcoming symbols, i.e., the number of remaining stabs for
     this source file.

`n_value'
     Size of the string table fragment associated with this source
     file, in bytes.

   The `.stabstr' 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.

   The ELF section header for the `.stab' section has its `sh_link'
member set to the section number of the `.stabstr' section, and the
`.stabstr' section has its ELF section header `sh_type' member set to
`SHT_STRTAB' to mark it as a string table.

   To keep linking fast, you don't want the linker to have to relocate
very many stabs.  Thus Sun has invented a scheme in which addresses in
the `n_value' field are relative to the source file (or some entity
smaller than a source file, like a function).  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
`Bbss.bss' for the bss section, `Ddata.data' for the data section, and
`Drodata.rodata' 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, Note: ELF and SOM Transformations.  GCC does
not provide these symbols; it instead relies on the stabs getting
relocated.  Thus addresses which would normally be relative to
`Bbss.bss', 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 `S'
symbol descriptor stabs (Note: Statics.) and functions (*note
Procedures::.).  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 `Ttext.text' symbol, analogous
to the `Bbss.bss', etc., symbols.  I recommend this rather than using a
zero value and getting the address from the ELF symbols.

   Finding the correct `Bbss.bss', etc., symbol is difficult, because
the linker simply concatenates the `.stab' sections from each `.o' file
without including any information about which part of a `.stab' section
comes from which `.o' file.  The way GDB does this is to look for an
ELF `STT_FILE' symbol which has the same name as the last component of
the file name from the `N_SO' symbol in the stabs (for example, if the
file name is `../../gdb/main.c', it looks for an ELF `STT_FILE' symbol
named `main.c').  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 `Bbss.bss' 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.


automatically generated by info2www