From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-46297-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 24902 invoked by alias); 27 Nov 2006 19:31:20 -0000
Received: (qmail 24880 invoked by uid 22791); 27 Nov 2006 19:31:13 -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; Mon, 27 Nov 2006 19:31:01 +0000
Received: (qmail 28473 invoked from network); 27 Nov 2006 19:31:00 -0000
Received: from unknown (HELO localhost) (jimb@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 27 Nov 2006 19:31:00 -0000
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: drow@false.org (Daniel Jacobowitz),  gdb-patches@sourceware.org
Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix)
References: <200611231755.kANHt6g2013138@d12av02.megacenter.de.ibm.com>
From: Jim Blandy <jimb@codesourcery.com>
Date: Mon, 27 Nov 2006 19:31:00 -0000
In-Reply-To: <200611231755.kANHt6g2013138@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Thu, 23 Nov 2006 18:55:06 +0100 (CET)")
Message-ID: <m3wt5gu1no.fsf@codesourcery.com>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-11/txt/msg00301.txt.bz2


"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> 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.

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?

I'd prefer that to adding a new field to struct value.