Re: [RFA] Location list support

[Daniel Jacobowitz <drow@mvista.com>]

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