This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Location list support
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michal Ludvig <mludvig at suse dot cz>
- Cc: GDB Patches <gdb-patches at sources dot redhat dot com>
- Date: Fri, 21 Feb 2003 12:11:39 -0500
- Subject: Re: [RFA] Location list support
- References: <3E560801.6080703@suse.cz>
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