From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26628 invoked by alias); 17 Mar 2017 00:29:14 -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 26615 invoked by uid 89); 17 Mar 2017 00:29:14 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS 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: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 013C3C057FA9 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jistone@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 013C3C057FA9 Subject: Re: Compilation Unit name To: SASHA NICOLAS DA ROCHA PINHEIRO , "elfutils-devel@sourceware.org" References: <705c6c77-fd79-004a-c744-7b534f38e4ed@redhat.com> From: Josh Stone Message-ID: Date: Fri, 17 Mar 2017 00:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 17 Mar 2017 00:29:14 +0000 (UTC) X-SW-Source: 2017-q1/txt/msg00096.txt.bz2 Stick to plain text, not HTML, if you want to reach the list. On 03/16/2017 03:44 PM, SASHA NICOLAS DA ROCHA PINHEIRO wrote: > I had that before, and it didn't work, then I empirically changed to > next_cu_off because it contained the same offset I was supposed to get > when I compared to the libdwarf execution. What you have called cu_die_off is *not* a die offset! In libdwarf.h that argument is called next_cu_header_offset, which is why it has the same value as the next_cu_off you're getting from libdw. > We already discarded the option of using dwarf_offdie_types since > previously, with libdwarf, it was passed true to: That's fine and correct. You shouldn't use dwarf_offdie_types now, I was trying to preempt a future problem. Sorry for adding confusion.