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....@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$ -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss