This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: location lists
- To: eager at eagercon dot com (Michael Eager)
- Subject: Re: location lists
- From: todd dot allen at ccur dot com (Todd Allen)
- Date: Thu, 8 Mar 2001 10:48:28 -0700 (MST)
- Cc: dwarf2 at corp dot sgi dot com (dwarf2)
- Reply-To: todd dot allen at ccur dot com (Todd Allen)
>
> Todd Allen wrote:
> >
> > Right here is where you lose me. DWARF doesn't describe references to
> > global symbols; it only describe declarations & definitions. So, how can
> > a debugger know if there is a reference in the current context? Surely
> > you're not talking about requiring a vendor extension to get this right?
> > Maybe you're talking about deducing the presence of a reference by looking
> > for a replicated global definition (which is problematic for Ada's
> > describe-an-object-once-only approach)?
>
> If there is a reference to a variable in the current context, there must
> be a declaration.
>
Why must there me a declaration in the current compilation unit for there
to be a reference? That rule might apply to C, but it sure doesn't apply
to Ada. That's the whole point of a with clause.
>
> It's not needed. There is no requirement that you describe globals as
> location lists. As I mentioned previously, this seems to be a rather
> awkward and unrewarding approach to handling globals.
>
> You've identified a problem which (almost) every other debugger solves
> without difficulty, using existing Dwarf 1 or Dwarf 2 (or other
> debug format), without requiring extension.
>
> It looks to me that you have fixated on a particular implementation
> which you are finding to be difficult. Might I suggest that you look
> for a different implementation?
>
Let's not let this degenerate. I'm not fixating on any solution. For
instance, I rather like Jason Merrill's TAG_local_copy suggestion.
The only different implementation I see is to scrap our compilation model,
and start replicating debug information for variables actually declared in
other compilation units. I don't see that as an acceptable solution.
This problem is far too isolated for such a radical approach.
Aside from that, I don't see any solution that can describe this case. To
clarify, I'm talking about globals which have "dead zones" where the main
in-memory copies are inaccurate because local copies have been created and
modified and the changes haven't propagated back to the main in-memory
copies.
--
Todd Allen
Concurrent Computer Corporation