Re: PROPOSAL: Permit AT_location with AT_declaration

[Michael Eager <eager at eagercon dot com>]

Todd Allen wrote:
> 
> 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.

There is no need for a non-defining declaration in this example.

This seems to be a case which is addressed by current debuggers 
without any changes to the Dwarf 2 specification.

If the first declaration were "extern int x;", then a non-defining
declaration would be needed.  And it should have a name, like any
other variable declaration.  Should the debugger wish to reference 
'x' in this context, then it would need to distinguish whether this
referred to the local or global.  This would seem straightforward.

> 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.

Please read the second paragraph under item 5 from the specification, 
as quoted in the proposal.


> 
> --------------------------------------------------------------------------------
> 
> 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.

No, modifies is correct; replaces is incorrect.

For example, if you had code which looked like the following:

	void myfunc() 
	{
	   extern int x;
	   { 
	      // use of x, where a copy is kept in a register
	   }
	   . . .	// x is only in memory here
	}

If one uses location lists, as you suggest, I guess that one could 
add an entry for the memory location.  But this would be (a) 
redundant and unnecessary since it only repeats the location which
is given in the definition, and (b) require the use of location 
lists where they would not otherwise be required.  

Changing "modifies" to "requires" would prohibit the use of 
location expressions to describe locations in non-defining 
declarations.

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