Re: [rfc] Simplify internal variable handling

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

> GDB "internal variables" are a bit in odd in how they attempt to handle
> changes in current architecture (in particular byte order).  The variable
> holds its data in a value object, which is in target byte order.  However,
> the internal variable remembers the byte order that was in effect at the
> time the value was created, and compares it to the byte order in effect
> at the time the internal variable is used.  If they differ, the bytes making
> up the data of the value object are byte-swapped, assuming the value is of
> sufficiently "simple" type (integer or pointer).
> 
> The following patch tries to simplify this logic, and in the process
> eliminate the associated references to current_gdbarch, by changing the
> internal variable logic to store its data as a LONGEST or CORE_ADDR
> (i.e. in *host* byte order) instead of a struct value for those simple
> types (for more complex types, a struct value is still used).
> 
> When the variable is accessed, a struct value is recreated from those
> LONGEST or CORE_ADDR values on the fly (automatically using the 
> appropriate byte order at the time).
> 
> As a side effect, this approach also allows to simplify handling of
> internal functions.  These no longer need to overlay a host pointer
> onto a struct value's "target" bytes, but instead can simply use yet
> another flavor of storing host data in the internal variable object.
> 
> By externally exposing a LONGEST-based interface to internal variables,
> several users throughout GDB can also be simplified as they no longer
> need to care about what type to use.
> 
> Overall, the patch is a pure code simplification with no expected change
> in behaviour.
> 
> Tested on powerpc64-linux and amd64-linux.
> Any comments are welcome; I'm planning to commit in about a week.

I've checked this in as well.

Bye,
Ulrich