This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: location lists



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]