From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18124 invoked by alias); 24 May 2007 09:28:13 -0000 Received: (qmail 18117 invoked by uid 22791); 24 May 2007 09:28:11 -0000 X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_FAIL,TW_DW X-Spam-Check-By: sourceware.org Received: from sccrmhc14.comcast.net (HELO sccrmhc14.comcast.net) (204.127.200.84) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 May 2007 09:28:10 +0000 Received: from gateway.sf.frob.com (c-69-181-208-57.hsd1.ca.comcast.net[69.181.208.57]) by comcast.net (sccrmhc14) with ESMTP id <2007052409280601400d6b6ne>; Thu, 24 May 2007 09:28:08 +0000 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id E502D357B; Thu, 24 May 2007 02:28:04 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id B5AA01F8511; Thu, 24 May 2007 02:28:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Tim Moore Cc: frysk Subject: Re: Dwarf book club question In-Reply-To: Tim Moore's message of Thursday, 24 May 2007 09:49:50 +0200 <4655439E.7020609@redhat.com> X-Shopping-List: (1) Cadaverous riot miscreants (2) Beatific suspicions (3) Economical nutrition (4) Harmonic rendezvous devotions (5) Imprudent riot skis Message-Id: <20070524092804.B5AA01F8511@magilla.localdomain> Date: Thu, 24 May 2007 16:17:00 -0000 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00200.txt.bz2 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