From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20269 invoked by alias); 22 Nov 2006 19:55:18 -0000 Received: (qmail 20261 invoked by uid 22791); 22 Nov 2006 19:55:18 -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; Wed, 22 Nov 2006 19:55:05 +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 kAMJt2hA272658 for ; Wed, 22 Nov 2006 19:55:02 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 kAMJwVjA2715690 for ; Wed, 22 Nov 2006 20:58:31 +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 kAMJt23b006976 for ; Wed, 22 Nov 2006 20:55:02 +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 kAMJt2MT006973; Wed, 22 Nov 2006 20:55:02 +0100 Message-Id: <200611221955.kAMJt2MT006973@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 22 Nov 2006 20:55:02 +0100 Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: drow@false.org (Daniel Jacobowitz) Date: Wed, 22 Nov 2006 19:55:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20061122192845.GA12105@nevyn.them.org> from "Daniel Jacobowitz" at Nov 22, 2006 02:28:45 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/msg00266.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Nov 22, 2006 at 11:25:48AM -0800, Jim Blandy wrote: > > Or, possibly another gdbarch method, VALUE_TO_REGISTER_BITFIELD, which > > can be left unset, provoking an internal error in value_assign? > > I'm not even quite sure how bitfields come into it. The register > type's a builtin_type_vec128. The problem occurs if there is a source-level variable of bitfield type that currently resides in such a register, and the GDB user attempts to assign to that variable. I guess one problem here is that there's two different problems intermixed here: - if an integral type (possibly bitfield) resides in a vector register, which parts of the vector register can I find it at (that's the platform specific part) - where within the bitfield is the particular element I want to access (that's the generic part) Maybe the best solution would be for GDB common code to call VALUE_TO_REGISTER / REGISTER_TO_VALUE to solve the first problem, but still solve the second problem in common code. Otherwise every target would have to implement all the bitfield fiddling separately -- I'm not sure this is required. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com