From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26793 invoked by alias); 7 Feb 2005 20:14:21 -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 26740 invoked from network); 7 Feb 2005 20:14:09 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Feb 2005 20:14:09 -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.11) with ESMTP id j17KE9qN013546 for ; Mon, 7 Feb 2005 15:14:09 -0500 Received: from localhost.redhat.com (vpn50-85.rdu.redhat.com [172.16.50.85]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j17KE8O24109; Mon, 7 Feb 2005 15:14:08 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B8CC37D79; Mon, 7 Feb 2005 15:13:51 -0500 (EST) Message-ID: <4207CBFC.3010900@gnu.org> Date: Mon, 07 Feb 2005 20:17:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: a value has-a location References: <4187A414.5060804@gnu.org> In-Reply-To: <4187A414.5060804@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00030.txt.bz2 Andrew Cagney wrote: > (back to this one again) > > We've the relationship: > > LOCATION ----<> VALUE <>----- TYPE > . > /_\ > | > +-------------------------. > | | > DWARF-2 LOCATION LEGACY LOCATION Now that I've got "struct value" more or less under control, I've sufficient information to expand refine this. First the above becomes: TYPE -----<> VALUE <>----- CONTENT i.e.: VALUE has-a TYPE; VALUE has-a CONTENT When it comes to CONTENT, that can be further refined: 1 N CONTENT <>------ PIECE <> \ `---- BUFFER i.e., CONTENT has-a 1:N PIECE; CONTENT has-a BUFFER. So what was LOCATION has been expanded into CONTENT (rough correspondence to the existing value->contents) and PIECE (rough correspondence to DW_OP_piece). Looking at the code, the existing VALUE fields, dependent on whether they make up part of the content (e.g., value->contents) or the content's location (aka piece) (e.g., value->lval), need to be moved to either CONTENT or PIECE. For fields moved to CONTENT, things are straight forward: Old: value->aligner.contents New: value->contents->buffer Old: value->lazy New: value->contents->lazy However, for the VALUE fields that describe the actual location (i.e., PIECE) there's a problem - there are now N PIECEs. Initially I'll assume there's only one piece giving: Old: value->lval Hack: value->contents->piece[0]->lval (the assume-one-piece methods will be DEPRECATED). Going forward the code can be updated to eliminate that assumption, instead iterating over multiple pieces. Andrew