From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21549 invoked by alias); 23 Nov 2006 13:57:31 -0000 Received: (qmail 21540 invoked by uid 22791); 23 Nov 2006 13:57:31 -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; Thu, 23 Nov 2006 13:57:24 +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 kANDvJAV033606 for ; Thu, 23 Nov 2006 13:57:19 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 kANE0n1w2027768 for ; Thu, 23 Nov 2006 15:00:49 +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 kANDvJRn031676 for ; Thu, 23 Nov 2006 14:57:19 +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 kANDvJNm031673; Thu, 23 Nov 2006 14:57:19 +0100 Message-Id: <200611231357.kANDvJNm031673@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 23 Nov 2006 14:57:19 +0100 Subject: Re: [RFA][2/5] New port: Cell BE SPU (valops.c fix) To: drow@false.org (Daniel Jacobowitz) Date: Thu, 23 Nov 2006 13:57:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20061122224819.GA19267@nevyn.them.org> from "Daniel Jacobowitz" at Nov 22, 2006 05:48:19 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/msg00277.txt.bz2 Daniel Jacobowitz wrote: > 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. Hmm, it looks like the enclosing type information is simply lost currently. Those values come from value_subscripted_rvalue (which appears to return an lvalue despite its name?), which simply forgets about the base array type, and only updates value_offset. What value_assign would need is the information: I want to update an object of type "int", which resides at offset 12 within an object of type "array of four ints" which resides in register 42. Then, we could call REGISTER_TO_VALUE on the enclosing type, and do the read-update-write cycle. However, we don't have the enclosing type in the data structure at all, which makes it difficult. I'm wondering whether we can employ the value_enclosing_type (and related) fields for this purpose, but I'm not completely sure how that would interact with the C++ use of those. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com