This is the mail archive of the
mailing list for the GDB project.
Re: [PING][PATCH 2/2] Involve gdbarch in taking DWARF register pieces
- From: Pedro Alves <palves at redhat dot com>
- To: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 28 Apr 2016 15:47:14 +0100
- Subject: Re: [PING][PATCH 2/2] Involve gdbarch in taking DWARF register pieces
- Authentication-results: sourceware.org; auth=none
- References: <20160415180943 dot 4FEE857EE at oc7340732750 dot ibm dot com> <571134CD dot 8080507 at redhat dot com> <m3shyjw2t3 dot fsf at oc1027705133 dot ibm dot com> <5714E6EA dot 8050905 at redhat dot com> <m3lh4bvu2z dot fsf at oc1027705133 dot ibm dot com> <57150356 dot 3090508 at redhat dot com> <m3a8kpx0ls dot fsf at oc1027705133 dot ibm dot com> <m3h9elvpc7 dot fsf_-_ at oc1027705133 dot ibm dot com>
On 04/28/2016 02:24 PM, Andreas Arnez wrote:
> 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
- 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