# FORMs Implicit Const and Indirect

## BACKGROUND

In issue [221114.1][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.

[221114.1]: https://dwarfstd.org/issues/221114.1.html

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.

---

2025-04-28: Accepted.
Approved deletion of the paragraph on repeated indirection.

2025-05-01: Editorial changes:

> For attributes with the form <ins>`DW_FORM_addrx_offset`</ins>,
> <del>following the attribute name,</del> the attribute specification
> contains <ins>additional</ins> two unsigned LEB128 numbers, each representing
> a form. The first form must be of class address and the
> second of class constant. 
> <ins>Using this form in an attribute of a debugging information entry
> results in two values: a value for the first form, and a value
> for the second form. The total value of the attribute is then
> computed by adding those two values together.</ins>
> <del>(if the first value is an indirect
> address, that is resolved first before adding it to the
> second value).</del>
>
> 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 <ins>is only
> used</ins> in an abbreviation section (`.debug_abbrev`
> <ins>or `.debug_abbrev.dwo`</ins>). <del>because the
> intention is to remove the constant value from
> `.debug_info`.</del>
> 
> *This form saves space by avoiding repetition of the same
> attribute value in multiple places in a `.debug_info` or
> `.debug_info.dwo` section.*
> 
> For attributes with the form `DW_FORM_indirect`, the actual
> attribute form value itself is in the `.debug_info` <ins>or
> `.debug_info.dwo`</ins> section which begins with an
> unsigned LEB128 number that specifies the actual form,
> followed by the value according to that form. <ins>This form
> is only used in an abbreviation section (`.debug_abbrev` or
> `.debug_abbrev.dwo`).</ins>
> 
> *This allows producers to choose forms for particular
> attributes dynamically, without having to add a new entry to
> the abbreviations table.*

2025-05-12: Editorial change:

> For attributes with the form <ins>`DW_FORM_addrx_offset`</ins>,
> <del>following the attribute name,</del>
> <ins>in addition to the attribute name and form values,</ins>
> the attribute specification contains
> <del>two unsigned LEB128 numbers,</del>
> <ins>a third and fourth part,</ins>
> each <ins>an unsigned LEB128 number</ins> representing
> a form. The first form must be of class address and the
> second of class constant....