From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22363 invoked by alias); 22 Nov 2006 22:13:19 -0000 Received: (qmail 22352 invoked by uid 22791); 22 Nov 2006 22:13:19 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Nov 2006 22:13:12 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAMMD9Uf175290 for ; Wed, 22 Nov 2006 22:13:09 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 kAMMGcOB2723896 for ; Wed, 22 Nov 2006 23:16:38 +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 kAMMD9Dv008270 for ; Wed, 22 Nov 2006 23:13:09 +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 kAMMD9YS008267; Wed, 22 Nov 2006 23:13:09 +0100 Message-Id: <200611222213.kAMMD9YS008267@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 22 Nov 2006 23:13:09 +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 22:13:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20061122205727.GA15718@nevyn.them.org> from "Daniel Jacobowitz" at Nov 22, 2006 03:57:27 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/msg00273.txt.bz2 Daniel Jacobowitz wrote: > Does the same thing happen for struct { char w, x, y, z; }? For some reason I seem unable to convince GCC to place such a struct into a register. However, when attempting to manipulate a register directly using its type structure, I'm seeing the same problem: (gdb) print $r3 $1 = {uint128 = 0x00000001000000000000000000000000, v4_float = {1.40129846e-45, 0, 0, 0}, v4_int32 = {1, 0, 0, 0}, v8_int16 = {0, 1, 0, 0, 0, 0, 0, 0}, v16_int8 = "\000\000\000\001", '\0' } (gdb) print $r3.v4_int32 $2 = {1, 0, 0, 0} (gdb) print $r3.v4_int32[2] $3 = 0 (gdb) set variable $r3.v4_int32[2] = 5 (gdb) print $r3.v4_int32 $4 = {5, 0, 0, 0} 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? 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. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com