From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12894 invoked by alias); 10 Nov 2005 14:34:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12879 invoked by uid 22791); 10 Nov 2005 14:34:29 -0000 Received: from ip127.bb146.pacific.net.hk (HELO stl.com.hk) (202.64.146.127) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 14:34:29 +0000 Received: from 86.194.17.210.dyn.pacific.net.hk ([210.17.194.86] helo=[192.168.1.10]) by stl.com.hk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EaDSu-0008R7-Kd; Thu, 10 Nov 2005 22:31:48 +0800 Message-ID: <43735A71.5010408@tausq.org> Date: Thu, 10 Nov 2005 23:00:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: Re: Another remark regarding hppa-tdep frame code References: <20051109234000.GA1635@adacore.com> In-Reply-To: <20051109234000.GA1635@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00136.txt.bz2 > I'm currently working off a gdb-6.3 baseline, so I don't have this > code in our tree, but the above seems incorrect. Although it probably > fixes the unwinding issue: > > /* If Save_SP is set, then we expect the frame pointer to be saved in the > frame. However, there is a one-insn window where we haven't saved it > yet, but we've already clobbered it. Detect this case and fix it up. > > The prologue sequence for frame-pointer functions is: > 0: stw %rp, -20(%sp) > 4: copy %r3, %r1 > 8: copy %sp, %r3 > c: stw,ma %r1, XX(%sp) > > So if we are at offset c, the r3 value that we want is not yet saved > on the stack, but it's been overwritten. The prologue analyzer will > set fp_in_r1 when it sees the copy insn so we know to get the value > from r1 instead. */ > > It also breaks: > > (gdb) print $r3 > > in that frame, since you've replaced of r3 by the value of r1. > this may have also broken unwinding if the upper frame uses r3 as > the frame pointer and r3 wasn't saved on stack in that frame. I think I've tested this case, but maybe not. It sounds familiar. > In my opinion, the way to go is to defined FP_REGNUM as a pseudo > register whose value would be invalid (is that possible?) if no > no frame pointer is in use, or its value otherwise. Yes, that might not be a bad idea at all.... > I just assigned myself a winter project to rewrite the unwinder. > I may never find the time to do it, but I have some ideas: > > 1. Merge the two prologue analyzers we have. > One is used to find the prologue-end address, and the other > is used to scan it and help doing unwinding. > > For this part, I think we can use the unwind record to tell > us what we're looking for, and we then scan the prologue until > we've found all the instructions providing just that. This would > still be the fallback method if debugging info is not available. I've looked at this once before but convinced myself that the two prologue analyzers do different things. Nonetheless I agree it's not a good idea to have two, and if you can come up with a clean API to do this, I think it's a good goal. > 2. For the unwinder, if we see the PC being past the function prologue > end, then we can compute the entire frame cache only using the > unwind record. > > Assuming that being inside the function prologue is a rare event, > we should be able to compute frames without doing too much code > scanning. I need to think about this. but iirc we already don't do code reading if pc is after the prologue. > 3. If still inside the prologue, then scan the code and build a fake > unwind record. Then we're back to 2. > > I think we can simplify the unwinder that way. Right now, I find the > mix/merge between using the unwind record and the prologue scan results > confusing... This is an interesting idea. I'd love to see a patch :) randolph