Replicated Dwarf [was Re: location lists]

[Michael Eager <eager at eagercon dot com>]

Todd --

You raise two issues, one technical, one philosophical.  I'll respond in
two emails.  This first one about your technical comments.

Todd Allen wrote:
> 
>    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

I, like many other, do not have adequate understanding of Ada to give
this discussion the review it deserves.

That said, it seems to me from the above discussion that it is possible 
to describe the Ada features you discuss within the current specification 
of Dwarf, although you may not like the way this is done.  

My impression, and again, I feel I have too little understanding of Ada
to offer examples, is that there are other ways to describe the structure
of an Ada program without the problems you describe above.  There are
similarities in Ada and C++ which may be used to your advantage.

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