PROPOSAL(2): New FORMs DW_AT_linep, locp, macp

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

The current situation surrounding the usage of "constant"-class
forms for pointers into other sections is somewhat confusing
and inconsistent.  We have four sections that contain data that
DIEs wind up pointing to via various attributes:

	Section		Attribute(s)	FORM classes

	.debug_line	stmt_list	data{4,8}
	.debug_loc	location, etc.	data{4,8}
	.debug_macinfo	macro_info	data{4,8}
	.debug_str	name, etc.	strp

Why should there be a special class for pointers into .debug_str and
not for the other three?  Adding three new FORMs will simplify the
descriptions in section 7.5.4 and Figure 17, as well as ameliorate
the confusion surrounding "constant"-class forms.

PROPOSAL

Remove the two paragraphs added to 7.5.4 by my previous proposal,
which explain the usage of class constant for pointers into .debug_loc
etc., and add, instead, three new FORM classes.  Add to the list in
Section 7.5.4 (between "flag" and "reference", keeping it alphabetical):


	lineptr (DW_AT_linep)

		This is an offset into the .debug_line section.  It
		consists of a 4-byte value which is the offset from
		the beginning of the .debug_line section to the first
		byte of the data making up the statement list for the
		compilation unit.  It is relocatable in a relocatable
		object file, and relocated in an executable or shared
		object.

	loclist (DW_AT_locp)

		This is an offset into the .debug_loc section.  It
		consists of a 4-byte value which is the offset from
		the beginning of the .debug_loc section to the first
		byte of the data making up the location list for the
		object in question.  It is relocatable in a relocatable
		object file, and relocated in an executable or shared
		object.

	macptr (DW_AT_macp)

		This is an offset into the .debug_macinfo section.  It
		consists of a 4-byte value which is the offset from
		the beginning of the .debug_macinfo section to the first
		byte of the data making up the macro information for the
		compilation unit.  It is relocatable in a relocatable
		object file, and relocated in an executable or shared
		object.

NOTE: The sizes of these (and strp) in 64-bit safe DWARF are addressed in
another proposal (number 4) to follow.

Add (in italics) the following paragraph after the above list:

	<i> For backward compatibility, a DWARF consumer should be
	prepared to accept FORMs of class "constant" in lieu of
	DW_AT_linep, DW_AT_locp, and DW_AT_macp. </i>


Modify Figure 17 (Attribute Encodings) as follows:

    DW_AT_location                      block, loclist
    DW_AT_stmt_list			lineptr
    DW_AT_string_length                 block, loclist
    DW_AT_return_addr                   block, loclist
    DW_AT_data_member_location          block, loclist
    DW_AT_frame_base                    block, loclist
    DW_AT_macro_info			macptr
    DW_AT_static_link                   block, loclist
    DW_AT_use_location                  block, loclist
    DW_AT_vtable_elem_location          block, loclist

 
NOTE: I intentionally omitted DW_AT_segment from the list above; there
I believe "constant" was intended to be an actual constant value.

Add to Figure 18 (Attribute form encodings):

	DW_FORM_linep	0x17
	DW_FORM_locp	0x18
	DW_FORM_macp	0x19

DISCUSSION

Yes, this is an incompatible change.  For that reason alone, I expect
it to be rejected.  Surprise me.  :-)  My next email will contain a
weaker version (proposal 3), just in case.

-- 
Dave Weatherford                Forte Tools
David.Weatherford@Sun.COM       Sun Microsystems, Inc.