[Dwarf-discuss] Update 240118.1: Allow padding in all tables

[Robinson, Paul]

Per comments on the list, revise the proposed non-normative paragraph for .debug_abbrev as follows.

### .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 or aligned by adding 0 bytes
at the end.*


> -----Original Message-----
> From: Dwarf-discuss <dwarf-discuss-
> bounces+paul.robinson=sony.com@lists.dwarfstd.org> On Behalf Of Robinson,
> Paul via Dwarf-discuss
> Sent: Thursday, January 18, 2024 2:08 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-discuss] Proposal: Allow padding in all tables
> 
> # 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
> INVALID URI REMOVED
> arf-discuss__;!!JmoZiZGBv3RvKRSx!-eIUiVM_8QeO3-EhqzXaj-roJozsN6a-JVU2-
> Hf7hb3L1ETrE3CYSACFhyY_Oo49VdINFheiOfos5ViaLhkSS8QhhthfqoOz$