Re: Modifies vs. Replaces

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

> 
> In his several emails, Todd Allen has offered a number of
> scenarios in which a debugger might interpret and mis-interpret
> a location description on a non-defining variable declaration.
> 
> To make my point succinctly, describing such a location description
> as modifying the location description on a defining declaration
> permits a debugger to decide how this modification is to be done.
> 
> My opinion is that in most (perhaps all) cases, augmenting the
> location information of the defining declaration would be the
> appropriate action for a debugger to take.  Todd, on the other hand, 
> would decide that the appropriate modification is to replace the 
> defining declaration's location information with the non-defining 
> location.
> 
> In either case, this represents a modification to the location
> information as described in the proposal.  As far as I can tell,
> the proposal, as written, permits a debugger to act both as I
> would feel is correct and as Todd would have it act.
> 
> Todd has suggested that the non-defining location information
> must replace the location information of the defining declaration.
> This would eliminate the interpretation that the two sets of
> information were to be merged and require me to make the same 
> design decisions in my debugger that he wishes to make in his.
> 
> Modifies permits a range of reasonable interpretations, which 
> include replacement.  The converse is not true.
> 

I think it is unwise to leave the interpretation of this to the debugger.  As
you like to point out, DWARF2 is intended to describe the structure of the
program.  Leaving this ambiguous in the standard leaves the definition of the
structure ambiguous.  If a compiler and debugger resolve the ambiguity in
different ways, they won't interoperate well.  I should think one of the
goals of the standard would be to define the description clearly enough that
compilers and debuggers can interoperate well.

Quite honestly, I would rather lose the ability to describe holes where the
in-memory copy is invalid than to leave this ambiguous.  At least that way
there is no ambiguity, and the ability to describe the holes can be added
back with a vendor extension.  (It would just sadden me that I have to
implement a vendor extension on a brand new feature.)

I would like to hear some other voices on this topic, too.  Does anyone
else even care?  :)

-- 
Todd Allen
Concurrent Computer Corporation