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

[David Blaikie]

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.robinson@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 <dblaikie@gmail.com>
> *Sent:* Tuesday, January 30, 2024 6:01 PM
> *To:* Robinson, Paul <paul.robinson@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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240131/632a8de3/attachment.htm>