This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: Rewrite of PROPOSAL 001213.1 re default location
- To: Michael Eager <eager at eagercon dot com>
- Subject: Re: Rewrite of PROPOSAL 001213.1 re default location
- From: Jim Dehnert <dehnert at transmeta dot com>
- Date: Fri, 12 Jan 2001 15:53:28 -0800
- CC: DAVID WEATHERFORD <david dot weatherford at sun dot com>, Ron 603-884-2088 <brender at gemgrp dot zko dot dec dot com>, DWARF2 at corp dot sgi dot com
- References: <01011113155004@gemgrp.zko.dec.com> <3A5F53C2.35D18CE4@sun.com> <3A5F5B21.965269C0@eagercon.com>
- Reply-To: Jim Dehnert <dehnert at transmeta dot com>
Michael Eager wrote:
>
> I can't understand why Ron's proposal makes no comment on the text in
> the standard which refers to overlapping address ranges, even when this
> was specifically mentioned at the last committee meeting.
>
> Here the relevant text from the draft standard (Draft 5, Section 2.5.4, page 25):
>
> Address ranges may overlap. When they do, they describe a
> situation in which an object exists simultaneously in more than
> one place. If all of the address ranges in a given location list
> do not collectively cover the entire range over which the object
> in question is defined, it is assumed that the object is not
> available for the portion of the range that is not covered.
I didn't either, but now I do. The overlapping range as described above
is
appropriate for a case where a value (like an incoming parameter) has
been
stored into memory but not yet replaced in the register -- the
overlapping
ranges are both valid. Ron is looking to deal with the case where
there's
a variable that normally lives in memory, but within various ranges, the
compiler maps it to a register _instead_ (not in addition), and updates
it
there instead of in memory, perhaps eventually storing it back.
Obviously, one could make a minor redefinition of the overlapping ranges
interpretation to deal with the latter problem (i.e. the first valid one
encountered is to be used), but that's not what it says now.
Jim