Re: [Dwarf-discuss] Proposal: Allow padding in all tables
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 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 > *Sent:* Tuesday, January 30, 2024 6:01 PM > *To:* Robinson, Paul > *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 pro
Re: [Dwarf-discuss] Proposal: Allow padding in all tables
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 Sent: Tuesday, January 30, 2024 6:01 PM To: Robinson, Paul 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 mailto: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, .debu
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.* > > ###
Re: [Dwarf-discuss] Proposal: Allow padding in all tables
On 1/19/24 06:51, Robinson, Paul via Dwarf-discuss wrote: Couldn't the abbrev table simply be padded with 0 bytes? Hmmm... that would appear to a dumper as a series of zero-length tables, I suppose? Would look funny in a dump but it could work. And would be a lot simpler for the producer of course. --paulr I think the zero-length-tables as padding sounds good. The way the libdwarf's dwarfdump prints such abbrev padding is not as nice as it should be, I'll fix that. David Anderson -- 100 pains = 1 Megahertz -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Proposal: Allow padding in all tables
> > ### .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.* > > Couldn't the abbrev table simply be padded with 0 bytes? Hmmm... that would appear to a dumper as a series of zero-length tables, I suppose? Would look funny in a dump but it could work. And would be a lot simpler for the producer of course. --paulr -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Proposal: Allow padding in all tables
> ### .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.* Couldn't the abbrev table simply be padded with 0 bytes? -cary -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Proposal: Allow padding in all tables
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 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
[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
