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 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


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