From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2770 invoked by alias); 6 Dec 2006 23:24:54 -0000 Received: (qmail 2753 invoked by uid 22791); 6 Dec 2006 23:24:51 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Dec 2006 23:24:42 +0000 Received: (qmail 29378 invoked from network); 6 Dec 2006 23:24:41 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Dec 2006 23:24:41 -0000 To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) References: <200612061629.kB6GTROh021274@d12av02.megacenter.de.ibm.com> <20061206220220.GA14086@nevyn.them.org> From: Jim Blandy Date: Wed, 06 Dec 2006 23:24:00 -0000 In-Reply-To: <20061206220220.GA14086@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 6 Dec 2006 17:02:20 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00085.txt.bz2 Daniel Jacobowitz writes: > On Wed, Dec 06, 2006 at 01:21:48PM -0800, Jim Blandy wrote: >> I'm reluctant to get into storing original types and having reference >> counts; it's a lot of complexity in the core code to handle >> architectures that are doing odd things. > > What about the fact that Vladimir wanted it for memory bitfields too? > Nothing architecture-specific about that. I'm not sure I think it's a great idea there, either. I want to write up an explanation of why (essentially, because you're just replacing the problem of too many reads with the problem of too few reads), but I'm crunched at the moment, and haven't had time to make sure I actually understand what everyone has written. >> I've got unsubmitted patches for GDB that implement a new kind of >> value, whose contents are read and written via functions provided by >> the user, based on a generic closure pointer. Future r2v / v2r >> functions could produce values of this sort, instead of using odd >> bitpos values. So the kludge wouldn't last forever. > > Then let's not add the kludge at all. If the alternative you have in mind is, let's give r2v the ability to construct any kind of value it wants, and v2r access to the whole value, thus solving Ulrich's problem, and then get computed lvalues in to solve the Alpha's problem, then I'm in agreement.