Re: [RFC] Using values to handle unwinding

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> It returns a GDB value object describing the register value.  It may
> be a lazy reference to memory, a lazy reference to the value of a
> register in THIS frame, or a non-lvalue (constant or address).  The
> first part of the patch adds support for lazy registers, which are not
> fetched until they are needed.  When any frame other than the sentinel
> frame sees that a register in the PREV frame is not saved or constant,
> it returns a lazy reference to the register in THIS frame.

I think this is an excellent idea.  I'm wondering how this plays with
special conversions needed for certain registers, see e.g. the
discussion we had last December that led to introduction of the
value_from_register gdbarch callback.

For example, while we do have ways of performing special conversions
on the registers themselves, there is no straightforward way to do so
for unwound register contents.  Maybe if we're going to using values
to represent those, we could allow the architecture to perform type-
specific conversions on those (this should e.g. allow me to eliminate
a specical pseudo on the SPU that I'm using to hold the properly
converted unwound stack pointer register contents).

> There are three key differences / motivations:
> 
>   - Uses GDB's value infrastructure.  Values carry around the
>     location information which previously took four extra arguments
>     to every unwinder.  And this lets us use our existing value
>     manipulation routines as necessary.
> 
>   - Uses the same frame that non-unwinder architecture methods use.
>     For instance, in my ARM CPSR unwinding patch I had a routine
>     "arm_frame_is_thumb".  It was used during software single
>     stepping, where we wanted the state of the current frame, and
>     during unwinding, where we wanted the state of THIS frame
>     (i.e. the one being unwound / having its ID established).
> 
>   - Simplifies getting other registers from the PREV frame.
>     For instance, if one register is computed based on the
>     value of another.  Previously you had to inline code
>     to do this or call the same prev_register routine again
>     with the same NEXT frame and THIS cache; awkward if more
>     than one function was involved (see previous reason).

I must admit I also no longer understand the original reason for
using the NEXT_FRAME here.  If THIS_FRAME works, it would certainly
appear to be much more straightforward ...

B.t.w. there's another change in the patch: the elimination of the
prev_pc unwinder method.  Could you explain the reason why this is
now no longer necessary?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com