From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31800 invoked by alias); 6 Dec 2006 17:10:24 -0000 Received: (qmail 31783 invoked by uid 22791); 6 Dec 2006 17:10:21 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Dec 2006 17:10:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kB6HA5pR224324 for ; Wed, 6 Dec 2006 17:10:05 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB6HA5Eq3117274 for ; Wed, 6 Dec 2006 18:10:05 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB6HA4l6004212 for ; Wed, 6 Dec 2006 18:10:05 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id kB6HA4a8004209; Wed, 6 Dec 2006 18:10:04 +0100 Message-Id: <200612061710.kB6HA4a8004209@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 6 Dec 2006 18:10:04 +0100 Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: drow@false.org (Daniel Jacobowitz) Date: Wed, 06 Dec 2006 17:10:00 -0000 From: "Ulrich Weigand" Cc: jimb@codesourcery.com (Jim Blandy), gdb-patches@sourceware.org, vladimir@codesourcery.com (Vladimir Prus) In-Reply-To: <20061206164303.GA755@nevyn.them.org> from "Daniel Jacobowitz" at Dec 06, 2006 11:43:04 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00067.txt.bz2 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