Re: Checked in: [RFA] read_frame_register_value and big endian arches

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

Joel Brobecker wrote:
> > > gdb/ChangeLog:
> > > 
> > >         * findvar.c (read_frame_register_value): Read the correct bytes
> > >         from registers on big-endian architectures.
> > 
> > Looks good to me.
> 
> Now checked in. Thanks again for the review...

It seems this completely broke reading of register variables on SPU.  These
are in the high-order element of the (always vector) registers, even though
we have a big-endian architecture.

It seems the underlying problem is that your new read_frame_register_value
routine completely ignores the value_offset of the lval_register value.
This is the place where this information is encoded: note that for
big-endian architectures, value_offset is already correct, so if you'd
respect it, you wouldn't need any special-purpose big-endian code.

Also, if you'd respect value_offset, the SPU special cases would work.

In general, if V is a value with value_lval (V) == lval_register, its
contents must be retrieved by reading the register(s) starting with
number VALUE_REGNUM (V) in their "natural" sizes, skipping the first
value_offset (V) bytes of the concatenated result, and using the
next TYPE_LENGTH (value_type (V)) bytes as the value contents.


If you look at the original code your patch:
http://www.sourceware.org/ml/gdb-patches/2011-10/msg00713.html
replaced, it does take value_offset into account:

      /* Get the data.  */
      v2 = get_frame_register_value (frame, regnum);

      value_contents_copy (v, 0, v2, value_offset (v), len);

While get_frame_register_value always reads the full register,
the value_contents_copy call then extracts only the part
starting at value_offset.

Note that to handle multi-register values, you may actually
need to skip full registers if value_offset starts out bigger
than the size of a register.  See the get_frame_register_bytes
routine how this should be handled.

Note that before Tom's patch here:
http://sourceware.org/ml/gdb-patches/2011-07/msg00351.html
the value_from_register routine actually called
get_frame_register_bytes to handle all those situations ...

The only problematic thing with get_frame_register_bytes is that
it doesn't create a value as output, and therefore does not
propagate precise availability information.  The new
read_frame_register_value should probably implement this
(or maybe even replace get_frame_register_bytes).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com