From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14939 invoked by alias); 22 Nov 2006 20:43:16 -0000 Received: (qmail 14930 invoked by uid 22791); 22 Nov 2006 20:43:15 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Nov 2006 20:43:09 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kAMKh7wj171442 for ; Wed, 22 Nov 2006 20:43:07 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 kAMKkZnm3215488 for ; Wed, 22 Nov 2006 21:46:35 +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 kAMKh6rj030469 for ; Wed, 22 Nov 2006 21:43:06 +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 kAMKh6KO030466; Wed, 22 Nov 2006 21:43:06 +0100 Message-Id: <200611222043.kAMKh6KO030466@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 22 Nov 2006 21:43:06 +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 20:43:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20061122203002.GA14849@nevyn.them.org> from "Daniel Jacobowitz" at Nov 22, 2006 03:30:02 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/msg00269.txt.bz2 Daniel Jacobowitz wrote: > I'm not sure how you are using "bitfield type" here; could you post an > example? i.e. do you mean: > > int x:7; > > or > > struct { int x:7; int y:25; } z; The latter; sorry for being vague. The problem manifests in store.exp's check_field test cases: FAIL: gdb.base/store.exp: f_1.i FAIL: gdb.base/store.exp: f_1.j FAIL: gdb.base/store.exp: f_1.k FAIL: gdb.base/store.exp: F_1.i FAIL: gdb.base/store.exp: F_1.j FAIL: gdb.base/store.exp: F_1.k FAIL: gdb.base/store.exp: f_2.i FAIL: gdb.base/store.exp: f_2.j FAIL: gdb.base/store.exp: f_2.k FAIL: gdb.base/store.exp: F_2.i FAIL: gdb.base/store.exp: F_2.j FAIL: gdb.base/store.exp: F_2.k FAIL: gdb.base/store.exp: f_3.i FAIL: gdb.base/store.exp: f_3.j FAIL: gdb.base/store.exp: f_3.k FAIL: gdb.base/store.exp: F_3.i FAIL: gdb.base/store.exp: F_3.j FAIL: gdb.base/store.exp: F_3.k FAIL: gdb.base/store.exp: f_4.i FAIL: gdb.base/store.exp: f_4.j FAIL: gdb.base/store.exp: f_4.k FAIL: gdb.base/store.exp: F_4.i FAIL: gdb.base/store.exp: F_4.j FAIL: gdb.base/store.exp: F_4.k struct f_1 {unsigned i:1;unsigned j:1;unsigned k:1; } f_1 = {1,1,1}, F_1; struct f_1 wack_field_1 (void) { register struct f_1 u = f_1; return u; } tbreak wack_field_1 Breakpoint 26 at 0xdd0: file /home/uweigand/fsf/gdb-head/gdb/testsuite/gdb.base/store.c, line 227. (gdb) PASS: gdb.base/store.exp: tbreak wack_field_1 continue Continuing. wack_field_1 () at /home/uweigand/fsf/gdb-head/gdb/testsuite/gdb.base/store.c:227 227 register struct f_1 u = f_1; (gdb) PASS: gdb.base/store.exp: continue field 1 next 229 } (gdb) PASS: gdb.base/store.exp: next field 1 print u $73 = {i = 1, j = 1, k = 1} (gdb) PASS: gdb.base/store.exp: old field 1 set variable u = F_1 (gdb) PASS: gdb.base/store.exp: set variable u = F_1 print u $74 = {i = 0, j = 0, k = 0} (gdb) PASS: gdb.base/store.exp: new field 1 set variable u = F_1, u.i = f_1.i (gdb) PASS: gdb.base/store.exp: set variable u = F_1, u.i = f_1.i print u $75 = {i = 0, j = 0, k = 0} (gdb) FAIL: gdb.base/store.exp: f_1.i > I'm wondering if you're describing the latter case, in which case the > problem is that we're calling value_to_register on only part of the > value we want in the register. Yes, that's what I was thinking. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com