Re: location lists revisited

[Michael Eager <eager at eagercon dot com>]

Ron 603-884-2088 wrote:
> 
> Michael Eager wrote:
> >I believe that the descriptions of variable "global" which you present
> >are incorrect.  If you do not use these flawed definitions, then your
> >problem will go away.  If you insist that flawed descriptions are
> >the only ones which you will consider, then there seems to be little
> >to discuss on this matter.
> 
> Perhaps you could clarify what the flaw is -- I sure don't see it.

The first definition of "global" declares that it's lifetime is
limited to source1.c.  This appears to be a file local symbol, 
not a global, although the AT_external is true.  As described,
the variable is explicitly described not to exist in any context
outside of the address range of source1.c.  This appears to be a flaw.

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.

Dwarf 2 is permissive and doesn't completely specify all (or even
many) of the interactions between different TAGs.  In the case
where there is an AT_declaration but no reasonable candidate for
a definition, I think a debugger would issue a diagnostic.  But
that it clearly a Quality of Implementation issue, since the 
Dwarf 2 spec does not require any particular behavior on the 
part of a consumer.

I see nothing which requires the lifetime for the variable to be 
specified as Todd has.  Certainly the lifetime which he describes
is different from what I understand the lifetime for a global
variable to be.  Indeed, it seems to be different from what he
wants it to be.

Using a location list is a poor way to describe a global variable.  
Giving an incorrect lifetime doesn't improve it.  

> >Dwarf describes scoped languages.  Determining the actual variable
> >being referenced in any context is dependent on the scope of the context.
> >No heuristics are needed to determine the context of the reference
> >and there is no ambiguity in resolving the reference.
> 
> Are you suggesting that when stopped at unrelated() that a debugger should
> be unable to display variable global because it is not in scope? It certainly
> would be an error at compiletime to attempt to reference global from anywhere
> in source3.c because there is neither a declaration nor definition visible.

A debugger should be able to display globals.  Some debuggers
also display file local symbols outside the current context.

AT_external says that the variable is visible outside the scope 
of the current compilation unit, i.e., it is visible to the scope
enclosing source3.c and a debugger should have no problem with
finding it.  There is no ambiguity.  All you have to do is proceed 
outward from the scope of source3.c until you find a definition.  

Please do not confuse C language rules with operation of a debugger.
The operations which a debugger can do are not restricted to the
correct statements in a C program, and certainly I have never
suggested that they should be.  Scope in Dwarf is well defined
and is a superset of the scoping rules for C.  

What I suggested, and I think my writing is clear, is that the
variable being referenced can be identified unambiguously by 
following the scope described in Dwarf.  (Had I meant to refer 
to compiler operation, I would have.)

Perhaps I wasn't clear (although I have tried to be) that my 
opinion is that no debugger should attempt to display a variable
whose lifetime is described as not including the current context.  

Given that Todd's example does not appear to correctly describe a 
global variable, I think that he would have a very difficult time.
It appears to me that he should be able to locate the global variable 
following scope rules (although I've gotten the impression that 
he is not able to), but that it's specified lifetime excludes the 
source3.c.  

And, indeed, he has a problem.  The problem, it appears to me,
is based on how he wishes to describe the program.  If he wishes
to describe it in a fashion which is incorrect or misleading to
his debugger, then the problems which he encounters seem to be
of his own creation.

It seems that this code is completely unremarkable and that 
there are a number of Dwarf 2 debuggers which, as far as I 
know, work correctly with this kind of code.  

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