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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Simon Marchi wrote:
> On 2018-05-28 15:13, Simon Marchi wrote:
> > 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).
> 
> I looked at ARMv7, and one case where this might happen is the VFP 
> registers.  The dX registers (64-bits) are the raw ones and the sX 
> (32-bits) are the pseudo ones (where two sX registers make up one dX 
> register).  The GNU assembler accepts using s0 with .cfi_offset (for 
> backwards compatibility, I guess?), so we end up with it in the unwind 
> info.  However, this is an obsolete way of doing it according to the 
> "DWARF for the ARM Architecture" document [1].  They recommend to 
> describe the sX registers as bit pieces of the dX registers.  That 
> recommendation would be in line with the "only raw registers in unwind 
> info" assumption.  But it means that we can encounter this in the wild.

Another consideration is where GDB itself massages the DWARF info to
use pseudo register numbers; one way to check for that is to look
for instances of gdbarch_dwarf2_reg_to_regnum where the returned
value is a pseudo register number.

At a quick glance, it seems that MEP does that (for pretty much all
registers?), SPU does it for the special SP register, h8300 does it
for a special CCR register, xtensa seems to do it for some registers
(driven by a table) etc.  (I didn't review all archictures.  Also, not
all of those registers are necessarily used for *unwinding*, some DWARF
registers may only be used for DWARF debug info / locations.  But in
at least in the SPU case, I know that SP *is* used for unwinding.).

Now for the internal uses, I guess those could all be fixed by GDB
internal changes to those targets in one way or the other.  But still,
this would need to be done to prevent your patch from breaking
existing platforms ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com