[Dwarf-discuss] Proposal: Allow padding in all tables

[Cary Coutant]

This is Issue 240118.1.

https://dwarfstd.org/issues/240118.1.html

-cary

On Thu, Jan 18, 2024 at 11:08 AM Robinson, Paul via Dwarf-discuss
<dwarf-discuss@lists.dwarfstd.org> wrote:
>
> # Allow padding in all tables
>
> Enhancement; 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) is as follows:
>
> - .debug_abbrev / .debug_abbrev.dwo (Section 7.5.3)
> - .debug_aranges (Section 6.1.2)
> - .debug_addr (Section 7.27)
> - .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_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 a size of (segment_selector_size + address_size) 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_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.
>
> ### 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:
>
> *This table may be padded by adding an unused abbreviation entry. The minimum number of bytes in an abbreviation entry is four (abbreviation number, child flag, and two 0 bytes indicating the end of the attribute/form pairs). This can be expanded by choosing a large abbreviation number with a longer LEB128 encoding, or adding non-zero attribute/form pairs.*
>
> ### .debug_macro
>
> Add new Section 6.3.4 "Other Entries" (~ p.170) as follows:
>
> 1. DW_MACRO_padding
>    The DW_MACRO_padding opcode 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.*
>
> ### .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 to fill out the table to some desired alignment. 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 to fill out the table to some desired alignment. These entries should have all 1 bits as a hint that the entries are unused.*
>
> ### General
>
> In Section 7.34 "Contiguous Tables" (added by issue 230329.1), at the end of the section, add a new non-normative paragraph:
>
> *Every table of information has a way for the table as a whole to be padded to some desired alignment if the producer wishes to do so. Tables from multiple object files that are concatenated by a linker could then each be aligned, which may provide performance or other benefits. This padding is entirely optional, and does not relax any constraint specified in section 7.30.*
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss