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>