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: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, gdb-patches at sourceware dot org
- Date: Thu, 28 Apr 2016 20:16:00 +0200
- 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> <ee0690e4-1228-7479-61cb-82366f643801 at redhat dot com> <m3d1p9vfqo dot fsf at oc1027705133 dot ibm dot com>
On Thu, Apr 28 2016, Andreas Arnez wrote:
> On Thu, Apr 28 2016, Pedro Alves wrote:
>> 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.
There's another aspect I should probably mention here. The adjustment
of the register number in this gdbarch method is really just a
circumvention around the register cache's inability of representing
*partially* valid registers. Otherwise unwinding would result in the
first 64 bits of such a vector register being "valid" and the others
"invalid", and then we could slice any value types from the valid bits.
In the long run maybe we want to extend the regcache in such a
direction, but I didn't see that in the scope of this fix.