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: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: jimb at codesourcery dot com (Jim Blandy), gdb-patches at sourceware dot org, vladimir at codesourcery dot com (Vladimir Prus)
- Date: Wed, 6 Dec 2006 18:10:04 +0100 (CET)
- Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
Daniel Jacobowitz wrote:
> 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.
Can you point me to the patch? I didn't find it on the gdb-patches list ...
> What do you think? Would this solve the same problem as your patch?
Depending on the circumstances when a "child" value is generated, it
may solve the same problem. To solve the register value problem,
we would need to make sure that accessing a component of a value in
a register would create a "child" value, and v_t_r is always only
ever called on the (grand-)parent that corresponds to the value
originally retrieved by r_t_v.
> 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.
I guess refcounts should be fine ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com