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
- Subject: Re: location lists
- From: todd dot allen at ccur dot com (Todd Allen)
- Date: Thu, 8 Mar 2001 08:50:08 -0700 (MST)
- Cc: dwarf2 at corp dot sgi dot com (dwarf2)
- Reply-To: todd dot allen at ccur dot com (Todd Allen)
>
> I don't think that it is necessary to describe all globals in every
> compilation unit, and, at least in C or C++, this isn't possible,
> since each compilation unit is unaware of the globals defined in
> other compilation units. Also, it is not uncommon for different
> shared libraries to contain global symbols which have the same
> name but different scopes (i.e., restricted to the library).
>
> Dwarf is intended to describe the structure of a program. It is
> not designed to be the internal format for a debugger's symbol table.
> I'm at a loss why one would want to use location lists to describe
> globals. I guess you can do this, but it seems awkward, inefficient,
> and clearly unnecessary. Your assumption that this is the only
> solution seems to be the cause of your difficulty.
>
> This is a quality of implementation issue. When the user of a
> debugger refers to a symbol, the debugger needs to determine
> what symbol is being referenced. If there is a reference to it
> in the current context (whatever that may mean to the debugger),
> then that reference should be used. This might be a location
> list entry which indicates that the symbol is located in a
> register.
>
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)?
I agree that this is a quality of implementation issue, but I don't see
how DWARF is enabling a good quality implementation.
BTW, have you read the DW_TAG_local_copy idea that's floating around? It
seems to solve this my describing globals as simple location descriptions,
and then augmenting that with local information in any compilation that
has special case locations for the global. I believe it would provide all
the descriptive functionality that's needed.
--
Todd Allen
Concurrent Computer Corporation