location lists

[todd dot allen at ccur dot com (Todd Allen)]

I've been struggling with how to implement location lists for global
variables in our Ada compilation model.  Until recently, I had not noticed
that the PC ranges embedded in them are relative to the containing
compilation unit.

That's problematic with our "emit the DWARF once" approach.  I find myself
wanting that "default" location description in a location list, that I think
has been suggested before.

There's another related issue, too.  As a debugger user, I want to be able to
access the value (and even modify the value) of a global variable, regardless
of the current scope at which the debugger is stopped.  That is, I want
visibility to all the global variables in the program, not just those that
have visible extern declarations at the point in the code where the debugger
is stopped.

It seems like you'd want the global variable to have a static location that
covered nearly the entire PC address space in the program.  The only holes
would be in locations where the optimizer had created a local copy of the
global variable for speed (probably putting it in a register), had modified
the local copy, and hadn't updated the static location yet.

So, unless every compilation unit describes every global variable in the
program (which is impossible, or at least prohibitively hard, since not every
object can necessarily know about every global in every other object), I
don't see how this can work.

And for Ada, it's not just global variables, either.  It also applies to
local variables that can be up-level referenced from subunits.

Sure, this is a quality-of-implementation issue, but in this case it seems
like the DWARF is prohibiting good quality.

I hope I'm just missing a piece of the puzzle, and there's a way to support
this.  If so, I'd appreciate some enlightenment.

-- 
Todd Allen
Concurrent Computer Corporation