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


Todd Allen wrote:
> 
> Your comments make it clear that you didn't understand the point.  The DWARF2
> is lying to the debugger about the locations of variables, causing the
> debugger to believe that it's free to follow the user's request and make a
> safe change to the program, when in fact, it is not.  The fault would be in
> DWARF2 in that case.

I understand your point.  But none of the examples which you have
given demonstrate this point.  

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

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

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


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