Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register

Andreas Arnez <[email protected]>
Newsgroups gmane.comp.gcc.devel,gmane.comp.gdb.devel
Message-ID <[email protected]>
On Thu, Feb 11 2016, Matthew Fortune wrote:

> No I think this is backwards it is the left half that shadows the next
> register and pieces are taken from the right. I've attempted a description
> below to see if it helps.
>
> I don't believe (in the MIPS case) we could unconditionally view the even
> numbered register as 64-bit or 32-bit as the shadowing onto the next
> register only exists in some hardware modes.
>
> The size of a register has to be determined from the current hardware mode
> and then the logic would be to read as much as possible from the referenced
> register and use it as the lower bits of the overall value. Then continue
> reading consecutive registers filling the next most significant bits
> until the full size of the DW_OP_piece has been read. This for MIPS
> FP registers is endian agnostic as the higher numbered register always
> has the most significant bits. For GPRs the even numbered register will
> provide either the most or least significant bits depending on endian but
> we have no reason to use this paradoxical DW_OP_piece for GPRs as they
> have compile time deterministic size.

Hm, so in the shadowed case, assuming that the DWARF consumer has loaded
the register file into a byte array via ptrace, which bytes would the
DW_OP_bit_piece offsets for FPR n correspond to?  Is it like this for
little-endian?

        FPR n            FPR n+1
  +---+---+---+---+ +---+---+---+---+
  |   |   |   |   | |   |   |   |   |
  +---+---+---+---+ +---+---+---+---+
   0   8   16  24    32  40  48  56

(In which case pieces would be taken from the left.)  Or different?  And
for big-endian?

--
Andreas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.