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: Rewrite of PROPOSAL 001213.1 re default location



M. Eager writes:
>There are few circumstances I can think of that a compiler
>would generate code where there are two identical instances
>of an object with overlapping lifetimes.   In most cases,
>there is what I might call a primary copy of the variable
>(i.e., the one in memory) and a working copy (the one in
>a register).  Dave's examples represent both of these cases.
>
>One can't reasonably chose to access only the primary during the 
>lifetime of the working copy.  One has to describe all of the 
>places where the object exists if one wishes to provide a debugger 
>with adequate information to be able to correctly display or 
>modify an object's value.

Whether lifetimes overlap or don't, as long as one
ignores the situation where multiple distinct instances
with the same name
exist at the same time (which has nothing to do
with Ron's proposal and is a situation that DWARF2 does
not address) one can already describe everything
using location lists.

(I'll presume I actually understand the issue here...)

Ron is not suggesting that the existing location list
is inadequate.
Ron is suggesting that for what is a real situation
in practice (for compilers and optimizers he is familiar with)
there is a description which is more compact.

Consider the following trivial example.


int v = z                               point A, a springs into life.


	v moves to a register     point B.
		v = y[k];            point C.

	
	v copied back to original loc  point D.

End of life of v, point E.


It's perfectly possible to describe this adequately with
dwarf location lists (in this case it takes 3 loclist entries,
but is most clearly shown as 4 lines).
  A to C, current in original location (only).
  B to C, current in register (ie, in both locations from B to C)
  C to D, current in register (only)
  D to E, current in original location (only).

This however misses the essential claim (lets hope I have this
paraphrase right):
That a variable whose home location is  at address 0x1234,
and which lives for possibly many short periods in a register,
is more compactly represented by 
   a default location plus location lists describing 
   times when the default location is not the current location
than by 
   An explicit complete location list.

This claim based on implementation experience (it is not hypothetical).

The original proposal states that the space saved is significant.

The original proposal removes no capability of location lists.

  Aside:Note that if a vendor uses the proposed facility (as a vendor
	extension) debuggers not knowing about the facility
	are significantly impaired as they would ignore the default
	location. 

davea@sgi.com

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