From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17309 invoked by alias); 9 Oct 2003 14:26:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17261 invoked from network); 9 Oct 2003 14:26:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 9 Oct 2003 14:26:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7bkT-0000mx-3G for ; Thu, 09 Oct 2003 10:26:37 -0400 Date: Thu, 09 Oct 2003 14:26:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA: DW_AT_frame_base fix for complicated frames Message-ID: <20031009142637.GC29621@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031002165606.GA22819@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00297.txt.bz2 On Thu, Oct 02, 2003 at 12:54:32PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > Does anyone remember a specific reason why this code was there? I don't, > > and I rewrote all of this stuff... I am 99.99% sure it's based on the unwind > > handling for saved registers, where we get either a register number or the > > address of a stack slot. But for frame bases that's not true: > > > > A subroutine or entry point entry may also have a DW_AT_frame_base > > attribute, whose value is a location description that computes the "frame > > base" for the subroutine or entry point. > > > > i.e. it computes the frame base. Not the address of the frame base. This > > memory read tends to find (on x86) the return address, and then we think the > > stack is at . Oopsie. > > > > OK? With this patch and some code Daniel Berlin and Joseph are working on, > > location lists actually work. I can see all the arguments in an > > -fomit-frame-pointer function from the beginning. It's really quite cool. > > I think you're right, there's no reason for that memory fetch to be > there. Please commit. Thanks. I've committed this to trunk and branch. I also moved this to the branch: 2003-10-09 Daniel Jacobowitz Merge from mainline: 2003-07-31 Daniel Jacobowitz * dwarf2read.c (new_symbol): Use var_decode_location for parameters. Location expressions and lists should work reasonably well on both now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer