From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30888 invoked by alias); 4 Aug 2004 18:26:16 -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 30880 invoked from network); 4 Aug 2004 18:26:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Aug 2004 18:26:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i74IQGe1008704 for ; Wed, 4 Aug 2004 14:26:16 -0400 Received: from zenia.home.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 i74IQEa12055; Wed, 4 Aug 2004 14:26:15 -0400 To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch] References: <4111145F.7000504@gnu.org> From: Jim Blandy Date: Wed, 04 Aug 2004 18:26:00 -0000 In-Reply-To: <4111145F.7000504@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg00039.txt.bz2 Andrew Cagney writes: > I'm just having trouble getting my head around how this will affect > core-gdb, and seeing how this addresses our need to meet GCC 3.5's > requirements? > > Can we expand on that? > > Looking at the below: > > - a single value can have multiple locations (important for store) > - could dwarf2_expr_piece be called ``struct location''? :-) That's where we're heading, yes. But I think one of the valuable things about dwarf2expr.[ch] is that it does its job --- evaluating Dwarf location expressions --- and only that job. We ought to leave the work of constructing GDB-specific data structures to its clients, like dwarf2loc.c and dwarf2-frame.c. That separation is important to preserve; I see this as just another aspect of the priorities that led to me revising Kevin's 2003 patch in the first place. So in my view, dwarf2expr.[ch] should construct a data structure that accurately reflects the result of evaluating a Dwarf 2 location expression; it should be a Dwarf-specific data structure. The construction of something like a 'struct location' should be left to dwarf2loc.c.