This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PROPOSAL: Permit AT_location with AT_declaration



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]