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

[dehnert at baalbek dot engr dot sgi dot com (Jim Dehnert)]

As elaborated below, I am uncomfortable with the idea of separate
semantics for fields depending on whether they are relocated...

> From: brender@gemgrp.zko.dec.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...
> 
> My variant of proposal 3 (email of 12 April, not assigned a number)
> is similar in effect, but formalized differently. 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 (duplicated from my earlier counter proposal):
> 
> 	"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 iff their
> 	data is not relocatable (even in a relocatable object file). They are
> 	included in the lineptr, loclist or macptr class iff their data is
> 	relocatable in a relocatable object file and is used to represent an
> 	offset into a related DWARF section (which section is indicated by
> 	the class name)."
> 
>     Question: is there any case where these forms might be used with a
>     relocation when not representing an offset into a related DWARF
>     section? I think not. (Recall that these forms *do not* get used to
>     represent addresses in the user program -- DW_FORM_addr is used
>     for that.) Even if there is such a case, it is not a serious impediment
>     to this approach -- it would just complicate a bit what is now a nice
>     simple dicotomy:

Yes.  SGI for a while had a C++ implementation which dealt with the
tendency for members to move around in class objects between revisions
by representing their offsets as relocatable constants, resolved at
dynamic link (i.e. program load) time.  It is easy for me to imagine 
similar things, e.g. arising from template instantiation at dynamic
link time.

>       . no associated relocation implies class constant,
>       . has relocation implies some class other than constant (which other
>         class depends on the attribute that uses it).
> 
>     A nice corrollary of this is that the values of the constant class
>     are all compile time constant values (the link-time constant values
>     belong to other classes named something else) -- that will help the
>     presentation for sure!
> 
> Observation: This is a nice conceptual distinction for a producer of DWARF:
> to output/emit a constant you never need an associated relocation;
> to output/emit a lineptr, loclist or macptr you must have an associated
> relocation. Unfortunately, this does not directly help a consumer,
> because a consumer has no way to ask "Is there (or was there) a
> relocation associated with this DW_FORM_data4 or DW_FORM_data8 value?"
> The consumer must use other context (like the using attribute kind)
> to determine the interpretation -- but that is exactly what happens
> today! Some italics text along these lines would likely be helpful.

Although I understand this as a source of descriptive confusion, I
don't think this is a good conceptual distinction.  I think it is
undesirable to define the semantics of a construct in terms of how
it is produced -- this can create even more confusion when an
implementation changes so that it produces more dynamic information,
which nevertheless is a resolved constant by the time the debugger
runs.  I would much rather have us clarify by saying that a "constant"
is a value that does not change once the program begins running, and
that tools which attempt to manipulate the DWARF information prior to
that point should be prepared to deal with relocations.  Whether or not
they need to do so is independent of whether we split the concepts, so
I don't even think it seriously affects the complexity of such tools.

Jim

-	    Jim Dehnert		dehnert@sgi.com
				(650)933-4272