From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11820 invoked by alias); 19 Feb 2014 13:44:39 -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 11808 invoked by uid 89); 19 Feb 2014 13:44:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 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; Wed, 19 Feb 2014 13:44:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JDiXWE029643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Feb 2014 08:44:33 -0500 Received: from [10.36.116.65] (ovpn-116-65.ams2.redhat.com [10.36.116.65]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1JDiUkZ026632; Wed, 19 Feb 2014 08:44:32 -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: <20140219072317.GA4270@adacore.com> References: <1392478818-30320-1-git-send-email-brobecker@adacore.com> <20140218133000.GA15835@adacore.com> <1392739369.21975.145.camel@bordewijk.wildebeest.org> <20140218184906.GB15835@adacore.com> <1392760350.21975.200.camel@bordewijk.wildebeest.org> <20140219072317.GA4270@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 19 Feb 2014 13:44:00 -0000 Message-ID: <1392817469.21975.221.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00598.txt.bz2 On Wed, 2014-02-19 at 08:23 +0100, Joel Brobecker wrote: > So, overall, the plan now is to adjust version #2 in the following > ways: > - Add a comment in the function documentation explaining that > this is to help trying to read broken DWARF; > - Add a complaint inside the function when the attribute has > the wrong format > The generalized usage of the new function is maintained. Sounds like a good plan. > > > > Note that this might break for DWARF5. See http://dwarfstd.org/ShowIssue.php?issue=120719.1 > > > > > > Interesting. I am curious why you would handle this attribute as > > > an offset even when the value is encoded in address form? > > > > As Doug said, it is a space saving (offsets are often small) and it > > saves a relocation (linkers have to resolve all DW_FORM_addr values and > > they add up). > > I was wondering why we don't "simply" require a constant format in > this case, instead of allowing both formats. DWARF in general seems to prefer only extensions, not deprecation of old supported ways of doing things. So that DWARFvX is (mostly) valid DWARFvX+1. In the case of DW_AT_high_pc you could in principle support only one way to do it, since it is always used in combination with DW_AT_low_pc as a pair of attributes. So in that case only supporting an offset in constant form is fine. But in the case of DW_AT_entry_pc the offset in constant form variant only makes sense if there is a DW_AT_ranges or DW_AT_low_pc attribute that gives the "base address". But in theory (though very unlikely) DW_AT_entry_pc could occur without either of those other attributes present. So I think also supporting the address form is still required there. Cheers, Mark