This is the mail archive of the
mailing list for the GDB project.
Re: Checked in: [RFA] read_frame_register_value and big endian arches
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: brobecker at adacore dot com (Joel Brobecker)
- Cc: gdb-patches at sourceware dot org, tromey at redhat dot com
- Date: Wed, 16 Nov 2011 19:22:51 +0100 (CET)
- Subject: Re: Checked in: [RFA] read_frame_register_value and big endian arches
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:
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:
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).
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE