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: Daniel Jacobowitz <drow at false dot org>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Jim Blandy <jimb at codesourcery dot com>, gdb-patches at sourceware dot org, Vladimir Prus <vladimir at codesourcery dot com>
- Date: Wed, 6 Dec 2006 11:43:04 -0500
- Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
- References: <20061128000117.GA21865@nevyn.them.org> <200612061629.kB6GTROh021274@d12av02.megacenter.de.ibm.com>
On Wed, Dec 06, 2006 at 05:29:27PM +0100, Ulrich Weigand wrote:
> The patch I proposed to remember the type of the value residing
> in the register would allow all the above cases to work without
> changes to architecture code, and would in fact work correctly
> with any conceivable implementation of the current r_t_v / v_t_r
> interface. However, it does have the disadvantage of requiring
> an additional field in struct value. (Maybe we can make up that
> loss -- do we actually still require VALUE_ADDRESS for register
> values?)
>
> Any suggestions?
Vladimir has actually been working on a similar change for a different
purpose. He added a "parent value" pointer to values; bitfields then
are accessed by reading the enclosing structure and extracting bits
from value_contents.
I've been kind of waffling on Vladimir's patch because it has a nasty
bug that I just can't find any way to fix. Adding pointers between
values messes up release_value / value_free; either we leak values or
we access uninitialized memory, or both. As Vladimir has pointed out
several times, what we really need is a shared_ptr :-)
What do you think? Would this solve the same problem as your patch?
Any bright ideas on the memory management? We could always go whole
hog and add a refcount... I realize now that if we only need to
reference count one reference for whoever called release_value (or
being on the value chain) and one per child field, it wouldn't
be too hard.
--
Daniel Jacobowitz
CodeSourcery