From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11323 invoked by alias); 22 Nov 2006 19:25:22 -0000 Received: (qmail 11310 invoked by uid 22791); 22 Nov 2006 19:25:21 -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, 22 Nov 2006 19:25:17 +0000 Received: (qmail 10237 invoked from network); 22 Nov 2006 19:25:16 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Nov 2006 19:25:16 -0000 To: gdb-patches@sourceware.org Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) References: <200611111838.kABIcHaZ031319@d12av02.megacenter.de.ibm.com> <20061122142300.GA1120@nevyn.them.org> From: Jim Blandy Date: Wed, 22 Nov 2006 19:25:00 -0000 In-Reply-To: <20061122142300.GA1120@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 22 Nov 2006 09:23:00 -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-11/txt/msg00262.txt.bz2 Daniel Jacobowitz writes: > On Sat, Nov 11, 2006 at 07:38:17PM +0100, Ulrich Weigand wrote: >> The patch below 'fixes' this for SPU by at least not calling >> VALUE_TO_REGISTER for bitfield assignments, but falling back >> to the default code. This happens to work for SPU; other >> platforms with special conversion needs might need to get a >> chance for the back-end to get involved even then. I guess >> when this happens we can think of an extended interface that >> would pass the bitsize information through to the back-end ... > > I've got to admit that I don't like it :-( Yeah --- it'll mask problems if someone else has a convertible register with bitfields. > VALUE_TO_REGISTER has only one caller and eight definitions (plus some > documentation). It shouldn't be hard to update it. What additional > information do you need? Would passing the two values instead of one > regnum and one contents do it? Or, possibly another gdbarch method, VALUE_TO_REGISTER_BITFIELD, which can be left unset, provoking an internal error in value_assign?