Re: [hppa] FYI: confusion in unwind descriptor field meaning

[Jim Blandy <jimb at red-bean dot com>]

On 11/11/05, Randolph Chung <randolph@tausq.org> 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. 
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. <sigh>

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.