From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17934 invoked by alias); 14 Feb 2003 19:01:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17927 invoked from network); 14 Feb 2003 19:01:19 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 14 Feb 2003 19:01:19 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1EJ1If30719 for ; Fri, 14 Feb 2003 14:01:18 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1EJ1Ia09995; Fri, 14 Feb 2003 14:01:18 -0500 Received: from dragon (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1EJ1HZ09738; Fri, 14 Feb 2003 14:01:17 -0500 Subject: Re: dwarf2_get_pc_bounds problem From: "Martin M. Hunt" To: Daniel Jacobowitz Cc: gdb@sources.redhat.com In-Reply-To: <20030214151227.GB30416@nevyn.them.org> References: <1045220381.25349.10.camel@Dragon> <20030214151227.GB30416@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 14 Feb 2003 19:01:00 -0000 Message-Id: <1045249278.1115.12.camel@Dragon> Mime-Version: 1.0 X-SW-Source: 2003-02/txt/msg00242.txt.bz2 Your patch fixes the problems I was seeing. Martin On Fri, 2003-02-14 at 07:12, Daniel Jacobowitz wrote: > On Fri, Feb 14, 2003 at 02:59:40AM -0800, Martin M. Hunt wrote: > > I'm investigating several errors in recent versions of gdb and they all > > seem to be caused by bogus values for lowpc and highpc returned from > > dwarf2_get_pc_bounds(). I'm not a DWARF expert so maybe the problem is > > bad debug info, but the code in dwarf2_get_pc_bounds seems suspicious. > > > > What I'm seeing is that with a program linked at 0x80000000, all the > > highpc and lowpc look fine, except those derived from DW_AT_ranges > > information. Those are all very small, like 0x100. Looking at the code > > in dwarf2_get_pc_bounds(), most of it seems to be trying to calculate a > > variable "base" which is then never used. Perhaps a simple addition was > > left out? > > Ah, er, um, er.... I tested this, how the heck did it work? Aha, my > test case involved multiple sections, so GCC used a base of 0. That's > how. > > Could you try this obvious fix? Still doesn't fix Jakub's test (we > really do need discontiguous ranges for that to work) but r_type > searches one local block instead of going straight to the function. > > Oddly, I remember this happening before. I may have lost the addition > in a merge somewhere. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > > 2003-02-14 Daniel Jacobowitz > > * dwarf2read.c (dwarf2_get_pc_bounds): Offset addresses by base. > > Index: dwarf2read.c > =================================================================== > RCS file: /cvs/src/src/gdb/dwarf2read.c,v > retrieving revision 1.85 > diff -u -p -r1.85 dwarf2read.c > --- dwarf2read.c 4 Feb 2003 20:17:02 -0000 1.85 > +++ dwarf2read.c 14 Feb 2003 15:10:24 -0000 > @@ -2195,6 +2195,9 @@ dwarf2_get_pc_bounds (struct die_info *d > return 0; > } > > + range_beginning += base; > + range_end += base; > + > /* FIXME: This is recording everything as a low-high > segment of consecutive addresses. We should have a > data structure for discontiguous block ranges