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

[Daniel Jacobowitz <drow at false dot org>]

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