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]

PROPOSAL: Permit AT_location with AT_declaration


PURPOSE

Dwarf 2 provides a means to describe the location(s) for a variable
when it is defined.  If the variable is not defined, but only declared
(using AT_declaration), no means is provided to modify this
description to indicate, for example, that a copy of the variable
may be found at a different location.

This proposal relaxes this restriction.

======

Section 4.1 contains the following as part of the description
of the possible attributes for a TAG_variable, 
DW_TAG_formal_parameter and DW_TAG_constant:

     3. A DW_AT_location attribute, whose value describes the 
	location of a variable or parameter at run-time.

	A data object entry representing a non-defining declaration 
	of the object will not have a location attribute, and 
	will have the DW_AT_declaration attribute.

	In a variable entry representing the definition of a variable 
	(that is, with no DW_AT_declaration attribute) if no 
	location attribute is present, or if the location attribute is
	present but describes a null entry (as described in Section 2.5), 
	the variable is assumed to exist in the source code but not 
	in the executable program (but see number 9, below).

	. . .

     5. If the variable entry represents the defining declaration for
	a C++ static data member of a structure, class or union, the 
	entry has a DW_AT_specification attribute, whose value is a
	reference to the debugging information entry representing the 
	declaration of this data member. The referenced entry will 
	be a child of some class, structure or union type entry.

	Variable entries containing the DW_AT_specification attribute 
	do not need to duplicate information provided by the declaration 
	entry referenced by the specification attribute. In particular, 
	such variable entries do not need to contain attributes for the 
	name or type of the data member whose definition they represent.


Replace item 3 with the following text (and renumber following
items as needed):

     3. A DW_AT_location attribute, whose value describes the 
	location of a variable or parameter at run-time.  

	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.

	If no location attribute is present, or if the location 
	attribute is present but describes a null entry (as described 
	in Section 2.5), the variable is assumed to exist in the 
	source code but not in the executable program (but see 
	number <x>, below).

     4. A DW_AT_declaration attribute, whose value is a flag,
	which indicates that this is a non-defining declaration 
	of the object.   

Insert the following text between the first and second paragraphs 
of 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 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.
	
======

Rationale:

Section 2.12 refers to non-defining declaration and includes the following
example:

	void myfunc()
	{
	   int x;
	   {
	      extern float x;
	      g(x);
	   }
	}

The rationale for non-defining declaration in this section is that a 
a debugger needs to know that 'x' passed to g() is not the same as
the one declared in the enclosing scope.  The apparent intent, since
it isn't explicit, is that the declaration of 'x' is found at global
scope.

A similar example might be the following:

	void myfunc()
	{
	   int x;
	   {
	      extern float x;
	      // complex sequence of code using x
	      // where a local copy is placed in a register	
	      g(x);
	   }
	}

In this case, the debugger needs to know not only that 'x' in
the code is the global, but also where it's value may be found.
This proposal permits a non-defining declaration to provide this.

(While this example is parallel to the example in Section 2.12,
the same situation holds in the case where 'x' is declared to be
extern and there is no other declaration of 'x'.)

In the following example, an AT_specification would provide the 
location of the defining declaration:

	namespace myspace {
	    float x;
	}
	void myfunc()
	{
	   int x;
	   {
	      using myspace::x;
	      // complex sequence of code using x
	      // where a local copy is placed in a register	
	      g(x);
	   }
	}

In this case, there would appear to be no way to locate the 
defining declaration without an AT_specification attribute.

======

Discussion:

The reason for the prohibition in the current specification
on having a location specified with a non-defining declaration 
is unknown.  Conjecture might be that for the example given in 
Section 2.12 no location information is necessary, and this
was extrapolated to all cases.

For the example given, this proposal permits the debugger to 
be provided additional location information for a variable which
is defined in another compilation unit.  

Consider the following C++ case:

	static float x;
	void myfunc()
	{
	   int x;
	   {
	       g(::x);
	   }
	}

In this case, a non-defining declaration is needed since the 'x'
passed to g() is the one at file scope, but it need not contain 
location information.  Any location information may be contained 
in the defining declaration.  

While there is no need for a compiler to generate location 
information in non-defining declarations for variables defined
within the current compilation unit, nothing in the specification
would prevent this.

Since debuggers currently handle both non-defining declarations
and locations on defining declarations, this relaxation of would 
seem to require only relatively minor modifications.

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


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