Re: location lists

[Michael Eager <eager at eagercon dot com>]

Todd Allen wrote:

>    Well, the global in-memory copy described in another compilation unit may
>    still have relevance.  Consider the case where there's a local copy of the
>    variable that *isn't* modified.  In that case, there are two equally
>    viable locations for the global variable.  Then say the user of the
>    debugger instructs it to modify the global variable while in that code.
>    You can't modify just the local copy and rely on the local code to update
>    the global copy with the local one, because the local code knows that it
>    never modifies the local one.  (Obviously, it wasn't expecting the
>    debugger to get involved.)  So, the debugger needs to update *both*
>    locations for the modification to affect the execution properly.

Use loc lists with overlapping ranges.

This is not a problem specific to Ada or global variables.  It is a common
problem when debugging even minimally optimized code, for example, when 
a variable is loaded into a register for the duration of a loop.  

>    It seems that a location list would solve this.  I worried about this for
>    a bit, because I went back to the inability to describe locations outside
>    the current compilation unit for the global.  But then I realized that it
>    wasn't necessary: as long as the location list covers all the PC ranges
>    for which this local copy is in scope, that's all it needs to do.

Exactly.

>    But there's a more serious problem with this solution.  In Ada, there
>    really aren't any objects at the outermost scope; they're all nested
>    within some construct (a package, subroutine, or other entity, which
>    collectively are called units).  In order for a debugger to be able to
>    cope with fully-specified object names
>    (e.g. outermostpackage.nestedpackage.object), I have to describe enough of
>    the foreign hierarchy to get the object nested in the right place.  But
>    having done that, now those units in the foreign hierarchy have been
>    described in the current compilation unit, and they will be found by the
>    visibility code instead of their original foreign counterparts all of the
>    time, not just when looking up the global with the local copy.  I suppose
>    even that could be worked around by making the debugger descend through a
>    local hierarchy if there is one, and then, if it didn't find what it was
>    looking for, through the original foreign hierarchy.

Yes, this is the way that other debuggers work.

The problem with Ada is not unique.  Many debuggers permit the user
to inquire where file local symbols are defined, which is similar.
C++ namespaces are similar to Ada packages.  A C++ debugger would 
handle similar issues when there were references to foo::fun() and goo::fun().

>    Aside: .pubnames is practically useless for Ada.  You have to do
>           hierarchical searches to follow proper Ada semantic visibility
>           rules, so .pubnames really can only describe outermost (library)
>           units, no more.
> 
>    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.   

Arguments that a debugger needs to search its symbol table correctly
to find the right symbol definition will get complete agreement from
everyone.  This seems to be a Quality of Implementation issue, not one
about description in Dwarf.

>    So, yes, this solution seems to work without requiring any new DWARF,
>    although I'm still not 100% confident that there aren't any other issues
>    with it.  (The rate it which I'm thinking up issues about this is still
>    too high for me to have that kind of confidence.)
> 
>    But this solution comes at a cost:
> 
>       1) It will cause the DWARF to be considerably larger, requiring
>          hierarchical replication.
>       2) It definitely will entail more work in the compiler to save all
>          information about each hierarchy that might need to be replicated in
>          other compilation units.
>       3) I suspect that it will even entail a lot of work to support it in a
>          debugger.

All solutions have a cost.  We obviously don't agree on the effort
or scope.

>    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. 

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