From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9396 invoked by alias); 11 Nov 2004 17:12:56 -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 9137 invoked from network); 11 Nov 2004 17:12:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Nov 2004 17:12:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CSIUq-0002nW-7f; Thu, 11 Nov 2004 12:12:32 -0500 Date: Thu, 11 Nov 2004 19:42:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb@sources.redhat.com Subject: Re: dwarf2 and frame bases Message-ID: <20041111171232.GA10326@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb@sources.redhat.com References: <20041110235149.GO15714@tausq.org> <20041110235649.GA741@nevyn.them.org> <20041111000933.GP15714@tausq.org> <20041111030938.GA4784@nevyn.them.org> <20041111164852.GS15714@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041111164852.GS15714@tausq.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00108.txt.bz2 On Thu, Nov 11, 2004 at 08:48:52AM -0800, Randolph Chung wrote: > 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. Correct. A watchpoint on "b" is associate with a particular frame, because it's a local. You want the previous frame's copy. You get the previous frame's copy. Everyone wins. > 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. This sounds totally messed up. Suppose we're in frame A, called from frame B. We're at the first instruction. If we ask the sentinel frame to unwind the value of r3, we'll get its real register value - regardless of where we are in the sequence. If we ask frame A to unwind r3, we want to get frame B's r3. Where frame A is in its prologue has no effect on what frame B's r3 was at the time of calling A. There's no more details in that message, just a patch :-) I can't trace exactly what it's doing. > 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..... The next frame's frame pointer _is_ available. This is what I don't understand. You were asked, "unwind r3 for frame B" and instead you're zeroing it based on where frame A is? > 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. No. The "frame base" as a GDB concept is completely separate from DW_AT_frame_base used for local variables; let's not confuse them further. -- Daniel Jacobowitz