Editorial PROPOSALs re 991102.1 (64-bit safe)

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

RE: Editorial proposals related to 991102.1

Michael: This could be treated as an addendum to 991102.1 but might more
easily be considered as separate proposals...

Dave has convinced me that we pretty much need to go with treating the
CIE/FDE initial length fields as subject to 991102.1, as well as pointing
out a couple things I overlooked. This takes care of Proposal #3 in my
mail of 31 March.

Also, Felix pointed out that the CIE_id distinguished value is actually
specified; in a 64-bit safe description, the distinguished value definitely
should be 0xffffffffffffffff for conistency.

So, here are new versions of Proposals #1 and #2 that reflect that resolution.

--------------------------------------------------------------------------------
Proposal #1:

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>

--------------------------------------------------------------------------------

Proposal #2:

The presentation in #1 (and the DWARF spec generally) would be simplified
and made more regular if:

    1) The "statement program prologue" were renamed "statement program
       header"

    2) The .debug_aranges, .debug_info, and .debug_pubnames headers
       were described in a manner similar to .debug_line (see 6.2.4/
       page 52). In particular, the header fields would have names.

       These are the proposed names.

	.debug_arange	unit_length
			version
			debug_info_length
			address_size

	.debug_info	unit_length
			version
			debug_abbrev_offset
			address_size

	.debug_line	unit_length (instead of total_length)
			version				\
			prologue_length			 \
			minimum_instruction_length	  \
			default_is_stmt			   \
			line_base			    \  unchanged
			line_range			    /
			opcode_base			   /
			standard_opcode_lengths		  /
			include_directories		 /
			file_names			/

	.debug_pubnames	unit_length
			version
			debug_info_offset
			debug_info_length


[[Note: CIE and FDE structures are already described with named fields.
I think it is unnecessary, even undesirable, to rename their "length" fields
to "unit_length" to try to match the above.]]