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

[Randolph Chung <randolph@tausq.org>]

> After your feedback, I'm starting to think that this whole unwind
> record thing is a wasp nest. This is loud thinking at this stage,
> but let me suggest something heretical: How about to stop using
> the unwind record to do the unwinding? We scan the prologue as we've
> always done, and collect all the information, including the fact that
> the function has a frame pointer or not. Then we don't need use
> the unwind record, except maybe to determine the function start
> address. I think we might even be able to dump the FP_REGNUM
> entirely.

How do you find the end of the prologue without consulting the unwind
data? Right now one heuristic is "scan the code until you hit a branch",
which works but might mean you scan way too much code. I'm also not
certain if this will work correctly for things like alloca, but it might.

For that matter, how do you find the beginning of the function without
unwind data? Right now the hppa backend can determine this even in the
absence of other debug (stabs, dwarf) info, although it might end up
printing the wrong function name in a backtrace.

> The good thing is that I don't think we'll need that many changes
> to the code to get to that point. Improve a bit the code scanner
> to retrieve the information that we normally dig out of the unwind
> record, and we should have something at least marginally working.
> The other advantage is that now the debugger doesn't need to know
> what compiler produced the object. So I'll be able to share the changes
> we make internally too. What do you think?

Making gdb more compiler independent is of course a good thing, but I
don't know that we want to get rid of the unwind record altogether.
OTOH, if you can combine all the prologue analysis code in hppa-tdep.c
and make it more robust, I think it will certainly be a good thing.

randolph