Issue 240118.1: Allow padding in all tables
| Author: | Paul Robinson |
|---|---|
| Champion: | Paul Robinson |
| Date submitted: | 2024-01-18 |
| Date revised: | 2024-06-11 |
| Date closed: | 2024-06-11 |
| Type: | Enhancement |
| Status: | Accepted |
| DWARF version: | 6 |
Multiple sections
Background
Issue 230329.1 requires all tables to be contiguous. During the discussion of that issue, the question came up of whether all tables allowed padding, so that contiguous concatenated contributions could be aligned reasonably. This is the result of my research.
Overview
The set of tables (merging the two tables from 230329.1, plus three more noticed by Ron) is as follows:
.debug_abbrev/.debug_abbrev.dwo(Section 7.5.3).debug_aranges(Section 6.1.2).debug_addr(Section 7.27).debug_cu_index(Section 7.3.5.3).debug_frame(Section 6.4.1).debug_info/.debug_info.dwo(Section 7.5.1).debug_line/.debug_line.dwo(Section 6.2.4).debug_line_str.debug_loclists/.debug_loclists.dwo(Section 7.29).debug_macro/.debug_macro.dwo(Section 6.3.1).debug_names(Section 6.1.1).debug_rnglists/.debug_rnglists.dwo(Section 7.28).debug_str/.debug_str.dwo.debug_str_offsets/.debug_str_offsets.dwo(Section 7.26).debug_sup(Section 7.3.6).debug_tu_index(Section 7.3.5.3)
.debug_abbrev
Entries have arbitrary size. Can be padded by adding an unused abbrev entry. Proposing a non-normative paragraph describing this.
.debug_aranges
Removed by 220724.1.
.debug_addr
Entries have the size of an address and don't explicitly provide a padding mechanism. Adding unused entries at the end of the table should suffice. Proposing a non-normative paragraph describing this.
.debug_cu_index
This is constructed by the "package" utility when the .dwp file is created, and so never needs more than one entry.
.debug_frame
Already permits padding by use of DW_CFA_nop.
.debug_info
Already permits padding by use of the abbreviation code 0 (see Section 7.5.2).
.debug_line
Already has DW_LNE_padding.
.debug_line_str
This is a string section and does not need padding (typically would be merged, not concatenated).
.debug_loclists
Already permits padding by use of repeated DW_LLE_end_of_list, with a
non-normative comment to that effect.
.debug_macro
This has no unit_length and no explicit provision for padding. One
could insert unused opcodes into the opcode_operands_table but this
seems like quite a hack. In keeping with other sections, I'm proposing a
DW_MACRO_padding opcode.
.debug_names
Components are mostly 4- or 8-byte multiples, except for the abbreviation table. The abbreviation table explicitly permits padding (Section 6.1.1.4.7).
.debug_rnglists
Already permits padding by use of repeated DW_RLE_end_of_list, with a
non-normative comment to that effect.
.debug_str
This is a string section and does not need padding (typically would be merged, not concatenated).
.debug_str_offsets
This has a header of 8 or 16 bytes, and entries of 4 or 8 bytes. This can still require padding if you want alignment greater than 4 bytes, and there is no explicit provision. Proposing a non-normative paragraph describing this.
.debug_sup
As currently specified, there can never be more than one entry in this section. If we did have more than one, then the FORMs that refer to the supplementary file would need a way to specify which one, and there is no provision for that.
.debug_tu_index
This is constructed by the "package" utility when the .dwp file is created, and so never needs more than one entry.
Conclusion
Everything is already covered except .debug_abbrev, .debug_addr,
.debug_str_offsets, and .debug_macro. The first three need
non-normative notes describing how to pad the sections, and
.debug_macro requires a new opcode to introduce padding cleanly.
Proposed Changes
I sorted these by affected section. In addition to the section-specific changes there is one general note.
.debug_abbrev
In Section 7.5.3 "Abbreviations Tables" (p.207), at the end of the section, add a new non-normative paragraph:
An abbreviations table may be padded at the end with null bytes.
.debug_macro
Add new Section 6.3.4 "Other Entries" (~ p.170) as follows:
DW_MACRO_paddingThe
DW_MACRO_paddingopcode takes two operands, a byte count and a sequence of arbitrary bytes. The byte count is an unsigned LEB128 encoded number and does not include the size of the opcode or the byte count operand. The opcode and operands have no effect on the macro information.This permits a producer to pad the macro information with a minimum of two bytes.
In Section 7.23 "Macro Information", Table 7.28 (p. 249), add the following row:
DW_MACRO_padding 0x00
.debug_str_offsets
In Section 7.26 "String Offsets Table" (p.241), at the end of the section, add a new non-normative paragraph:
This table may be padded with unused entries. These entries should have all 1 bits as a hint that the entries are unused.
.debug_addr
In Section 7.27 "Address Table" (p.241), at the end of the section, add a new non-normative paragraph:
This table may be padded with unused entries. These entries should have all 1 bits as a hint that the entries are unused.
General
Section 7.34 "Contiguous Tables" was added by issue 230329.1, and reads as follows:
Tables must be contiguous with the preceding table in the section or start of the section if there is no preceding table.
This proposal adds a new non-normative paragraph:
Consumers may prefer to have these tables padded so that each subsequent table is "aligned" on a certain boundary, typically 4 or 8 bytes. Every table of information has a way for the table as a whole to be padded if the producer wishes to do so. Tables from multiple object files that are concatenated by a linker would then each be aligned without any special effort by the linker; this alignment may provide performance or other benefits. This padding is entirely optional, and does not relax any constraint specified in section 7.30.
2024-02-05: Revised to suggest padding .debug_abbrev with 0 bytes.
2024-06-10: Accepted, pending wording changes to be agreed on between Paul and Ron, regarding alignment.
2024-06-11: Revised and closed.
