public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Tim Moore <timoore@redhat.com>
Cc: frysk <frysk@sourceware.org>
Subject: Re: Dwarf book club question
Date: Thu, 24 May 2007 16:17:00 -0000	[thread overview]
Message-ID: <20070524092804.B5AA01F8511@magilla.localdomain> (raw)
In-Reply-To: Tim Moore's message of  Thursday, 24 May 2007 09:49:50 +0200 <4655439E.7020609@redhat.com>

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

      reply	other threads:[~2007-05-24  9:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-24  9:28 Tim Moore
2007-05-24 16:17 ` Roland McGrath [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070524092804.B5AA01F8511@magilla.localdomain \
    --to=roland@redhat.com \
    --cc=frysk@sourceware.org \
    --cc=timoore@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).