Dwarf book club question

Dwarf book club question

[Tim Moore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's a question that I'm not sure is answered in the Dwarf spec:

What is "bias" and why do I care? When do I need to take bias into account?

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGVUOeeDhWHdXrDRURAupBAKCH729JmtaiTs3n6oTf/esTES70DACgnPg5
sDCWPC8vA5P+YCt3DVjivEI=
=tKF6
-----END PGP SIGNATURE-----

Re: Dwarf book club question

[Roland McGrath]

The address bias is not something specified by DWARF or ELF.
It's something necessary in dealing with DWARF (or ELF symbol
tables) in the wider world, rich with DSOs, prelink, and separate
debuginfo, and exciting permutations of the three.  libdwfl deals
with figuring out the bias values you need to know, tells you
them when you might need them, and also has convenience
interfaces for some uses that let you not need to know.

Each Dwfl_Module (meaning the executable and each DSO) has a pair
of bias values.  The DWARF address bias is the difference between
what you think an address is and what libdw thinks an address is,
meaning what address constants are used in DWARF data.  The ELF
address bias is the difference between what you think an address
is and what libelf thinks an address is, meaning what address
constants are used in ELF symbol tables (and section headers).
The two can be the same or different depending on the details of
separate debuginfo splitting and prelinking.  Either can be zero.
Both are always zero for a freshly linked executable file like
those you usually compile yourself, that has not been prelinked
or stripped into a separate debug file.  Neither is ever zero for
a DSO, unless it's been prelinked.

In dwfl_module_info, the DWBIAS argument gets the DWARF address
bias and the SYMBIAS argument gets the ELF symbol address bias.
You should not ordinarily want to fetch and keep them this way.
Note that each of these values is only known after the DWARF data
or the symbol table, respectively, has been loaded in by libdwfl.
Each is done only as needed to satisfy a dwfl_* call that
requires DWARF or symbol information.

dwfl_* calls and Dwfl_* data structures generally deal with absolute
addresses.  dwarf_* calls and Dwarf_* data structures deal with
addresses that need the DWARF bias applied.  elf_* and gelf_* calls
and the data structures they yield deal with addresses that need the
ELF bias applied.

The dwfl_* calls at the transition from Dwfl_* to Dwarf_* or Elf_*
data structures return a bias value.  When you pass an address into a
dwarf_* call, you need to subtract the DWARF bias.  When you get an
address constant out of a dwarf_* call or a Dwarf_* data structure,
you need to add the DWARF bias.  (Don't sue me if the sign is inverted.)

You probably never need to think about the ELF symbol bias.  The
dwfl_module_{getsymtab,getsym,addrsym,addrname} calls are all you
need.  Those give you absolute addresses in the st_value field.

The only thing using Dwfl_Line instead of Dwarf_Line gets you is
that it deals in absolute addresses.  It is libdwfl's front-end
to libdw, glossing over the details of multiple modules and their
address bias details.

For the libdw functions dealing with DIEs, there are no libdwfl
front-end interfaces so far.  It's not worthwhile in a few ways
to have dwfl_* wrappers on absolutely everything just to hide the
address bias.  As we find useful higher-level functions to add,
for some of them it will make sense to put them in libdwfl and
have them deal with absolute addresses.


Thanks,
Roland