Re: location lists revisited

[todd dot allen at ccur dot com (Todd Allen)]

> > 
> > >
> > > 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.
> > >
> >
> > Ron Brender replied:
> >
> > Perhaps you could clarify what the flaw is -- I sure don't see it.
> >
> 
> Michael Eager replied:
>
> 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.
> 

But this is the traditional way C programs are compiled.  They are
preprocessed and the result, which might look much like what I wrote, is
compiled.  But even if that weren't true, a user is capable of writing source
like what I wrote, and a debugger should endeavor to handle it well.  And
DWARF2 should be supportive.

Where else would you suggest that the declarations of these variables be
described but in the objects in which they're declared?  It's not as though
DWARF2 provides some "global scope" which encloses all of the compilations
and into which arbitrary entities can be placed.  The compilation units are
the roots.

Furthermore, from 3.1:

   A compilation unit typically represents the text and data contributed
   by a single relocatable object file.  It may be derived from several
   source files, including pre-processed "include files".

This seems not only to permit the placement of the declarations of global as
I did, but also to encourage it.

The proposal for duplicate dwarf elimination will allow for more splitting
between headers and C sources, but the declarations still will have to be in
compilation units of some form or other.

I understand that you have particular views of how a debugger should operate
on file scoped variables.  But not everyone agrees with them, and I don't
think DWARF2 should restrict a debugger to them.

>
> Michael Eager wrote:
> 
> 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.
>

When you say the "scope enclosing source3.c", I conclude that you mean a
compilation unit (DW_TAG_compile_unit).  What scope is farther outward than
the scope of a compilation unit?

>
> Michael Eager wrote:
>
> 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.  
> 

I agree that my example is a poor way to describe this.  I merely don't see
any alternative within the confines of DWARF2, as it stands.

You keep asserting that DWARF2 provides a way to describe this latest case
I'm talking about.  Certainly, I can't find a way, and you haven't said
anything to back up your assertion.  Perhaps you can provide a proof of
concept.

>
> Michael Eager wrote:
> 
> 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.  
> 
> ...
>
> 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.
>

Very well.  Despite all the confusion, I think everyone is agreed that using
location lists to describe global variables is a bad idea.  I'm pleased.  I
only explored the approach because Michael seemed to be advocating it.
Certainly, I don't think it's a good idea.  Let's let it die as relates to
global variables with local copies.  (I would still like to understand what
you were getting at regarding scopes, though!)

So, what approach is workable?  At least so far, no one has suggested
anything concrete that stays within the bounds of DWARF2.  So, the best idea
that I see is Jason's DW_TAG_variable/DW_TAG_constant local copy extension.
In the absence of any other concrete approach, I'm willing to write up the
local copy extension as a proposal.

>
> Michael Eager wrote:
> 
> 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.  
> 

This is another assertion that hasn't been backed up.  

In particular, you mentioned GCC.  It was my understanding that GCC provided
no support for location lists.  My exploration of the gcc-20010320 snapshot
backs that up, as does my exploration and testing with the gcc 2.96 (from
gcc-2.96-20000731, apparently) release and gdb 5.00 that came conveniently
with my Linux distribution.  Incidentally, there is a LOC_SECTION defined as
".dwarf_loc" in GCC, but it's never used.  That appears to be as close to
location lists as it gets.

Of course, if I'm wrong about this, I'm sure Jason will set me straight.  I
see his name all over this source.  :)  Jason: If there is loclist support,
could you provide some information on where I can find it?  Thanks.

I did get the impression others had implemented some location list support
from the lengthy location list discussion that Ron sent me.  (Thanks, Ron!)
But since no one has come forward on this issue, perhaps they never dealt
with globals & local copies.

So, which compilers and debuggers support this?  How?  The people who
represent these compilers and debuggers are the people I was hoping would
respond to this in the first place.

-- 
Todd Allen
Concurrent Computer Corporation