From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28977 invoked by alias); 2 Nov 2004 15:32:55 -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 28927 invoked from network); 2 Nov 2004 15:32:54 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 2 Nov 2004 15:32:54 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id ED8BA47D9F; Tue, 2 Nov 2004 07:32:52 -0800 (PST) Date: Tue, 02 Nov 2004 15:32:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: a value has-a location Message-ID: <20041102153252.GM27334@gnat.com> References: <4187A414.5060804@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4187A414.5060804@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-11/txt/msg00017.txt.bz2 > I intend refactoring ``struct value'' so that there is an explicit > location object (at present it's a union :-/). Initially it will > probably remain in ``struct value''. Once the location has been > separated out we can look at making it virtual with separate dwarf-2 and > legacy locations. Looks good. I didn't comment on making struct value opaque, but I think it's a terrific idea. I think we should be doing the same for struct type, and possible struct symbol/minimal_symbol/partial_symbol as well. And heck, we could do the same for the symtab structs as well. That would probably help us with transforming the low/high address range into a set of ranges, for the compilation units that are not contiguous in memory (a long term project of mine). -- Joel