From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15505 invoked by alias); 11 Nov 2004 16:49:10 -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 15343 invoked from network); 11 Nov 2004 16:48:50 -0000 Received: from unknown (HELO pippin.tausq.org) (64.81.244.94) by sourceware.org with SMTP; 11 Nov 2004 16:48:50 -0000 Received: by pippin.tausq.org (Postfix, from userid 1000) id 887A9CD2E8; Thu, 11 Nov 2004 08:48:52 -0800 (PST) Date: Thu, 11 Nov 2004 17:12:00 -0000 From: Randolph Chung To: gdb@sources.redhat.com Subject: Re: dwarf2 and frame bases Message-ID: <20041111164852.GS15714@tausq.org> Reply-To: Randolph Chung References: <20041110235149.GO15714@tausq.org> <20041110235649.GA741@nevyn.them.org> <20041111000933.GP15714@tausq.org> <20041111030938.GA4784@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041111030938.GA4784@nevyn.them.org> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00107.txt.bz2 > > but the unwound copy is wrong too... :) i explain more below.. > > Then, that's a bug in the unwinder. after a night's sleep and some more looking through the code, this is making a bit more sense... > > r3 is also a callee-saved register, so its contents are undefined on > > entry to the function. so even if you were to unwind r3, you won't get > > the right frame base. > > That's your mistake. At the first instruction of the prologue, > unwinding r3 for the previous frame should use the copy already in > r3; you need to be falling back to a prologue analyzer and cutting it > off at $pc. I thought you already were? yes, but... so, if you are at the first insn of the prologue, and you unwind r3, you would get the *previous frame*'s frame base. if you used this value to calculate the address of your locals, you will get the value they have in the previous frame. sounds like it should still work (i.e it should still be a valid address), except the hppa targer has an explicit check for when we expect r3 to be modified but we may be in the process of changing it (since it's a 3 insn sequence). In that case, we zero the register to tell the unwinder not to use the value in the r3 to calculate the frame base (it uses the stack pointer and other unwind information in that case) See http://sources.redhat.com/ml/gdb-patches/2004-06/msg00108.html for more details. i know it is kind of hacky, but the frame unwinding code is explicitly asking "what is the frame base of this frame", and the target code is especially tuned for that..... i see two possible solutions: 1) perhaps the hppa target should use some other mechanism (instead of mucking with r3) to tell the next frame that the frame pointer is not available..... 2) in the dwarf code, when trying to get the frame base, should we explicitly ask for the frame base instead of using the dwarf expression? perhaps this could be something that can be overridden by the target, so that the default still uses the dwarf information. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/