Fair enough - alignment is mentioned in several cases, perhaps that could be omitted? If that's not usually the need/intent?
On Wed, Jan 31, 2024 at 6:54 AM Robinson, Paul <paul.robin...@sony.com> wrote: > This proposal is guidance for the producer, not the linker. The producer > needs this guidance specifically because linkers don’t pad/align > contributions. > > > > I believe padding is rarely a functional requirement, and when it is, it’s > not for alignment IME. This is where the line-table padding came from, > allowing elbow room to replace a function’s line table without having to > update references to other contributions. (Motivating examples include JIT > (re-)compilation and incremental linking.) > > > > Padding for alignment, which is generally for performance or convenience > and which I have run into in past years (pre-LLVM), must not confuse > dumpers (which would be inclined to interpret padding bytes as the next > header); therefore the padding bytes have to be interpretable. > > > > I think if we’re going to mention padding (which we already do in six of > the ten non-string-section cases described below) we should be complete > about it, hence this proposal. I’m not especially excited about the > .debug_macro case, but as we failed to give that section a header with a > length, we have to live with the consequences. > > > > If you think padding should never be mentioned (and so anyone who feels > moved to provide padding has to re-invent the wheel), feel free to write a > counter-proposal removing the existing mentions. > > --paulr > > > > *From:* David Blaikie <dblai...@gmail.com> > *Sent:* Tuesday, January 30, 2024 6:01 PM > *To:* Robinson, Paul <paul.robin...@sony.com> > *Cc:* dwarf-discuss@lists.dwarfstd.org > *Subject:* Re: [Dwarf-discuss] Proposal: Allow padding in all tables > > > > Is anyone actually using this? In my experience linkers are generally > concatenating these sections together with no extra padding/alignment. > > I'd rather not spec something that's not used/needed. I'm happy for > consumers to be improved in the face of degenerate entries that might be > created for padding if developers of such consumers feel so inclined > (though I'd probably push back a bit on it in the consumers I work on - in > the absence of any evidence of particular need/use case). > > > > 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