[PING][PATCH 2/2] Involve gdbarch in taking DWARF register pieces
Pedro Alves
palves@redhat.com
Thu Apr 28 14:47:00 GMT 2016
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
More information about the Gdb-patches
mailing list