From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89369 invoked by alias); 14 Dec 2017 13:51:36 -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 89358 invoked by uid 89); 14 Dec 2017 13:51:35 -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=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=cus, H*Ad:D*io X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no 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; Thu, 14 Dec 2017 13:51:33 +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 9AC7F32B90ED; Thu, 14 Dec 2017 14:51:31 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 899DC413C922; Thu, 14 Dec 2017 14:51:31 +0100 (CET) Message-ID: <1513259491.15696.82.camel@klomp.org> Subject: Re: [PATCH 2/2 v2] Generalize cu_sec_idx From: Mark Wielaard To: Ulf Hermann , elfutils-devel@sourceware.org Date: Thu, 14 Dec 2017 13:51:00 -0000 In-Reply-To: References: 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: 2017-q4/txt/msg00110.txt.bz2 On Fri, 2017-12-08 at 16:06 +0100, Ulf Hermann wrote: > Apparently CUs can appear in other sections than IDX_debug_info and > IDX_types. Rather than relying on the indirect indication provided by > type_offset we compare the addresses directly to figure out which section > a given CU belongs to. This is clever and indeed cu_sec_idx () is not generic enough. But this is also somewhat inefficient. I am working on DWARF5 support and there a CU can come from even more different sections (or file). So I am changing Dwarf_CU to have an explicit section to which is it is associated. This can then also be used by the "fake" CUs like created in dwarf_getmacros. Thanks, Mark