From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24324 invoked by alias); 16 Feb 2014 19:19:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24315 invoked by uid 89); 16 Feb 2014 19:19:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Feb 2014 19:19:08 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1GJJ31c020207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Feb 2014 14:19:04 -0500 Received: from [10.36.116.65] (ovpn-116-65.ams2.redhat.com [10.36.116.65]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1GJJ2mH000913; Sun, 16 Feb 2014 14:19:03 -0500 Subject: Re: [RFA/DWARF] constant class of DW_AT_high_pc is offset for version >=4 only. From: Mark Wielaard To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <1392478818-30320-1-git-send-email-brobecker@adacore.com> References: <1392478818-30320-1-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 16 Feb 2014 19:19:00 -0000 Message-ID: <1392578342.21975.12.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00515.txt.bz2 Hi Joel, On Sat, 2014-02-15 at 19:40 +0400, Joel Brobecker wrote: > Starting with DWARF version 4, the description of the DW_AT_high_pc > attribute was amended to say: > > if it is of class constant, the value is an unsigned integer offset > which when added to the low PC gives the address of the first > location past the last instruction associated with the entity. > > A change was made in Apr 27th, 2012 to reflect that change: > > | commit 91da14142c0171e58a91ad58a32fd010b700e761 > | Author: Mark Wielaard > | Date: Fri Apr 27 18:55:19 2012 +0000 > | > | * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to > | see whether it is an address or a constant offset from DW_AT_low_pc. > | (dwarf2_record_block_ranges): Likewise. > | (read_partial_die): Likewise. > > Unfortunately, this new interpretation is now used regardless of > the CU's DWARF version. It turns out that one of WindRiver's compilers > (FTR: Diabdata 4.4) is generating DWARF version 2 info with > DW_AT_high_pc attributes using the data4 form. Because of that, > we miscompute all high PCs incorrectly. Sorry about that. I read the spec as disallowing anything except DW_FORM_addr to encode class address. And since before DWARF4 DW_AT_high_pc only allowed class address it hadn't occurred to me that it could have been encoded differently. I do think this really is a bug in the compiler that generated this. > This patch fixes it by ammending a bit the changes from the commit > mentioned above to use the new interpretation of a relative address > only when the CU's DWARF version is 4 or greater. That should work fine. GCC at least doesn't generate DW_AT_high_pc attributes as offsets (constant class) unless it generates DWARF4+. Cheers, Mark