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>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, gdb-patches at sourceware dot org
- Date: Thu, 28 Apr 2016 23:15:11 +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> <ee0690e4-1228-7479-61cb-82366f643801 at redhat dot com> <m3d1p9vfqo dot fsf at oc1027705133 dot ibm dot com> <m38tzxvbtr dot fsf at oc1027705133 dot ibm dot com>
On 04/28/2016 07:16 PM, Andreas Arnez wrote:
>> 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.
Ah, when I saw your other email pointing at the ascii art, the thought
of partially valid registers crossed my mind too.
But why do you say we don't support this?
The register cache only cares about registers in the current frame
(IOW, the real current state of a thread's registers). And in the
current frame, the whole vector register is always valid. So I don't
think we need to worry about the register cache.
The unwinding machinery instead works with struct values, and those _do_
support being marked partially optimized out (not saved). You do that by
calling mark_value_bits_optimized_out on the part of the value that
is not saved.
Maybe there's e.g., some value_optimized_out() checks on common code
that might need to be replaced with a more finer-grained "these bytes/bit
here are optimized-out" check, but what else would be necessary?
> 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.