Re: location lists

[Michael Eager <eager at eagercon dot com>]

Todd Allen wrote:
> 
>    Assuming not, then the only solution is for every compilation unit to
>    describe the global variable, because only they can produce a loclist that
>    correctly describes where the global is within the PC range of their
>    compilation units.  And then the debugger is responsible for figuring out
>    that all those separate descriptions are really the same variable and
>    coalescing them (and their loclists) into a single definition.

I don't think that it is necessary to describe all globals in every
compilation unit, and, at least in C or C++, this isn't possible,
since each compilation unit is unaware of the globals defined in 
other compilation units.  Also, it is not uncommon for different
shared libraries to contain global symbols which have the same 
name but different scopes (i.e., restricted to the library). 

Dwarf is intended to describe the structure of a program.  It is
not designed to be the internal format for a debugger's symbol table.
I'm at a loss why one would want to use location lists to describe
globals.  I guess you can do this, but it seems awkward, inefficient,
and clearly unnecessary.  Your assumption that this is the only 
solution seems to be the cause of your difficulty.

This is a quality of implementation issue.  When the user of a 
debugger refers to a symbol, the debugger needs to determine 
what symbol is being referenced.  If there is a reference to it
in the current context (whatever that may mean to the debugger), 
then that reference should be used.  This might be a location 
list entry which indicates that the symbol is located in a
register.  

If the symbol is not referenced in the current context, 
then the debugger needs to find it (or them, as the case may be).
As a implementation choice, this may mean that the symbol is 
defined in a different compilation unit, shared library, or
elsewhere. 

I don't understand why a debugger might want to (or need to)
coalesce different location lists together, or how it might do
this, but that is clearly an implementation choice.  

As Dave mentioned, .pubnames provides a shortcut to having to
search each compilation unit.  But a debugger could also process
each of the compilation units, extract globals, and create its 
own internal table.

You could design your debugger to only work with symbols which
are referenced with location lists, but that is an implementation 
choice, not a Dwarf requirement.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077