From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20645 invoked by alias); 14 Feb 2003 15:12:31 -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 20631 invoked from network); 14 Feb 2003 15:12:30 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 14 Feb 2003 15:12:30 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18jjP0-0000LZ-00; Fri, 14 Feb 2003 11:13:30 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18jhVr-0008TE-00; Fri, 14 Feb 2003 10:12:27 -0500 Date: Fri, 14 Feb 2003 15:12:00 -0000 From: Daniel Jacobowitz To: "Martin M. Hunt" Cc: gdb@sources.redhat.com Subject: Re: dwarf2_get_pc_bounds problem Message-ID: <20030214151227.GB30416@nevyn.them.org> Mail-Followup-To: "Martin M. Hunt" , gdb@sources.redhat.com References: <1045220381.25349.10.camel@Dragon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045220381.25349.10.camel@Dragon> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00235.txt.bz2 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