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

Ulrich Weigand
2006-11-27T23:23:51Z

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