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

[Pedro Alves <palves@redhat.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.

Thanks,
Pedro Alves