Re: Rewrite of PROPOSAL 001213.1 re default location

[Michael Eager <eager at eagercon dot com>]

Jim Dehnert wrote:
> 
> Michael Eager wrote:
> >
> > No, I don't think so.  It appears that the existing text of the
> > standard would not be applicable in any circumsance, under your
> > interpretation.  I see no reason to accept an interpretation
> > of the existing standard which has no utility.
> 
> I don't think so.  I think the existing standard very clearly says what
> Ron interprets it to say, and I also provided an example earlier today
> of what immediately came to mind when I saw it.  It may well be that
> this isn't what was intended, or what the "best" interpretation is from
> a utility standpoint, but I think that if we want to claim that David's
> interpretation is correct, a wording change is absolutely necessary.

I re-read your email, but I don't see an example.  
 
> But before we blithely do that, consider the following situation.
> A subprogram parameter is passed in a register.  Shortly after entry,
> it is stored to a memory location that is its "home."  However, it
> remains live in the register for a while, until after being used in
> an expression.  Later in the subprogram, there is one region (or more)
> where it is transferred to a register, used and modified there, and
> eventually stored back.
> 
> So we have one range near the entry where the value is live and valid
> simultaneously in both places -- the debugger may read from either and
> must write to both.  Later there are regions where the value is only
> valid in the register, and the memory location may or may not even be
> touchable (i.e. a compiler could have allocated something there
> temporarily -- though admittedly stack memory allocation in the sense
> of coloring and reallocation is something I've often heard suggested,
> but never heard of being implemented).

It appears to me that this is represent able in the location lists as
described in the current standard.  It also appears to me that a 
default location attribute would not be useful in this example, since
you make it clear that the memory location could not be the default.

> So, if we want to use the current overlapping range mechanism to solve
> Ron's issue, we need to clarify (a) which of the locations with
> overlapping ranges contains the currently valid value for access -- I
> would think first is the right answer, and (b) that all of the locations
> with ranges overlapping the current address should be updated.  This (b)
> would make it clear to implementors that actually did reallocate the
> memory while the value was in a register that they must leave a hole
> in the "default" range.  I don't think that's onerous, since I don't
> think it'll be done much if at all, but I think it should be clear.
> Given those "clarifications," I think the current mechanisms should be
> adequate to Ron's purpose, but the current wording isn't.

I certainly can agree that there may be wording changes needed.   If
you recall, I proposed a minor clarification earlier.

Simple questions:

Are there realistic circumstances where the existing mechanism can not
accurately represent the code generated?    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.)

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.

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