Re: [RFC PATCH] Read pseudo registers from frame instead of regcache

[Simon Marchi <simon dot marchi at polymtl dot ca>]

Hi Ulrich,

Thanks for the feedback.

On 2018-05-28 13:47, Ulrich Weigand wrote:
> Simon Marchi wrote:
>
> > The problem: Reading pseudo registers from an upper stack frame does 
> > not
> > work.  The raw registers needed to compose the pseudo registers are
> > always read from the current thread's regcache, which is effectively
> > frame #0's registers.
>
> I think this may have been by design at some point.  The idea being:
> for the innermost frame, you construct your register set using the 
> ptrace
> (or whatever) interface, possibly using arch-specific constructions
> (the "pseudo" registers).  But for higher frames, you construct *all*
> registers directly via the unwinding logic.

That make sense, I don't think my patch really changes that.  What my 
patch changes is that we can reconstruct pseudo register values from 
unwound raw register values, which we couldn't before.  In the simple 
rbx/ebx case I tried, next_frame will never have info about ebx (trying 
to use it in cfi_offset gives "bad register expression"), so it doesn't 
make sense to query it about the location of ebx.

> For example, on a platform where a floating-point register was extended
> to a vector register at some point, your ptrace interface may be split
> between the original FP part, and the "remaining" piece, so to 
> construct
> the full vector register, you'd have to make two ptrace requests and
> combine them (using a "pseudo" register).  But if you want to find the
> value of the vector register in a higher frame, there will be unwind
> info for the full vector register, and not the two pieces.
>
> (This construct actually exists on Intel as well, e.g. with the ymmh
> register parts.  However, since ymm is not call-saved in the Linux ABI,
> we don't have unwind info either way ... In some other ABI, this could
> be an actual problem, however.)

Ok, I was assuming that it was never possible for the debug info to 
describe how pseudo registers are saved, only raw registers.  Do you 
have an architecture in mind where it's possible to have a pseudo 
register mentioned in the unwind information?  GNU as doesn't accept at 
all "ymm0" or "ymm0h" as an argument to .cfi_offset, so I don't know how 
ymm0 would be represented if we wanted to save it (despite it not being 
callee saved according to the ABI).

If the unwind info can indeed contain explicit information about pseudo 
registers (and therefore implicit info about the raw registers that 
compose it), can't it lead to very difficult situations?  There is 
normally only one way to reconstruct a pseudo register value from raw 
registers.  But a raw register can be part of many pseudo registers.  So 
if we need to unwind a raw register value for which the next frame has 
no explicit information, then we need to check if it has info about all 
the possible pseudo registers this raw register is part of?

> So this change:
>
> > -  /* Ask this frame to unwind its register.  */
> > -  value = frame->unwind->prev_register (frame, 
> > &frame->prologue_cache, regnum);
> > +  struct value *value;
> > +  if (regnum < gdbarch_num_regs (gdbarch))
> > +    {
> > +      /* This is a raw register, we can directly ask the next frame 
> > to unwind
> > +         the register.  */
> > +      value = next_frame->unwind->prev_register (next_frame,
> > +						 &next_frame->prologue_cache,
> > +						 regnum);
> > +    }
> > +  else if (gdbarch_pseudo_register_read_value_p (gdbarch))
> > +    {
> > +      /* This is a pseudo register, we don't know how how what raw 
> > registers
> > +         this pseudo register is made of.  Ask the gdbarch to read 
> > the value,
> > +         it will itself ask the next frame to unwind the values of 
> > the raw
> > +         registers it needs to compose the value of the pseudo 
> > register.  */
> > +      value = gdbarch_pseudo_register_read_value (gdbarch, 
> > next_frame, regnum);
> > +    }
>
> in effect changes what unwind info GDB expects.  Now maybe it is still 
> the
> correct change, but this at least needs a review on how pseudo register
> unwind info is currently handled across all architectures ...

I'll do what I can, but don't expect me to be an expert of all CPU 
architectures anytime soon :).

Simon