Re: Rewrite of PROPOSAL 001213.1 re default location

[Michael Eager <eager at eagercon dot com>]

Jim Dehnert wrote:
> 
> Michael Eager wrote:
> > I certainly can agree that there may be wording changes needed.   If
> > you recall, I proposed a minor clarification earlier.
> 
> Sorry, I don't, and can't find it.  What was it?

This is what I wrote on Jan 12:

   The only ambiguity that I see is what should a Dwarf consumer do when
   an object exists in more than one place.  It appears that the consumer
   would have the choice to use any copy of the object.  

   It would appear that resolving this ambiguity would resolve this issue.

   Insert the following after the second sentence in the above paragraph:

        "When address ranges overlap, the specification for the latest 
        encompassing address range should be used to reference the object."

   (I had thought to indicate "most restrictive address range", but this has 
   it's own set of ambiguities.  There may be a better word than "latest".)

I'm no longer sure that this is appropriate, given the comments which Dave
has made.

> > Simple questions:
> >
> > Are there realistic circumstances where the existing mechanism can not
> > accurately represent the code generated?
> 
> No.
> 
> > Are there realistic examples
> > where the existing mechanism generates debugging information which is
> > significantly larger than the proposed mechanism?   (You may recall
> > me asking essentially the same questions about several past proposals.)
> 
> Yes, if you interpret the current wording to mean that overlapping ranges
> mean that the value is valid in any of the locations described.  And I
> believe that's the obvious way to interpret it, whatever the original
> intent.  However, I think a modification of the current wording to
> specify that one location in an overlapping range is the primary valid
> one, would also be an adequate solution.
> > The proposal did not address either of these points.  I'm very reluctant
> > to endorse changes to the Dwarf standard unless these questions can be
> > answered affirmatively.
> 
> Your first question has not previously required an affirmative answer for
> changes, if they provide significant compaction benefits.  Why the change?

I don't think that there is any change.  I believe that if a source or
code feature cannot be represented in Dwarf 2, there is a strong argument
for adding it to the standard (providing it can be well defined).  If there
are significant size reductions which can be obtained by adding a different
mechanism, then these are valuable.  

On the other hand, if size reductions are small or apply in only limited
circumstances, then I think that there is limited value to making the change
to the standard.  

In designing a debugging format such as Dwarf 2, there may be a number of 
different implementation choices.  In a number of cases, we have entertained 
proposals which do not meet either of these criteria (additional feature 
representation or significantly reduced size), but only represent a different
choice from the current implementation.  To me, these proposals have 
little merit.

I believe that I have been consistent in this regard.   I did not mean to
imply that both questions must be answered affirmatively.

===

With the current proposal, there appear to be multiple answers to my
two questions:

1)  Can the feature be represented with the current standard?

    It appears that general opinion is that it can, although it is not
    clear to me that Ron would agree based on his email of Jan 12.

2)  Is there a significant size reduction?

    There's been a claim that the size reduction is significant, although
    little seems to have been said to illustrate this.   There is also 
    the claim that the same benefit can be obtained by a wording change.

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