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