This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: Modifies vs. Replaces
- To: todd dot allen at ccur dot com
- Subject: Re: Modifies vs. Replaces
- From: Michael Eager <eager at eagercon dot com>
- Date: Thu, 29 Mar 2001 20:59:42 -0800
- CC: brender at gemevn dot zko dot dec dot com, DWARF2 at corp dot sgi dot com
- References: <200103292046.f2TKkSR15284@toad.ccur.com>
- Reply-To: Michael Eager <eager at eagercon dot com>
Todd Allen wrote:
>
> >
> > Todd Allen wrote:
> > >
> > > But if the group decides to go with the "augmentation" plan (and Jim's
> > > "primary" concept in that case, hopefully), then it seems we'd need to
> > > describe how an "effective location list" is produced by:
> > >
> > > concatenating the location list from the local copy/copies to the location
> > > list from the global (or perhaps in the opposite order, depending on how
> > > Jim's primary is determined), and also how a location description is
> > > interpreted as a location list with an address range which covers the
> > > whole program for this purpose.
> >
> > I don't think that there are any places where the Dwarf 2 prescribes
> > a particular implementation. You seem to be specifying how a consumer
> > should process location information.
> >
> > This seems both unnecessary and over specified. There is existing text
> > which describes the meaning of location lists with overlapping address
> > ranges. I can't see a need for any additional description.
> >
>
> There's no text anywhere that describes how to interpret the location lists
> and/or location descriptions from multiple DIE's which have been mixed
> together to produce an effective location list by this
> modifies/augments/concatenates wording. My text attempts to describe what
> that means.
>
> Mixing two location lists is pretty straightforward, and describing them as
> being concatenated (presumably with the end-of-list operation of the first
> removed) seems pretty clear. Then you only need a little glue to clarify how
> a location description is interpreted as a location list so that it can be
> mixed in, too.
>
> Obviously, a consumer can implement this conceptual mixing of location
> information any way it pleases.
What I seem not to be able to convey is that you are describing an
implementation. Rather than stating what the information represents,
you give an algorithm which the consumer is to follow.
I'm of the opinion that the text in 2.4.5 is adequate. If additional
text is desired, then perhaps a small change to the text of my proposal
would be reasonable (second paragraph under item 3):
Change
If the object is a non-defining declaration, the location
specified modifies the location specified by the defining
declaration and is only valid for the scope of the current
declaration.
to
If the object is a non-defining declaration, the location(s)
specified provides additional location(s) for the object in
addition to those specified by the defining declaration and
is only valid for the scope of the current declaration.
--
Michael Eager Eager Consulting eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077