Re: Replicated Dwarf [was Re: location lists]

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

> 
> > AT_abstract_origin is strictly for function references.  While
> > there may be some analogy between inline functions and copies
> > of global variables into local registers, I think that the
> > relationship is pretty distant.  AT_specification might be
> > a closer analogy, although I don't believe that there is
> > any need for this either.
> 
> It isn't necessary for C, which only has unqualified names.  For C++, you
> might refer to the global variable with explicit namespace scope, and you
> would want to make that work in the debugger as well.
> 
> Using AT_specification seems reasonable to me.
> 

This is my rationale for thinking that some connection is necessary,
too.  And DW_AT_specification seems a reasonable candidate for making
the connection.

>
> >>>>> "Todd" == Todd Allen <todd.allen@ccur.com> writes:
> 
> >    One other thing, though: the local copy must not have a DW_AT_name.
> >    If it did, it could interfere with proper visibility code.  The name
> >    might even end up creating ambiguities within the local scope.  It
> >    isn't a problem in a flat namespace, I suppose.  But it is a problem
> >    with hierarchical namespaces.  If you disagree, I'll cope up with some
> >    Ada examples.
> 
> If the local copy has AT_specification, then it should not have AT_name
> anyway.  If it doesn't have AT_specification, it probably should have
> AT_name or it would be useless.
> 

Right.  I'm assuming it has DW_AT_specification.  If it didn't, then items in
namespaces could get pretty confusing.  You could try to replicate namespaces
from the global scope in the local scope, and that might even work for C++.
(I just don't know enough about C++ to say.)  But I can come up with a whole
variety of cases where you'd either have really confusing, and maybe
downright ambiguous, duplications of names within the local scope in Ada,
where the visibility rules are non-trivial.  And by "non-trivial", I really
mean "quite complicated", of course.  :)

-- 
Todd Allen
Concurrent Computer Corporation