From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10044 invoked by alias); 11 Nov 2006 18:38:28 -0000 Received: (qmail 10035 invoked by uid 22791); 11 Nov 2006 18:38:27 -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; Sat, 11 Nov 2006 18:38:20 +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 kABIcHFO169398 for ; Sat, 11 Nov 2006 18:38:17 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 kABIfRLK372786 for ; Sat, 11 Nov 2006 19:41:27 +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 kABIcHdu031322 for ; Sat, 11 Nov 2006 19:38:17 +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 kABIcHaZ031319 for ; Sat, 11 Nov 2006 19:38:17 +0100 Message-Id: <200611111838.kABIcHaZ031319@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sat, 11 Nov 2006 19:38:17 +0100 Subject: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: gdb-patches@sourceware.org Date: Sat, 11 Nov 2006 18:38:00 -0000 From: "Ulrich Weigand" 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00083.txt.bz2 Hello, this fixes another problem for the SPU port. In value_assign, when assigning to a register that is marked as CONVERT_REGISTER_P, the front end always calls VALUE_TO_REGISTER, which always cleans out the full previous contents of the register. This happens even if the value is a bitfield that occupies only part of the register, and the remaining contents should *not* be changed. The back end's VALUE_TO_REGISTER has no real chance to do this right since it doesn't even get the value object as input, and thus doesn't know that value_bitsize is nonzero. This probably rarely triggers on other architectures, as those registers that require CONVERT_REGISTER_P tend to be special registers that usually don't hold bitfield values. On the SPU however, every general-purpose register needs CONVERT_REGISTER_P (since they are really 16-byte vector registers, and loading/ storing scalar values required a special conversion). The patch below 'fixes' this for SPU by at least not calling VALUE_TO_REGISTER for bitfield assignments, but falling back to the default code. This happens to work for SPU; other platforms with special conversion needs might need to get a chance for the back-end to get involved even then. I guess when this happens we can think of an extended interface that would pass the bitsize information through to the back-end ... Tested on SPU (where it fixes about a dozen test cases). Also tested without regressions on s390-ibm-linux and s390x-ibm-linux. OK? Bye, Ulrich ChangeLog: * valops.c (value_assign): Do not call VALUE_TO_REGISTER for bitfield assignments. diff -urN gdb-orig/gdb/valops.c gdb-head/gdb/valops.c --- gdb-orig/gdb/valops.c 2006-10-09 21:28:14.000000000 +0200 +++ gdb-head/gdb/valops.c 2006-10-30 19:39:02.972619008 +0100 @@ -643,6 +643,7 @@ error (_("Value being assigned to is no longer active.")); if (VALUE_LVAL (toval) == lval_register + && value_bitsize (toval) == 0 && CONVERT_REGISTER_P (VALUE_REGNUM (toval), type)) { /* If TOVAL is a special machine register requiring -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com