From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3501 invoked by alias); 21 Feb 2003 17:11:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3487 invoked from network); 21 Feb 2003 17:11:58 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 21 Feb 2003 17:11:58 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18mIbH-0003mJ-00; Fri, 21 Feb 2003 13:12:47 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18mGi3-0003vU-00; Fri, 21 Feb 2003 12:11:39 -0500 Date: Fri, 21 Feb 2003 17:11:00 -0000 From: Daniel Jacobowitz To: Michal Ludvig Cc: GDB Patches Subject: Re: [RFA] Location list support Message-ID: <20030221171139.GA14877@nevyn.them.org> Mail-Followup-To: Michal Ludvig , GDB Patches References: <3E560801.6080703@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E560801.6080703@suse.cz> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00521.txt.bz2 On Fri, Feb 21, 2003 at 12:05:37PM +0100, Michal Ludvig wrote: > Hi, > attached is a patch that adds support for .debug_loc sections as > generated by newer versions of GCC (eg. from rtlopt-branch). > > It works in this way: > - Parse .debug_loc into a list of new internal structures (struct > loclist_master, struct loclist_block). Each loclist_master belongs to > one variable and contains a pointer to a chain of loclist_blocks that > represent different locations where the given variable can be found > during it's life. > - Next the .debug_info is parsed and when a new symbol is being added, > the function new_symbol() first checks, if it's location is described by > a location list or not. If not, then the old method is used. If there is > a location list (in loclist_master) found for this variable, each one of > its loclist_blocks is parsed and added to symbol.loclist chain. The > structure symbol itself is filled up with the first loclist entry found > for this symbol (ie with the values for the lowest PC where the symbol > is valid). > - When the variable's value is to be read (in read_var_value()), it's > first checked if there is a non-null loclist pointer in variable's > 'symbol' structure. If not, everything continued like it did until now. > If there is a loclist it's searched for a block valid for the actual PC > and if found, the variable is updated with description found there. If a > valid block is not found, it's assumed that a variable was already > optimized out on this PC and again the symbol structure is updated in an > appropriate way. > > Comments? Approvals? Let me try saying this again... Michal, are you watching GDB HEAD development? Have you been following my discussions with Jim about how DW_AT_location should be supported? I didn't just ask you to wait for the LOC_COMPUTED patch out of sheer pique. If you're not using that mechanism, then you're defeating the whole purpose it was implemented for. For instance, a good sized chunk of code you delete in the patch below is no longer there. Be careful updating, since you copied that deleted code to new functions; it shouldn't be there either. Basically, location lists should be represented as LOC_COMPUTED symbols; the LOC_COMPUTED lookup mechanism should be updated to accept a PC when computing the location. The entire thing will be worlds simpler than all the work you did below, and a heck of a lot less fragile. You just need to parse the location lists, store them in the location baton, and select a list to evaluate in dwarf2loc.c. If there's no list entry for $pc, that's where you return optimized-out; it might take another little change to accept an optimized-out result there. If there is a list entry you evaluate it just like presently. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer