# FORMs Implicit Const and Indirect
## 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`, and `DW_FORM_indirect` to be listed in the order `DW_FORM_addrx`, `DW_FORM_implicit_const`, and `DW_FORM_indirect`. `DW_FORM_addrx` 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. -- Space is to place as eternity is to time. -- Joseph Joubert -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
