This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
- From: Jim Blandy <jimb at codesourcery dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: drow at false dot org (Daniel Jacobowitz), gdb-patches at sourceware dot org
- Date: Mon, 27 Nov 2006 16:00:14 -0800
- Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
- References: <200611272323.kARNNYPo014050@d12av02.megacenter.de.ibm.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.