Issue 250422.1: FORMs Implicit Const and Indirect

Author:	David Anderson
Champion:	David Anderson
Date submitted:	2025-04-22
Date revised:
Date closed:
Type:	Improvement
Status:	Open
DWARF version:	6

BACKGROUND

In issue 221114.1 DW_FORM_implicit_const and DW_FORM_indirect we corrected a mistake in DWARF5 that, in very limited circumstances, forced compilers to emit an abbrev section that could not be scanned (to find abbrev codes) without chaos ensuing in the reader.

This never caused problems in real life, but it was a mistake in DWARF5.

PROPOSAL

Simplify section 7.5.3 by restricting DW_FORM_implicit_const and DW_FORM_indirect to useful cases, avoiding space-wasting complications.

The simplification is quite small as text (negligible) but avoids having to document implicit-const in .debug_info.

As part of this, we rearrange the references from DW_FORM_implicit_const, DW_FORM_addrx_offset, and DW_FORM_indirect to be listed in the order DW_FORM_addrx_offset, DW_FORM_implicit_const, and DW_FORM_indirect.

DW_FORM_addrx_offset is not part of the proposal so we keep it separate (just preceding) DW_FORM_implicit_const and DW_FORM_indirect.

CHANGES TO SECTION 7.5.3 (DWARF6 April 18,2025 version, pages 223,224)

Revise the FORM ordering

Finally, the child encoding is followed by a series of attribute specifications. Each attribute specification consists of two parts (except for DW_FORM_addrx_offset, DW_FORM_implicit_const, and DW_FORM_indirect, see below). The first part is an unsigned LEB128 number representing the attribute’s name. The second part is an unsigned LEB128 number representing the attribute’s form. The series of attribute specifications ends with an entry containing 0 for the name and 0 for the form.

Describe this first (arbitrarily, and unchanged)

For attributes with the form DW_FORM_addrx_offset, following the attribute name, the attribute specification contains two unsigned LEB128 numbers, each representing a form. The first form must be of class address and the second of class constant. Values using this form in the .debug_info section contain a value for the first form followed by a value for the second form. The total value of the DW_FORM_addrx_offset is then computed by adding those two values together (if the first value is an indirect address, that is resolved first before adding it to the second value).

Now describe implicit const and indirect

For attributes with the form DW_FORM_implicit_const, in addition to the attribute name and form values, the attribute specification contains a third part, which is a signed LEB128 number. The value of this number is used as the value of the attribute. This form only appears in an abbreviation section (.debug_abbrev) because the intention is to remove the constant value from .debug_info .

For attributes with the form DW_FORM_indirect, the actual attribute form value itself is in the .debug_info section which begins with an unsigned LEB128 number that specifies the actual form, followed by the value according to that form. This allows producers to choose forms for particular attributes dynamically, without having to add a new entry to the abbreviations table.

Delete the following line

If the actual attribute form is DW_FORM_implicit_const, the form is (still) followed by a signed LEB128 number.

Would we want to delete the following paragraph? Quite possibly yes, there is little reason to suggest repetition is a good idea.

If the actual attribute form is itself DW_FORM_indirect, the indirection repeats. There may be one or more occurrences of DW_FORM_indirect in sequence until a non-DW_FORM_indirect form is reached. The sequence of DW_FORM_indirect forms does not have any effect other than to use up space.

The rest of 7.5.3 continues unchanged.

The abbreviations for a given compilation unit end with an entry consisting of a 0 byte for the abbreviation code.