Re: location lists

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

   Sorry about taking so long to respond here.  Work interfered.  :)

> > 
> >    There's another issue, too.  Even ignoring entities nested within these
> >    replicated hierarchical units, the hierarchical units themselves will have
> >    attributes which will need to be replicated.  For the case of uplevel
> >    referenced variables with local copies, that means that foreign
> >    subroutines have to be replicated in the local compilation unit, along
> >    with all their attributes.  In order for that to work, additional ELF
> >    symbols original foreign subroutine have to be made extern, so that they
> >    can be referenced potentially by from any other compilation units that
> >    need to replicate the subroutine and its attributes in order for it to
> >    contain an uplevel referenced variable.  And while I'm replicating the
> >    description of a subroutine, is it necessary to replicate its formal
> >    parameters, too?  Assuming the same approach I described in the last
> >    section where there's a 2-pass symbol table lookup for variables, then I
> >    don't need to replicate the formals just to be able to look them up from
> >    within the subroutine.  But what about the ability to call the subroutine?
> >    I need to know the formals for that, too.  (Well, I do in Ada, at least;
> >    maybe other languages are looser.)  So, either they have to be replicated
> >    along with the subroutine, or the debugger's visibility code has to be
> >    clever enough to realize that it's looking up a subroutine and to ignore
> >    one that it found in the 1st pass of a symbol table lookup and use the one
> >    in the more-global symbol table lookup if the former has no formal
> >    parameters, and the latter does.  Of course, it still has to pay attention
> >    to the subroutine found in the 1st pass when trying to lookup something
> >    nested within it.
> 
> I'm not following this at all.  
> 
> How is this different from C or C++ where you need to know the types
> of the arguments to call a function?
> 
> I don't follow why the description of an external routine would need
> to be replicated.  If you need to refer to other Dwarf descriptions,
> then use DW_form_ref.   
> 

   Here's a concrete example of a case where I would need to replicate a
   subroutine in your suggested approach.  Each of these units is a 
   distinct compilation unit in a distinct object.

      package foo is
         procedure p;
      end foo;

      package body foo is
         procedure p is separate;
      end foo;

      separate(foo)
      procedure p is separate;
         var : integer;

         procedure q is separate;
      begin
         ...
         q;
         ...
      end p;

      separate(foo.p)
      procedure q is
      begin
         loop
            ...
            var := var + 1;
            ...
         end loop;
      end q;

   In this case, within foo.p.q, it is useful to make a copy of var, because
   it's used frequently.  So, in the object for foo.p.q, the DWARF needs to
   contain a duplicate description of foo.p.var.  To do that, it needs to
   make a duplicate description of foo.p, so that q will be within the right
   scope.  But foo.p is a subroutine, and describing subroutines is somewhat
   more complex than packages.  For instance, it will have to re-describe all
   the static link locations (when normally, only a canonical one would be
   saved).  Also, it will need to reference labels in the other object which
   normally wouldn't even have been extern (e.g. the label for
   DW_AT_high_pc).

   Then there's the issue of formal parameters.  There are two approaches:

      1) when calling foo.p from inside the foo.p.q in the debugger, the 
         debugger must know to ignore the duplicate foo.p, presumably just 
         because it has no formal parameters, and go look for the real 
         description of foo.p

         -or-

      2) the DWARF must duplicate not only foo.p, but also its formal 
         parameters

> 
> >    Is a nice simple extension so bad, compared to this?
> 
> I believe that I heard this same argument when I was on the C++ standards
> committee.  Unneeded extensions are bad, since they require everyone to
> implement them, even in the cases when they are unlikely to be used. 
> 

   Actually, I disagree about everyone needing to implement this extension.
   Whether or not they do is a quality of implementation issue, itself.

   If a debugger fails to understand a DW_TAG_local_copy, then the debugger
   behaves as though the compiler failed to describe local copies of any
   global or uplevel-referenced variables.  I've found no compiler which
   implemented location lists at all in DWARF (except for one research
   project which didn't address global or uplevel-referenced variables).  So,
   this is the current state of affairs.  Apparently, no one perceives this
   is all that bad.

   But my real reason for disliking the duplication-of-scopes approach is
   that it involves duplication.  Duplication is bad.  DWARF debug
   information already is outrageously huge.  It seems unwise to devise a
   solution that requires it to be even larger.  The DW_TAG_local_copy
   solution has the advantage of being terse.

-- 
Todd Allen
Concurrent Computer Corporation