From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43091 invoked by alias); 1 Jun 2018 11:10:43 -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 43079 invoked by uid 89); 1 Jun 2018 11:10:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=cie, intuitive, debug_* X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,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; Fri, 01 Jun 2018 11:10:41 +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 32CE1300087C; Fri, 1 Jun 2018 13:10:38 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id E41354001058; Fri, 1 Jun 2018 13:10:37 +0200 (CEST) Message-ID: <1527851437.12946.35.camel@klomp.org> Subject: Re: dwarf_begin_elf() won't create handle without .debug_* sections From: Mark Wielaard To: Sasha Da Rocha Pinheiro , "elfutils-devel@sourceware.org" Date: Fri, 01 Jun 2018 11:10:00 -0000 In-Reply-To: References: , <1527179307.2911.23.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-14.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00134.txt.bz2 On Wed, 2018-05-30 at 17:32 +0000, Sasha Da Rocha Pinheiro wrote: > I just fixed something interesting in Dyninst. We were assuming that > the FDEs were following the CIE in the eh_frame section, but this is > not correct. I found them mixed in an ARM binary and this caused > wrong parsing.=C2=A0 > So we I did dwarf_next_cfi() in the loop to go through the FDE's, and > I had to use it again in the loop to get the corresponding CIE. I > don't think it's a problem, just kinda not intuitive, for who wants > to understand after me. dwarf_next_cfi () is a very low level interface. Other cfi related interfaces that work with a Dwarf_CFI handle (dwarf_getcfi () and dwarf_getcfi_elf ()) and don't make any assumptions about the order.=C2=A0 But they do build up a cache of all entries. In return for some extra memory usage you can use them without caring about the order in which they appear with dwarf_cfi_addrframe () by just giving an address you are interested in and using dwarf_frame_info (), dwarf_frame_cfa () and dwarf_frame_register () to extract the information (which might be less/different than what you would get from the "raw" Dwarf_CFI_Entry). Cheers, Mark