From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1212 invoked by alias); 6 Dec 2006 17:12:42 -0000 Received: (qmail 1107 invoked by uid 22791); 6 Dec 2006 17:12:41 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 06 Dec 2006 17:12:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1Gs0Jr-0000mn-1z; Wed, 06 Dec 2006 12:12:31 -0500 Date: Wed, 06 Dec 2006 17:12:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: Jim Blandy , gdb-patches@sourceware.org, Vladimir Prus Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) Message-ID: <20061206171231.GA2999@nevyn.them.org> Mail-Followup-To: Ulrich Weigand , Jim Blandy , gdb-patches@sourceware.org, Vladimir Prus References: <20061206164303.GA755@nevyn.them.org> <200612061710.kB6HA4a8004209@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612061710.kB6HA4a8004209@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00068.txt.bz2 On Wed, Dec 06, 2006 at 06:10:04PM +0100, Ulrich Weigand wrote: > 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 ... It hasn't been posted yet - it's not quite done. > > 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. Right. The current version only did this for bitfields in memory, rather than fields in registers, but it shouldn't be hard to extend. Does that make sense, Vlad? -- Daniel Jacobowitz CodeSourcery