From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18286 invoked by alias); 27 Nov 2006 23:23:51 -0000 Received: (qmail 18251 invoked by uid 22791); 27 Nov 2006 23:23:46 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 27 Nov 2006 23:23:37 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kARNNYn8257040 for ; Mon, 27 Nov 2006 23:23:34 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 kARNRAAq1507552 for ; Tue, 28 Nov 2006 00:27:10 +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 kARNNYXR014053 for ; Tue, 28 Nov 2006 00:23:34 +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 kARNNYPo014050; Tue, 28 Nov 2006 00:23:34 +0100 Message-Id: <200611272323.kARNNYPo014050@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 28 Nov 2006 00:23:34 +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 23:23: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 02:31:48 PM 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/msg00306.txt.bz2 Jim Blandy wrote: > "Ulrich Weigand" writes: > > 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? > > I had to think it through a bit, but yes, I think that's the way to do > it. Then, won't the non-convertible register code in value_assign do > the right read-modify-write thing without changes? Yes, that would probably work for SPU. > My motivation is that it seems to me that 'struct value' already has > stuff meant to handle these kinds of subregister references, but we're > not using it. If we do use it, then value_struct_elt and > value_subscript will do the right thing for us. However, I still think there's something fundamentally broken in the way value_assign calls VALUE_TO_REGISTER. As the documentation says, that gdbarch functions is supposed to "convert a data value of type TYPE to register number REG's raw format". Calling the conversion function with a type that does not actually denote the type of the register contents, but some subfield, must break all other implementations of that routine as well ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com