From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56745 invoked by alias); 13 Feb 2018 16:15:51 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 47572 invoked by uid 89); 13 Feb 2018 16:15:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*dodji X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Feb 2018 16:15:34 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 8B25130002C6; Tue, 13 Feb 2018 17:15:27 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 39504404389D; Tue, 13 Feb 2018 17:15:27 +0100 (CET) Message-ID: <1518538527.3058.20.camel@klomp.org> Subject: Re: [PATCH] libdw: Add dwarf_die_addr_die function. From: Mark Wielaard To: elfutils-devel@sourceware.org Cc: Dodji Seketeli Date: Tue, 13 Feb 2018 16:15:00 -0000 In-Reply-To: <1516892815-28359-1-git-send-email-mark@klomp.org> References: <1516892815-28359-1-git-send-email-mark@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00034.txt.bz2 On Thu, 2018-01-25 at 16:06 +0100, Mark Wielaard wrote: > Currently storing a lot of Dwarf_Dies might be inefficient since it > costs a lot of memory since the sizeof (Dwarf_Die) =3D=3D 32 bytes on 64b= it > arches. You can try storing just the Dwarf_Off from dwarf_dieoffset. > Which is just 8 bytes. But then you have to keep track of whether to > call dwarf_dieoffset, if the Dwarf_Die came from the main .debug_info, > or call dwarf_dieoffset_types, if it came from .debug_types. And you'll > have to keep track of whether it came from the main Dwarf or the alt > Dwarf (dwz multi file). With DWARF5 or GNU DebugFission split-dwarf > you will also need to know which split Dwarf file the original DIE > came from. >=20 > A Dwarf_Die consists of an addr pointer where the actual DIE data > comes from, a CU pointer that provides context (and has a pointer > to the Dwarf file the Die is associated with) and a (cached) > Dwarf_Abbrev pointer that is initialized when the Dwarf_Die is > first read and describes how to interpret the DIE data. >=20 > libdw already keeps track of the data pointers (sections) of a > Dwarf file and given an offset it can already reconstruct the > other Dwarf_Die fields. So this patch introduces dwarf_die_addr_die. > Given a Dwarf_Die addr dwarf_die_addr_die returns a (reconstructed) > Dwarf_Die, or NULL if the given addr didn't come from a valid > Dwarf_Die. In particular it will make sure that the correct Dwarf_CU > pointer is set for the Dwarf_Die, the Dwarf_Abbrev pointer will not > be set up yet (it will only be once the Dwarf_Die is used to read > attributes, children or siblings). >=20 > This functions can be used to keep a reference to a Dwarf_Die which > you want to refer to later. The addr, and the result of this function, > is only valid while the associated Dwarf is valid. >=20 > Since libdw already had to lookup the Dwarf_CU given an offset, this > function is as efficient as dwarf_dieoffset (or dwarf_dieoffset_types) > without having to know the original origin of the Dwarf_Die. It will > search both the .debug_info and .debug_types data sections from both > the main Dwarf or the alt Dwarf file. Once split dwarf support is added > it will also look in any split dwarf .dwo (or the .dwp) file. >=20 > The only limitation, compared to using a Dwarf_Off and dwarf_dieoffset, > is that it only works during runtime while the main Dwarf object is > valid (till dwarf_end has been called on it). I pushed this to master now.