Re: Replicated Dwarf [was Re: location lists]

[Michael Eager <eager at eagercon dot com>]

Jason Merrill wrote:
> 
> I just don't think that location lists for the global or up-referenced
> variable are a clean way to deal with this issue, even apart from the
> question of duplication; it seems to me that the data layout within a
> function should be described within that function DIE only, and should not
> impact enclosing scopes.  I think the duplication you folks have been
> talking about is just a consequence of the design problem.
> 
> It seems to me that optimizing access to external variables by making local
> copies is precisely analogous to optimizing calls to external functions by
> expanding them inline, and TAG_local_copy analogous to TAG_inlined_subroutine.
> 
> However, I think that we don't actually need to use a new tag; we should be
> able to just use TAG_variable.  If the description of foo.p.q includes a
> TAG_variable named var with the appropriate location, the user of the
> debugger should get the right results.  If we want to know what the
> original variable was, we could add AT_abstract_origin.

An AT_declaration is used for non-defining declarations of a 
variable.  The current specification prohibits location lists
for these declarations, for reasons which are not clear.  
A reasonable interpretation for a location list for a non-
defining declaration would be that this list represents 
a qualification of the variable for the specified scope,
e.g., to indicate that it is in a register.  

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.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077