Re: location lists revisited

[Jim Dehnert <dehnert at transmeta dot com>]

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.

Jim
-- 
-	    Jim Dehnert		dehnert@transmeta.com
	    (408)919-6984	dehnertj@acm.org