From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31455 invoked by alias); 27 Nov 2006 22:06:36 -0000 Received: (qmail 31435 invoked by uid 22791); 27 Nov 2006 22:06:34 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 27 Nov 2006 22:06:28 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kARM6OL4190904 for ; Mon, 27 Nov 2006 22:06:24 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 kARMA0Me2007246 for ; Mon, 27 Nov 2006 23:10:00 +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 kARM6Ovo013011 for ; Mon, 27 Nov 2006 23:06:24 +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 kARM6OqG013008; Mon, 27 Nov 2006 23:06:24 +0100 Message-Id: <200611272206.kARM6OqG013008@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 27 Nov 2006 23:06:24 +0100 Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: jimb@codesourcery.com (Jim Blandy) Date: Mon, 27 Nov 2006 22:06:00 -0000 From: "Ulrich Weigand" Cc: drow@false.org (Daniel Jacobowitz), gdb-patches@sourceware.org In-Reply-To: from "Jim Blandy" at Nov 27, 2006 11:31:39 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-11/txt/msg00304.txt.bz2 Jim Blandy wrote: > It seems to me this is the problem to fix. When value_from_register > retrieves a char from an SPU register, and that char is occupying byte > three of the register, then if that value doesn't have its > value_offset set, that seems wrong. You're using CONVERTIBLE_P and > VALUE_TO_REGISTER / REGISTER_TO_VALUE to make up for that loss of > information; why not actually provide it? So just to make sure I understood correctly, you'd suggesting that I should *not* be using CONVERT_REGISTER_P for those registers? Instead, value_from_register should run into its default path, and at the place where it computes the offset if (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG && len < register_size (current_gdbarch, regnum)) /* Big-endian, and we want less than full size. */ set_value_offset (v, register_size (current_gdbarch, regnum) - len); else set_value_offset (v, 0); we add some architecture-specific way to set a different offset? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com