This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: PROPOSAL: Permit AT_location with AT_declaration
- To: eager at eagercon dot com
- Subject: Re: PROPOSAL: Permit AT_location with AT_declaration
- From: todd dot allen at ccur dot com (Todd Allen)
- Date: Thu, 22 Mar 2001 15:02:12 -0700 (MST)
- Cc: dwarf2 at corp dot sgi dot com (Dwarf 2)
- Reply-To: todd dot allen at ccur dot com (Todd Allen)
This proposal mostly looks good to me.
I do have a couple points, which hopefully everyone will agree are minor.
--------------------------------------------------------------------------------
First of all, thanks for the C++ code samples. I see that C++ has many of
the same visibility issues that are present in Ada, thanks to the ::
qualifier. The first point I'll illustrate with this modified example:
int x;
void myfunc()
{
int x;
// complex sequence of code using ::x
// where a local copy is placed in a register
}
It seems that it would be unwise for a compiler to describe the local copy of
x in myfunc() with a DW_AT_name, because it would conflict with the proper
definition of x in that scope. So, presumably, the DW_AT_name would be
omitted.
That seems to conflict with the text in 2.14:
... A debugging information entry containing no name attribute, or
containing a name attribute whose value consists of a name containing
a single null byte, represents a program entity for which no name was
given in the source.
The proposal's text characterizes this local copy description as a
modification of a (potentially) named object, rather than as a new object.
So, omitting the name on the modifying DIE might be considered invalid DWARF.
Perhaps some text in that new paragraph in item 5:
If the variable entry represents a non-defining declaration,
DW_AT_specification may be used to reference the defining declaration for
the variable. If so, it need not duplicate any information provided by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
referenced entry. If no DW_AT_specification is provided, the defining
^^^^^^^^^^^^^^^^^
declaration may be found as a global definition either in the current
compilation unit or in another compilation with the DW_AT_external
attribute.
--------------------------------------------------------------------------------
In Section 3, it says:
If the object is a non-defining declaration, the location
specified modifies the location specified by the defining
declaration and is only valid for the scope of the current
declaration.
I think it could stand to be clarified that, within the scope of the
non-defining declaration, the DW_AT_location completely overrides the
DW_AT_location of the global, rather than just augmenting it.
This way, both read-only local copies and a read/write local copies can be
described. A read-only local copy would provide a location list that
reiterated the in-memory location from the original global and also provided
the local register location. A read/write local copy would describe only the
location of the local register copy (at least for some range of addresses).
Perhaps just a single change, "modifies" => "replaces", is enough:
If the object is a non-defining declaration, the location
specified replaces the location specified by the defining
^^^^^^^^
declaration and is only valid for the scope of the current
declaration.
--
Todd Allen
Concurrent Computer Corporation