From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25120 invoked by alias); 14 Sep 2004 17:57:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25106 invoked from network); 14 Sep 2004 17:57:39 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Sep 2004 17:57:39 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8EHvYBA015353 for ; Tue, 14 Sep 2004 13:57:39 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8EHvSr17327; Tue, 14 Sep 2004 13:57:28 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6863128D2; Tue, 14 Sep 2004 13:55:15 -0400 (EDT) Message-ID: <41473083.70805@gnu.org> Date: Tue, 14 Sep 2004 17:57:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: implementing full scattered values References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00105.txt.bz2 It's good to see that the arch changes have been taken off the table. > Last month there was a thread on supporting DW_OP_piece: > > http://sources.redhat.com/ml/gdb/2004-08/msg00004.html > > Everyone agreed that having architecture-independent support for > arbitrary DW_OP_piece location expressions would be preferable to the > partial and architecture-dependent support, if someone could find time > to do it soon. > > Let's talk about full scattered value support. What's the best > approach? What's entailed? How do we want 'struct value' to look > when we're done? Let's try to set some concrete goals so that if > someone does have the cycles to work on this, they can have some idea > what to work towards so it'll be acceptable for inclusion in the > public sources. Daniel at the time wrote: > I'm dubious as to whether this step is even worthwhile. Another > possible intermediate step is to immediately combine the pieces, > marking the value as not_lval; read them all and piece them together in > GDB's memory. Yes, this means that they can't be assigned to, but at > least we'd be able to inspect them. I think this idea needs to be explored. Up until now we've all been assuming that we had to implement: ``struct value'' has-a array-of ``struct location'' yet what we should really be implementing is: ``struct dwarf-2-value'' is-a ``struct value'' where ``struct value'' has a small number of virtual methods that let GDB both read and write the value's underlying bytes. I guess this means lval_expression, with the other lval's being deprecated. We've already kind of got this with symbols (although the old code was never deprecated / flushed). -- Anyway, before we even start persuing this, I think we should drain our existing backlog of debuginfo patches, hopefully in time for 6.3. Andrew