Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)

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

Jim Blandy wrote:
> "Ulrich Weigand" <uweigand@de.ibm.com> writes:
> > So just to make sure I understood correctly, you'd suggesting that
> > I should *not* be using CONVERT_REGISTER_P for those registers?
> >
> > Instead, value_from_register should run into its default path,
> > and at the place where it computes the offset
> >
> >       if (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG
> >           && len < register_size (current_gdbarch, regnum))
> >         /* Big-endian, and we want less than full size.  */
> >         set_value_offset (v, register_size (current_gdbarch, regnum) - len);
> >       else
> >         set_value_offset (v, 0);
> >
> > we add some architecture-specific way to set a different offset?
> 
> I had to think it through a bit, but yes, I think that's the way to do
> it.  Then, won't the non-convertible register code in value_assign do
> the right read-modify-write thing without changes?

Yes, that would probably work for SPU. 

> My motivation is that it seems to me that 'struct value' already has
> stuff meant to handle these kinds of subregister references, but we're
> not using it.  If we do use it, then value_struct_elt and
> value_subscript will do the right thing for us.

However, I still think there's something fundamentally broken in the
way value_assign calls VALUE_TO_REGISTER.   As the documentation says,
that gdbarch functions is supposed to "convert a data value of type
TYPE to register number REG's raw format".  Calling the conversion
function with a type that does not actually denote the type of the
register contents, but some subfield, must break all other implementations
of that routine as well ...

Bye,
Ulrich

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