Re: [RFA] Location list support

Daniel Jacobowitz
2003-02-21T17:11:58Z

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