This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]