Re: REVISED Editorial ideas related to 991102.1,000403.2,000410.3 and others

[David Weatherford <david dot weatherford at sun dot com>]

This is much better!  And I think it captures what I'm trying to do with
my proposal 000410.3 (assuming 000410.2 is rejected), so I'll accept it as
an amendment to the wording suggested in 000410.3, up through "two feet
in the water."  We need a separate proposal for the last part (allowing
data1, data2, sdata, and udata to be interpreted as true constants, but
data4 and data8 to be in class loclist for AT_data_member_location).

I'll send out a revised version of 000410.3 shortly.

Dave W.

Ron 603-884-2088 wrote:
> 
> Editorial ideas related to 991102.1, 991108.4, 000403.2, 000410.1, 000410.2,
> 000410.3, 000410.4, probably others...
> 
> See also my earlier proposal in email on this topic dated 1-May.
> 
> Jim and David make good points about not tieing the *explanation* of my
> proposal to whether or not relocations are involved. As I mentioned, however,
> that aspect of the proposal is not essential -- in fact the proposal is
> easily (and, in retrospect, clearly better when) recast in terms of function
> (instead of mechanism).
> 
> So here is a second variation that comes out to the same results, just
> explained a bit differently. "*" in the right margin indicates the changes
> from the 1-May proposal.
> 
> One toe in the water (revised)
> ------------------------------
> 
> The key elements are:
> 
>   - Define lineptr, loclist and macptr as "real" classes (not just aliases).
> 
>   - Specify that DW_FORM_data4 and DW_FORM_data8 belong to more than one
>     class. Heretofore each form belonged to exactly one class. So this is
>     a concept change, but it will not actually affect any bits or any code.
> 
>   - Unlike proposal 3, DW_FORM_data1, DW_FORM_data2, DW_FORM_sdata and
>     DW_FORM_udata belong *only* to class constant (and never to lineptr,
>     loclist or macptr).
> 
>   - Explain the membership of DW_FORM_data4 and DW_FORM_data8 in class
>     constant versus one of lineptr, loclist or macptr something like the
>     following:
> 
>         "The FORMs DW_FORM_data4 and DW_FORM_data8 are included in more than
>         one class of operand. They are members of the constant class if
>         used for the operand of an attribute that allows class constant      *
>         but not class lineptr, loclist or macptr. They are members of        *
>         class lineptr, loclist or macptr if used for the operand of an       *
>         attribute that allows one of those classes.                          *
> 
>         "<i>Because classes lineptr, loclist and macptr share a common       *
>         representation, it is not possible for an attribute to allow an      *
>         operand from more than one of these classes. If an attribute         *
>         allows an operand of both constant and one of lineptr, loclist or    *
>         macptr, then DW_FORM_data4 and DW_FORM_data8 are interpreted as      *
>         members of the latter as appropriate to the attribute (not class     *
>         constant).</i>"
> 
> Two feet in the water (unchanged)
> ---------------------------------
> 
> Once we get the forms and classes properly defined, we can then exploit
> the new vocabulary exactly as proposed by Weatherford -- the result will look
> much like his proposal 2 had been adopted. Better yet, we can fold in the 32-
> vs 64-bit distinction in a clean way, perhaps something like this:
> 
>   o lineptr
> 
>     There are two forms of lineptrs: DW_FORM_data4 which is used always
>     and only in the 32-bit DWARF file format, and DW_FORM_data8 which is
>     used always and only in the 64-bit DWARF file format (see section 7.4).
> 
> Similarly for loclist and macptr.
> 
> [[All the way into the water (unchanged)
> [[--------------------------------------
> [[
> [[This part of the May 1 proposal is also unchanged, but in fact does not
> [[depend on the proposal here. As a result, it is deleted.]]
> 
> A Free Bonus Award (unchanged)
> ------------------------------
> 
> Think back to 000302.1, in which we changed the definition of a "constant"
> class operand for a data member location from being an offset into the
> location list section to being an immediate offset in the object. With
> the above reformulation, we can have it both ways!
> 
> That is, the forms DW_FORM_data1, _data2, _sdata, and _udata (part but
> not all of the possible FORMs of constant) can be defined as immediate offsets
> into the object, while forms DW_FORM_data4 and DW_FORM_data8 can be
> defined as being of class loclist (hence an offset in the .debug_loc section).
> 
> Then in Figure 18, we can have
> 
>     DW_AT_data_member_location  0x38    block, constant, loclist
> 
> This eliminates even the unlikely possibility of forcing an incompatible
> change on some implementation that is currently supporting split lifetimes for
> data members or of denying that possibility in the future. Such an
> implementation must necessarily use DW_FORM_data4 (and in the 64-bit file
> format, would have to use DW_FORM_data8) to refer to the .debug_loc section)
> which leaves the other constant forms to be given some other interpretation.
> 
> Of course, we as DWARF designers have to keep this in mind if and when we
> want to specify any other attribute as allowing both a constant and a
> lineptr, loclist or macptr class operand to make sure the "removal" of the
> DW_FORM_data4 and DW_FORM_data8 forms from the constant class for that
> operand does not pose a problem. (So far DW_AT_data_member_location is the
> only case where this issue arises.) Since DW_FORM_sdata and DW_FORM_udata
> are still available as constants and they can represent any compile time
> constant values that DW_FORM_data4 and DW_FORM_data8 can represent, this
> is unlikely to ever be a problem.
> 
> I am not actually proposing this variation of 000302.1 (yet). I mention it
> because we *could* have specified 000302.1 to have this effect in the
> first place -- but we (I) did not even consider it because the vocabulary and
> concept foundation we had to work with did not make this an obvious
> possibility. I think the reformulation above does provide the clarity and
> foundation we want and need.

-- 
Dave Weatherford                Forte Tools
David.Weatherford@Sun.COM       Sun Microsystems, Inc.
begin:vcard 
n:Weatherford;David
tel;work:650 786-8942
x-mozilla-html:TRUE
org:Sun Microsystems, Inc.;Forte Tools
version:2.1
email;internet:David.Weatherford@Sun.COM
title:<img src="http://xidus.net/~weath/weath-small.gif"><br>Staff Engineer
adr;quoted-printable:;;901 San Antonio Road=0D=0AMS UMPK16-305;Palo Alto;CA;94303;
x-mozilla-cpt:;-8304
fn:David Weatherford
end:vcard