From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31432 invoked by alias); 12 Nov 2005 04:59:21 -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 31422 invoked by uid 22791); 12 Nov 2005 04:59:19 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.197) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 12 Nov 2005 04:59:19 +0000 Received: by zproxy.gmail.com with SMTP id l1so856171nzf for ; Fri, 11 Nov 2005 20:59:17 -0800 (PST) Received: by 10.36.178.7 with SMTP id a7mr2004038nzf; Fri, 11 Nov 2005 20:59:17 -0800 (PST) Received: by 10.37.2.35 with HTTP; Fri, 11 Nov 2005 20:59:17 -0800 (PST) Message-ID: <8f2776cb0511112059u4c54acf1j13936c04fed3dbe6@mail.gmail.com> Date: Sat, 12 Nov 2005 17:08:00 -0000 From: Jim Blandy To: Randolph Chung Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning Cc: Joel Brobecker , gdb-patches@sources.redhat.com In-Reply-To: <437571F4.8020508@tausq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051109203108.GX1635@adacore.com> <43735815.3070805@tausq.org> <20051111001017.GJ1635@adacore.com> <437548AF.5090107@tausq.org> <8f2776cb0511111838m64d478d9s2e04db338fbf7fc8@mail.gmail.com> <4375624D.1070202@tausq.org> <8f2776cb0511112022k746e7909r24be2e964dd45a13@mail.gmail.com> <437571F4.8020508@tausq.org> X-SW-Source: 2005-11/txt/msg00158.txt.bz2 On 11/11/05, Randolph Chung wrote: > > Hmm. Is it possible to find a function's entry point from a PC within > > that function's code given only the unwind records? If the detailed > > There is one unwind record for each function. The unwind record contains > the start and end address of the function. So yes, given a pc, we can > find the unwind record and recover the starting address of the function. Okay, that's interesting. > Well.... > If we have an unwind record (and we should for any ABI-conforming > function), and the pc is after the prologue, then theoretically we don't > need to do prologue analysis. > > Now, there is a trick to this -- how do we know we are after the > prologue? Currently, we look at the unwind record which tells us what > information is stored in the frame, and we do code analysis to determine > the pc where all the information that the unwind record says should be > in the frame has been stored in the frame. I think it's best to just not think in terms of "before the prologue" / "after the prologue" / "end of the prologue". Your instructions are going to get mixed together by scheduling anyway. What you can count on instead is that, at any given point in the function, whether at its entry point, in the midst of the prologue, or deep into the guts of the function, there is some way to do the unwinding. Otherwise, the function itself couldn't return. (Backtracing out of "never-return" functions presents special difficulties exactly because this isn't true there.) That's why I say prologue analysis should run from the entry point up to the current PC, or until it reaches an unrecognized instruction.=20 In the first case, it's obviously correct to stop. In the second case, since prologue analysis is inevitably a conservative approximation to actually running the code live, the only technically correct thing to do with an unrecognized instruction is throw away all the information you've gathered --- after all, that instruction could potentially invalidate all of it. But in most cases, whatever you've accumulated up to that point is a decent approximation of the right thing, so it's better to just stop than to throw everything away. > I'm all for cleaning up the code; I just think we need to be careful > because of all the "twists" in the hppa ABI... especially on HPUX :( > Just take a look at hppa_hpux_push_dummy_code sometime. I don't know what state the test results from HPPA are in (please don't read any criticism in that), but I don't think we would need to tolerate any regressions from the change. What's a real threat to progress is if there are so many variations we care about that it becomes difficult to test.