This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PROPOSAL: Permit AT_location with AT_declaration


> > 
> > Let me try to distill our fundamental viewpoints down here.  I may miss the
> > mark on yours, of course.  Correct it if I do.
> > 
> > It seems to me that you think the "augmentation" interpretation should be
> > retained because you can't think of any reason why a compiler would ever want
> > to describe a place where the in-memory location was invalid, nor would a
> > debugger ever need to know such information because it would always have some
> > other basis for choosing from among multiple locations that would arrive at
> > the correct choice.  As such, the reduction in size by not requiring location
> > lists is more important than the loss of the seemingly little-used additional
> > descriptive power.  Is that accurate?
> 
> Three points:  (1) there is both a reduction in size and a reduction
> in complexity.  (2) the hypothetical situations which require whatever
> additional descriptive power you claim appear to be unreasonable and
> contrived.  (3) the claim for additional descriptive power is not
> apparent.
> 
> > I think that the "replaces" interpretation is better because I don't think we
> > should try to second-guess whether or not a compiler would want to describe
> > "holes" where the in-memory location is invalid, nor whether a debugger would
> > be able to deduce a location from among several locations described as valid
> > (but where only one actually is).  Instead, I think we should attempt to
> > provide a more general descriptive mechanism that is capable of describing
> > all cases.  I recognize that this would result in the need for location lists
> > in cases where your original proposal would not, and consider that less
> > important.
> 
> Indeed, you have the point.  Your modification would require that
> every non-defining declarations include a location list and that this
> location list have an external reference (or multiple references)
> to the memory location of the global.  This duplicates the information
> provided in the defining definition, which appears unnecessary.
> 

I never intended for every non-defining declaration to have a location list.
If they did, there would be no point to the change.  The intention is that
any read/write non-defining local copy declaration would require only a
location description, because it would explicitly intend to exclude the
in-memory copy.  

Of course, if a local copy had a limited lifetime, it would still need a
location list to indicate the lifetime, but that's true with either your
original proposal or my modification.  I think it's outside the scope of this
conversion, but I include it for completeness.

>
> As far as I've seen, the exceptions to this which you have offered 
> seem to be very strained and hypothetical.
> 

Well, at least I understand your viewpoint properly.  As for understanding
mine, I've tried explaining, and then providing many examples of the loss of
descriptive power.  If you still don't understand it, I can't think of what
else to try to get the point across.  If you do understand the additional
descriptive power, but merely believe that it has little value, well, that's
better.  But it still seems clear that I can't convince you, so I think I'm
done talking about it for now.

Either way, I suggest we step back for a while and let others comment.

-- 
Todd Allen
Concurrent Computer Corporation


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]