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

[brender at gemgrp dot zko dot dec dot com (Ron 603-884-2088)]

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.