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.

This proposal would add three new constant forms for addressing the line table, location lists, and macros. It is an incompatible change.  It was felt that the benefits of this change did not warrant making a new, incompatible version of Dwarf 2.

Withdrawn by proposer.