Re: [PING][PATCH 2/2] Involve gdbarch in taking DWARF register pieces

[Andreas Arnez <arnez@linux.vnet.ibm.com>]

On Thu, Apr 28 2016, Pedro Alves wrote:

> I couldn't find any reference to "sub-register" in the codebase.
> I'd assume it's something like "eax" being a sub part of "rax"
> on x86-64.  But I'm not certain that's the case here?  On a machine with
> vector registers, is a FP register really a chunk of the vector
> register, or is it a real separate physical register?

It's exactly comparable with eax and rax.  Or consider the SSE registers
xmm0-xmm15, which are embedded in their double-wide AVX counterparts
ymm0-ymm15.  With z/Architecture, each 64-bit FP register is just a
"chunk" ("sub-register" / "part" / "slice" / ...) of a 128-bit vector
register.  The ASCII art in section 2.1 of this article illustrates
this:

  https://sourceware.org/ml/gdb/2016-01/msg00013.html

(BTW, I still didn't get much feedback on that article...)

And if there is a better (or wider used) term than "sub-register", I'll
be happy to change the wording.

> My main confusion revolves I think, around how these points
> are addressed:
>
>  - FP registers and vector registers have the same identical
>    DWARF register number.
>
>  - If the object stored is <= 8 bytes, we should find it in
>    the FP register; otherwise get it from the vector register.
>
> I'd naively think that the fix for something like that would be
> to make dwarf_reg_to_regnum return the gdb FP register number instead 
> of the vector number, when the type fits in a FP register, instead of
> the need for an extra diversion step.  Ignoring the fact that we don't
> currently pass the type/size to gdbarch_dwarf_reg_to_regnum.

Right, ignoring that fact ;-)

Also, IMHO the "actual" placement of an object within a register does
not conceptually depend on where the register number came from.  It
could come from DWARF, from some other debug format, from the user, or
from wherever.  Adjusting the placement only for objects with a DWARF
location seems wrong to me.

--
Andreas