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: location lists revisited


Jim Dehnert wrote:
> 
> Michael Eager wrote:
> >
> > Jim Dehnert wrote:
> > >
> > > Michael Eager wrote:
> > > >
> > > > Ron 603-884-2088 wrote:
> > > >
> > > > The second definition for "global" declares that it's lifetime is
> > > > limited to source2.c.  As far as I can tell, these are not the
> > > > same variables, since they have distinct, non-overlapping lifetimes.
> > > > But this one has the AT_declaration tag, saying that there is
> > > > another definition for this variable, presumably at some enclosing
> > > > scope.  If I were to look for one, I'd find that the only likely
> > > > candidate has a non-overlapping lifetime.  This appears to be a flaw.
> > >
> > > You appear to be confusing "scope" and "lifetime" in this paragraph
> > > (and throughout the message).  Should we read it as meaning "scope"
> > > for both?
> >
> > No, I don't think I'm confusing scope and lifetime.
> >
> > The scope is where the name is known.  As I said, the AT_declaration
> > attribute indicates that there is a definition of the variable in
> > an outer scope.  At least that is my reading of the text.
> >
> > The location lists give the lifetime of the variable, which is
> > clearly different from its scope.  The Dwarf spec explicitly
> > says that there may be addresses which are not covered by the
> > location list.  At these locations, the variable is not available
> > (not live) but it is in scope.
> 
> OK, I understand your distinction now.  In the compiler world, "lifetime"
> is primarily a dynamic (temporal) concept, meaning that the variable has
> a defined value, whether or not it is in scope (e.g. during a call to a
> procedure outside its static scope).  In general, it's not even decidable
> whether a lifetime "includes" a particular address range.  But I can see
> how you might sometimes identify static address ranges in scope but where
> none of the values is live.

I think that we use exactly the same definition for lifetime.  The
lifetime of a variable may be identical to its scope or they may be
(and usually are) distinct.

I'm unclear why you suggest that the lifetime for a variable is not
decidable.  This may be true for unnamed objects, but a variable has
a well defined lifetime.   Certainly a compiler knows when a variable
is live and can describe this in Dwarf 2 (at least, in most cases).  

Whether a variable is live or not in any particular context can be 
determined by following the thread of execution (i.e., walking the
stack) to see if the variable is live in any of the scopes along this
thread.  Are there circumstances when this would not be decidable?

In Dwarf 2, a variable's scope is described by the nesting of the 
DIE defining the variable, while its lifetime is described by the
AT_location and/or a combination of AT_low_pc/AT_high_pc of the 
containing scope with AT_start_scope.

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