000403.2 B N R. Brender Representation Dwarf files over 4Gb

The following text is proposed for addition at the end of the current
Section 7.4, File Constraints, page 66. This text complements (does not
replace) the changes approved in 991102.1.

The proposal uses HTML notation (<i>, </i>)for indicating italics, though
HTML is not the authoring tool in use (I am actually using Word 97 and
Adobe Acrobat).

<i>DWARF Version 2 provides the ability to describe programs that operate in
a 64-bit address space environment. However, it does not make provision for
a DWARF description that itself requires more than 32-bits to represent;
this is because the lengths that describe DWARF sections and values that
are offsets into DWARF sections are all specified to be 32-bits in size.
This revision adds the ability to support a DWARF description that is
greater than 2**32 bytes in size.</i>

A DWARF description is <i>64-bit safe</i> iff all of the lengths that
describe DWARF sections and the offsets that are relative to the beginning
of a DWARF section are represented using 64-bits. To achieve this, all
of the following must be true:

1. The initial length field in those DWARF sections that have a header
   is 96 bits in size (instead of 32), and has two parts:

    - The initial 32-bits have the value 0xFFFFFFFF.
    - The following 64-bits contain the length represented as an unsigned
      64-bit integer.

   This convention also applies to the initial length fields of the CIE
   and FDE structures that occur in the .debug_frame section.

   <i>This representation allows a DWARF consumer to dynamically detect that
   a DWARF section contribution is 64-bit safe and adapt its processing
   accordingly.</i>

   The sections to which this applies are listed in the next bullet.
   (In the case of .debug_line, the header is called the "prologue" and
   the initial length field is named "total_length").

2. Other header fields are 64-bits (instead of 32-bits) as follows:

    section            field position/name      role
    -------            -------------------      ----

    .debug_aranges    3rd                      offset in .debug_info

    .debug_frame/CIE  CIE_id                   CIE distinguished value
                                              (0xffffffffffffffff)

    .debug_frame/FDE  CIE_pointer              offset in .debug_frame

    .debug_info       3rd                      offset in .debug_abbrev

    .debug_line       3rd/prologue_length      length of prologue itself

    .debug_pubnames   3rd                      offset in .debug_info
                      4th                      length of .debug_info
                                              contribution

   <i>The CIE_id field in a CIE structure must be 64 bits because it
   overlays the CIE_pointer in a FDE structure; since this field
   must be accessed to distinguish whether a CIE or FDE is present,
   these two fields must exactly overlay each other (both offset and
   size).


3. Fields and values within the body of DWARF sections use 64-bit
   lengths and offsets as follows:

    section         item                        role
    -------         ----                        ----

    .debug_abbrev   n/a

    .debug_aranges  n/a

    .debug_frame    n/a

    .debug_info     Attributes that use         offset in .debug_info
                    DW_FORM_ref_addr

                    Attributes that use
                    DW_FORM_strp                offset in .debug_str

                    Attributes that use        offset in .debug_line
                    DW_FORM_data4 for          offset in .debug_loc
                    section offsets (use       offset in .debug_macinfo
                    DW_FORM_data8 instead)

                    Attributes that use        offset in .debug_info
                    DW_FORM_ref4 for           (contribution for containing
                    section offsets            unit)
                    (use DW_FORM_ref8 instead)

                    Operators that use         offset in .debug_info of
                    DW_OP_const4u to target    for DW_OP_calli
                    materialize a DIE offset
                    (use DW_OP_const8u
                    instead)

    .debug_line     n/a

    .debug_loc      Operators that use          offset in .debug_info of
                    DW_OP_const4u to           target for DW_OP_calli
                    materialize a DIE offset
                    (use DW_OP_const8u
                    instead)

    .debug_macinfo  n/a

    .debug_pubnames First field of each         offset in .debug_info
                    tuple

    .debug_str      n/a


To be 64-bit safe, all of the above must apply to all of the DWARF sections
of a single compilation.

A DWARF consumer that claims to support the 64-bit safe representation
must support executables in which some objects are 64-bit safe and some
are not, provided that the combination linked correctly (that is, provided
that there are no link-time errors due to truncation/overflow).
(However, an implementation is not required to guarentee detection and
reporting of all such errors.)

<i>It is assumed that DWARF producing compilers will not produce 64-bit
safe DWARF <u>by default</u>. In most cases, the division of even very large
applications into a number of executable and shared objects will suffice
to assure that the DWARF sections within each individual linked object will be
less than 2**32 bytes in size. However, for those cases where needed, the
64-bit safe representation allows the unusual case to be handled as well.
Even in this case, it is expected that only application supplied objects
need be compiled in 64-bit safe mode; separate versions of system supplied
shared executable libraries can still be used.
</i>