From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80055 invoked by alias); 31 Oct 2019 16:29:54 -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 80045 invoked by uid 89); 31 Oct 2019 16:29:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1539 X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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, 31 Oct 2019 16:29:53 +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 F18EF302AB34; Thu, 31 Oct 2019 17:29:50 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id DFD3042CED16; Thu, 31 Oct 2019 17:29:50 +0100 (CET) Message-ID: Subject: Re: [PATCH 4/5] libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame From: Mark Wielaard To: Omar Sandoval Cc: elfutils-devel@sourceware.org Date: Thu, 31 Oct 2019 16:29:00 -0000 In-Reply-To: <20191030235551.GJ326591@vader> References: <7be679675894550820b63e7c08a5495d06ac49a8.camel@klomp.org> <20191030235551.GJ326591@vader> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00093.txt.bz2 On Wed, 2019-10-30 at 16:55 -0700, Omar Sandoval wrote: > On Wed, Oct 30, 2019 at 02:04:42PM +0100, Mark Wielaard wrote: > > Hi Omar, > >=20 > > On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote: > > > The next change will need to have the Dwarf_Frame readily available, = so > > > rather than finding it again every time, let's cache it for reuse. The > > > CFI frame can also be useful to clients of libdwfl, so add > > > dwfl_frame_dwarf_frame to get it. Similarly, the Dwfl_Module is also > > > frequently needed in conjunction with the frame, so cache it and add > > > dwfl_frame_module. > >=20 > > I can see how this is useful. But it seems the Dwarf_Frame is only > > cached when __libdwfl_frame_unwind is called. Which I believe isn't > > done for the initial frame. Also it isn't clear how to propagate any > > errors when NULL is returned. Maybe dwfl_frame_dwarf_frame () should > > check first to see if frame is NULL and then call lookup the CFI and > > call dwarf_cfi_addrframe if not? >=20 > Yes, that makes sense. Rather than doing the lookups in > __libdwfl_frame_unwind and handle_cfi, I can move the lookups to > dwfl_frame_module and dwfl_frame_dwarf_frame, have those functions cache > it internally, and make __libdwfl_frame_unwind and handle_cfi call those > functions. dwfl_frame_dwarf_frame should also save any errors, so that when it is called again it can set it again when returning NULL. Like what dwfl_module_getdwarf does. Thanks, Mark