This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: location lists
- To: dwarf2 at corp dot sgi dot com (dwarf2), todd dot allen at ccur dot com (Todd Allen)
- Subject: Re: location lists
- From: David B Anderson <davea at quasar dot engr dot sgi dot com>
- Date: Thu, 1 Mar 2001 13:30:20 -0800 (PST)
- Reply-To: David B Anderson <davea at quasar dot engr dot sgi dot com>
Todd Allen writes:
>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.
Naturally.
>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.
Exactly.
>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.
I'm confused about why you think multiple entries are needed for
a single simple non-moving global.
The global variables are all described in .debug_pubnames
and any given global is described there exactly once.
And for .debug_aranges, each global is also described once
(unless it's one of the ones that don't stay in one place).
(Once across all compilation units, not once-per-compilation-unit)
So for normal non-moving globals it's as you desire.
What leads you to be concerned?
davea@sgi.com