From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15308 invoked by alias); 6 Feb 2004 16:36: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 15300 invoked from network); 6 Feb 2004 16:36:54 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Feb 2004 16:36:54 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Ap8yL-0004KG-TE; Fri, 06 Feb 2004 11:36:53 -0500 Date: Fri, 06 Feb 2004 16:36:00 -0000 From: Daniel Jacobowitz To: fnf@redhat.com Cc: gdb@sources.redhat.com Subject: Re: DW_OP_piece coming in gcc 3.4 Message-ID: <20040206163653.GA16536@nevyn.them.org> Mail-Followup-To: fnf@redhat.com, gdb@sources.redhat.com References: <200402060930.34787.fnf@ninemoons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402060930.34787.fnf@ninemoons.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00058.txt.bz2 On Fri, Feb 06, 2004 at 09:30:34AM -0700, Fred Fish wrote: > I've been tasked with fixing this problem, or at least deciding if it > can be fixed in the amount of time I have available to work on it. Great! > I've scanned most of the prior messages on the gdb@sources.redhat.com > and gdb-patches@sources.redhat.com mailing lists which can be found by > searching for DW_OP_piece. I intend to go back today and study them > in detail to get some history on what has been discussed about this > problem. > > If you have contributed to this topic in the past and have some new > suggestions and/or ideas, or want to contribute, I'd appreciate any > additional relevant input. At this point, I believe the correct fix will be mostly contained to the dwarf2-expr and dwarf2-loc code. A _complete_ fix will be quite complicated; enough to print variables will not be too hard, since we can read them in the LOC_COMPUTED read method, and mark them as not_lval. The problem I see with being able to write and fully use such variables is that we need to audit uses of SYMBOL_VALUE_ADDRESS to find which are used for full symbols. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer