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

[Pedro Alves <palves at redhat dot com>]

On 04/28/2016 02:24 PM, Andreas Arnez wrote:
> Ping:
> 
>   https://sourceware.org/ml/gdb-patches/2016-04/msg00437.html
> 
> IIRC, there was some uncertainty about the clarity/meaning of the new
> gdbarch method's description below.  Or has this cleared up by now?

Sorry, I've spent the last hour trying to wrap my head around this,
but I'm still confused.  :-/  I'm sorry to be blocking this.

> 
> On Tue, Apr 19 2016, Andreas Arnez wrote:
> 
>> Here's another attempt:
>>
>> Determine the physical placement of a piece of size LEN within register
>> *REGNUM, possibly overwriting *REGNUM.  (E.g., some ABIs have unwindable
>> sub-registers embedded in non-unwindable full registers, and this method
>> diverts from the full register to the sub-register if possible.)

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?

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.

It may be that the end result is the same, but it's all blurry to
me still.

Thanks,
Pedro Alves