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: Wed, 06 Dec 2006 15:39:47 -0800
- Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
- References: <200612062316.kB6NG5Z9009161@d12av02.megacenter.de.ibm.com>
"Ulrich Weigand" <uweigand@de.ibm.com> writes:
>> I've got unsubmitted patches for GDB that implement a new kind of
>> value, whose contents are read and written via functions provided by
>> the user, based on a generic closure pointer. Future r2v / v2r
>> functions could produce values of this sort, instead of using odd
>> bitpos values. So the kludge wouldn't last forever.
>
> I'm not sure I see how this would solve the problem at hand: assume
> r2v creates a value containing special functions to read and write
> the register. Then common code goes and creates a value refering
> to a sub-field of that value. How do we access that derived value?
> Using the same access functions as provided for the full value --
> but how do they know they should operate only on a part (which part)?
> It would appear that this is exactly the same problem as we're
> currently discussing ...
r2v would create a computed lvalue V whose closure indicates how the
value is encoded in the register. V's contents are the decoded
register contents. Common code goes and creates a value W referring
to a sub-field of the value. W contains offset, bitpos and bitsize
values indicating the sub-field's position within the decoded
contents.
When W is read, its 'read' function is called, which reads the
register, does the decoding, and then extracts the appropriate
portion.
When W is assigned to, its 'write' function is called, which can do
the appropriate decode-modify-encode steps, and write the re-encoded
value back to the register.
The key is that r2v knows how to both decode the register's contents,
and how to re-encode both the full contents, or a portion of the
contents, so it can leave enough information in the closure to tell
v2r how to handle component writes.