Re: Rewrite of PROPOSAL 001213.1 re default location

[Jim Dehnert <dehnert at transmeta dot com>]

Michael Eager wrote:
> 
> 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.

So I must not be getting my point across.  I'll try again.  First, noone
has ever claimed that there is something not representable by location
lists.  The _only_ question is how many location list entries are required,
with the specific concern being variables that are sometimes in memory and
sometimes in registers.  There have been two suggestions:

a) Add a default location, to be used only when none of the location list
   entries apply (from Ron).  In a case where there are n ranges with the
   variable in a register, separated and surrounded by n+1 ranges with it
   in memory, exclusive in both cases, this allows us to use n location
   list entries and one default location instead of 2n+1 location list
   entries to describe the ranges disjointly.  The reason Ron thought he
   needed this instead of one all-inclusive memory entry is that the current
   standard says that overlapping ranges represent multiple simultaneously
   valid locations for the variable, and it isn't generally valid in memory
   after being updated in the register.  (The case described is intended to
   be an example, and it corresponds to what SGI's compilers do and from
   what Ron says, what Compaq's do as well.)

b) Use overlapping ranges as presently specified, with the interpretation
   that _one_ of them is the current "master" copy (from Dave W.).  This
   again allows one all-inclusive range (this time a location list entry
   instead of a separate default), but requires that we clarify which of
   the overlapping entries contains the valid value (the one in the
   register in the (a) example) for the debugger to reference.  This is
   why I claimed that we absolutely have to change the wording if we keep
   only the existing mechanism (and hope to solve Ron's problem) -- the
   overlapping locations _don't_ simultaneously contain a valid value, as
   I believe is implied by the current language, even if some people don't
   believe that was intended.

   My associated point (below), which may have confused you, is that we
   need to be particularly careful when clarifying, because sometimes two
   copies may actually be live, e.g. parameters shortly after procedure
   entry (that was an example too), so specifying which copy the debugger
   should reference in an overlapping range does not mean that it should
   only update that copy if it updates.  It's important to make that clear
   both for debugger implementors and for compiler implementors who might
   contemplate re-allocating the memory space during the interval when the
   variable is in a register.

   Before continuing, I prefer (b), presuming a careful rewording of the
   current draft.  What follows is not argument for (a), but an attempt
   to clarify it so the choice is based on reasonable interpretations.

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

No one has claimed otherwise.

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

That depends, actually.  The primary difference between the default attribute
and the all-inclusive range in a location list is that the default attribute
is not presumed to apply at all to locations appearing in loclist entries.
So it works fine for holes in the memory-accessible range (i.e. where
something else is there and the debugger may not update), by simply providing
a loclist entry that overrides it, whereas the all-inclusive range may not
include that subrange.  But that isn't a big advantage, as long as the
treatment is clear.

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

Sorry, I don't, and can't find it.  What was it?

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

Jim

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