This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: Replicated Dwarf [was Re: location lists]
- To: todd dot allen at ccur dot com (Todd Allen)
- Subject: Re: Replicated Dwarf [was Re: location lists]
- From: Jason Merrill <jason at redhat dot com>
- Date: 21 Mar 2001 01:58:55 +0000
- Cc: eager at eagercon dot com, dwarf2 at corp dot sgi dot com (dwarf2)
- References: <200103201648.f2KGmEn03473@toad.ccur.com>
- Reply-To: Jason Merrill <jason at redhat dot com>
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.
Jason