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

[Jim Blandy <jimb at codesourcery dot com>]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> 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 ...

You're clearly right...  Hmm.

What's important here is that values' offset and bitfield information
be correct, so that value_subscript and value_struct_elt actually
work.  Which macros originate and consume that information isn't so
important.

If REGISTER_TO_VALUE returned a fresh struct value, and
VALUE_TO_REGISTER accepted a struct value, then they'd become fully
general register access hooks.  This is what Daniel suggested at the
top of the thread, but with the difference that REGISTER_TO_VALUE
would be responsible for setting the value's offset and bitfield info,
which avoids the need for knowing about a parent pointer.

I'd worry a bit that we'd get arch-specific reimplementations of the
now-generic gathering and scattering code in value_from_register and
value_assign.  At the moment, you have to choose between using only
the generic code, or converting but not handling assignments to
subfields; making R2V and V2R operate on struct values would give you
a choice between using only the generic code, or doing all the work
yourself.