From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1404 invoked by alias); 22 Nov 2006 22:48:26 -0000 Received: (qmail 1396 invoked by uid 22791); 22 Nov 2006 22:48:25 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 22 Nov 2006 22:48:21 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1Gn0t9-00052R-21; Wed, 22 Nov 2006 17:48:19 -0500 Date: Wed, 22 Nov 2006 22:48:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) Message-ID: <20061122224819.GA19267@nevyn.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20061122205727.GA15718@nevyn.them.org> <200611222213.kAMMD9YS008267@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611222213.kAMMD9YS008267@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00275.txt.bz2 On Wed, Nov 22, 2006 at 11:13:09PM +0100, Ulrich Weigand wrote: > For some reason I seem unable to convince GCC to place such > a struct into a register. Must be a mode thing... shame; it ought to be able to do this. > For registers without special conversion function, value_assign > performs a read-modify-write cycle: it reads the old contents > of the register(s), modify the bits denoted by value_offset, > value_bitsize and value_bitpos, and writes the full register > contents back. > > Maybe we need to do a similar cycle of REGISTER_TO_VALUE, > modify selected bits, VALUE_TO_REGISTER for the registers with > special conversion function? I think that's precisely it. I'm worried that this will break some other uses of VALUE_TO_REGISTER, though - how do we keep track at this point in the code of "the whole struct is in the register" or "this field is in the register"? Right now, there's limited flexibility on that, but Jim's been working on improved DW_OP_piece support which would let us write to structure pieces. > As an aside, what is this code in value_assign supposed to do: > > /* Locate the first register that falls in the value that > needs to be transfered. Compute the offset of the > value in that register. */ > { > int offset; > for (reg_offset = value_reg, offset = 0; > offset + register_size (current_gdbarch, reg_offset) <= value_offset (toval); > reg_offset++); > byte_offset = value_offset (toval) - offset; > } > > It seems clearly broken (offset remains constant 0), but I'm not > quite sure what the intent was. Um, yeah, that's definitely not sensible. Perhaps it is supposed to match the loop further down, in which offset would go up by register_size? -- Daniel Jacobowitz CodeSourcery