From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23661 invoked by alias); 7 Dec 2006 06:34:17 -0000 Received: (qmail 23653 invoked by uid 22791); 7 Dec 2006 06:34:16 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Dec 2006 06:34:07 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GsCpU-0008Ai-5m for gdb-patches@sources.redhat.com; Thu, 07 Dec 2006 07:34:00 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Dec 2006 07:34:00 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Dec 2006 07:34:00 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) Date: Thu, 07 Dec 2006 06:34:00 -0000 Message-ID: References: <20061206164303.GA755@nevyn.them.org> <200612061710.kB6HA4a8004209@d12av02.megacenter.de.ibm.com> <20061206171231.GA2999@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 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/msg00091.txt.bz2 Daniel Jacobowitz wrote: > 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? It does. We'd only have to use value_to_register as opposed to write_memory when sending the value back. Plus a bunch of unexpected problems but nothing impossible. - Volodya