From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18867 invoked by alias); 23 Nov 2006 17:55:16 -0000 Received: (qmail 18859 invoked by uid 22791); 23 Nov 2006 17:55:16 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Nov 2006 17:55:10 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id kANHt7is101032 for ; Thu, 23 Nov 2006 17:55:07 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 kANHwb4i2973886 for ; Thu, 23 Nov 2006 18:58:37 +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 kANHt6ml013141 for ; Thu, 23 Nov 2006 18:55:06 +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 kANHt6g2013138; Thu, 23 Nov 2006 18:55:06 +0100 Message-Id: <200611231755.kANHt6g2013138@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 23 Nov 2006 18:55:06 +0100 Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: drow@false.org (Daniel Jacobowitz) Date: Thu, 23 Nov 2006 17:55:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20061123161641.GA11679@nevyn.them.org> from "Daniel Jacobowitz" at Nov 23, 2006 11:16:41 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/msg00280.txt.bz2 Daniel Jacobowitz wrote: > I suppose there's times we want to destroy the rest of the register, > so knowing where it is in the register isn't enough? The problem is, we don't *know* where it is in the register. For example, on the SPU "char" values are placed in byte 3 of the 16 bytes of a general purpose register, "short" values are placed in bytes 2 and 3, and "int" values are placed in bytes 0 .. 3. ("long long" is placed in 0 .. 7.) However, structs are placed into registers starting from byte 0 always. So if we have struct { char x; char y; char z; char w; } s; char t; and both s and t reside in registers, then a value to access t would look exactly the same as a value to access s.x (i.e. type "char", lval_regnum, value_offset == 0), but to access them requires using different bytes of the register. We might be able to fix this particular problem by having value_from_register somehow set the value_offset to 3 when retrieving a value of type "char" from a register. However, even though there is a comment saying "The assumption is that REGISTER_TO_VALUE populates the entire value including the location.", that isn't actually possible with the current interface since REGISTER_TO_VALUE doesn't actually *get* the value itself. So maybe we can extend REGISTER_TO_VALUE by an argument to return the byte offset of the original value in the register, and extend VALUE_TO_REGISTER by an argument to pass the requested byte offset (which might point to a subobject of the whole object), this could work ... We'd still have to solve the bitfield problem, but that might be possible in common code later on. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com