From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32717 invoked by alias); 27 Nov 2006 23:59:44 -0000 Received: (qmail 32703 invoked by uid 22791); 27 Nov 2006 23:59:42 -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 23:59:36 +0000 Received: (qmail 13024 invoked from network); 27 Nov 2006 23:59:35 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Nov 2006 23:59:35 -0000 To: "Ulrich Weigand" Cc: drow@false.org (Daniel Jacobowitz), gdb-patches@sourceware.org Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) References: <200611272323.kARNNYPo014050@d12av02.megacenter.de.ibm.com> From: Jim Blandy Date: Mon, 27 Nov 2006 23:59:00 -0000 In-Reply-To: <200611272323.kARNNYPo014050@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Tue, 28 Nov 2006 00:23:34 +0100 (CET)") Message-ID: 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: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00307.txt.bz2 "Ulrich Weigand" writes: > 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 ... You're clearly right... Hmm. What's important here is that values' offset and bitfield information be correct, so that value_subscript and value_struct_elt actually work. Which macros originate and consume that information isn't so important. If REGISTER_TO_VALUE returned a fresh struct value, and VALUE_TO_REGISTER accepted a struct value, then they'd become fully general register access hooks. This is what Daniel suggested at the top of the thread, but with the difference that REGISTER_TO_VALUE would be responsible for setting the value's offset and bitfield info, which avoids the need for knowing about a parent pointer. I'd worry a bit that we'd get arch-specific reimplementations of the now-generic gathering and scattering code in value_from_register and value_assign. At the moment, you have to choose between using only the generic code, or converting but not handling assignments to subfields; making R2V and V2R operate on struct values would give you a choice between using only the generic code, or doing all the work yourself.