[Dwarf-discuss] Tables which have a unit_length header field must be contiguous.
# Problem There is no statement if tables must be contiguous or if there can be padding between the tables. # Background Some sections have an implicit assumption that the tables in a section are contiguous so the section can be processed by serially reading the section. Sections in this category are: .debug_info (Unit Headers, Section 7.5.1) .debug_aranges (Address Lookup Tables, Section 6.1.2) .debug_names (Name Index Section Header, Section 6.1.1) .debug_frame (Section 6.4.1) All other tables may be accessed indirectly via an offset into a section, so in theory there is no need to ensure the tables are contiguous provided the tables are only accessed via these offsets. However there are use cases when this can be a problem - The file is "stripped" to just contain line information (.debug_line / .debug_line_str). The .debug_line_str was added for exactly this use case. There is now the assumption that the .debug_line section can be processed serially. - File dump utilities which list the contents of the sections serially. Sections with tables which have headers with a unit_length field: .debug_aranges (Section 6.1.2) .debug_addr (Section 7.27) .debug_info / .debug_info.dwo (Section 7.5.1) .debug_line / .debug_line.dwo (Section 6.2.4) .debug_loclists / .debug_loclists.dwo (Section 7.29) .debug_names (Section 6.1.1) .debug_rnglists / .debug_rnglists.dwo (Section 7.28) .debug_str_offsets / .debug_str_offsets.dwo (Section 7.26) Sections with tables/contributions without headers: .debug_abbrev / .debug_abbrev.dwo (Section 7.5.3) .debug_frame (Section 6.4.1) .debug_line_str .debug_macro / .debug_macro.dwo (Section 6.3.1) .debug_str / .debug_str.dwo It is a point for discussion on whether to only require the tables with a unit_length header field be contiguous, or should all tables be made contiguous. # Proposed Addition: 7.34 Contiguous Tables Tables which start with a unit_length field must be contiguous with the preceding table in the section or start of the section if there is no preceding table. # Alternative Proposed Addition: 7.34 Contiguous Tables Tables must be contiguous with the preceding table in the section or start of the section if there is no preceding table. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Tables which have a unit_length header field must be contiguous.
Yeah - agreed with this whole description & I'd feel comfortable with either of the proposed additions. On Wed, Mar 29, 2023 at 2:15 AM Keith Walker via Dwarf-discuss wrote: > > # Problem > > > > There is no statement if tables must be contiguous or if > > there can be padding between the tables. > > > > # Background > > > > Some sections have an implicit assumption that the tables in a section > > are contiguous so the section can be processed by serially reading the > > section. Sections in this category are: > > > > .debug_info (Unit Headers, Section 7.5.1) > > .debug_aranges (Address Lookup Tables, Section 6.1.2) > > .debug_names (Name Index Section Header, Section 6.1.1) > > .debug_frame (Section 6.4.1) > > > > All other tables may be accessed indirectly via an offset into a section, > > so in theory there is no need to ensure the tables are contiguous provided > > the tables are only accessed via these offsets. > > > > However there are use cases when this can be a problem > > > > - The file is "stripped" to just contain line information (.debug_line / > > .debug_line_str). The .debug_line_str was added for exactly this use case. > > There is now the assumption that the .debug_line section can be processed > > serially. > > > > - File dump utilities which list the contents of the sections serially. > > > > Sections with tables which have headers with a unit_length field: > > > > .debug_aranges (Section 6.1.2) > > .debug_addr (Section 7.27) > > .debug_info / .debug_info.dwo (Section 7.5.1) > > .debug_line / .debug_line.dwo (Section 6.2.4) > > .debug_loclists / .debug_loclists.dwo (Section 7.29) > > .debug_names (Section 6.1.1) > > .debug_rnglists / .debug_rnglists.dwo (Section 7.28) > > .debug_str_offsets / .debug_str_offsets.dwo (Section 7.26) > > > > Sections with tables/contributions without headers: > > > > .debug_abbrev / .debug_abbrev.dwo (Section 7.5.3) > > .debug_frame (Section 6.4.1) > > .debug_line_str > > .debug_macro / .debug_macro.dwo (Section 6.3.1) > > .debug_str / .debug_str.dwo > > > > It is a point for discussion on whether to only require the tables > > with a unit_length header field be contiguous, or should all tables be > > made contiguous. > > > > # Proposed Addition: > > > > 7.34 Contiguous Tables > > > > Tables which start with a unit_length field must be contiguous with the > > preceding table in the section or start of the section if there is no > > preceding table. > > > > # Alternative Proposed Addition: > > > > 7.34 Contiguous Tables > > > > Tables must be contiguous with the preceding table in the section or > > start of the section if there is no preceding table. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- > 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
Re: [Dwarf-discuss] Tables which have a unit_length header field must be contiguous.
> There is no statement if tables must be contiguous or if > there can be padding between the tables. I've added this as Issue 230329.1. Thanks! -cary -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] ISSUE: CPU vector types.
On 3/28/23 13:17, David Blaikie wrote:
DW_AT[_GNU]_vector is best understood not as "a hardware vector register" but rather as a
marker that "this type is eligible to be passed in hardware vector registers at function
boundaries according to the platform ABI".
My 2c would not be to describe these in terms of
hardware/implementations (that gets confusing/blurs the line between
variable/types and locations - as you say, these things can be stored
in memory, so they aren't uniquely in registers - you might have a
member of this type in a struct passed in memory and need to know the
ABI/struct layout for that, etc), but at the source level - which the
ABI is defined in those same terms. Overloading, for instance, still
applies if these are different types - so other debugger features need
to work based on this type information.
So it seems like a simpler question is:
How should DWARF producers/consumers expect to encode the source
example Ben provided (well, simplified a bit):
#include
void f( __m128 a){
}
What DWARF should be used to describe the type of 'a'? And how does
this encoding scale to all the other similar intrinsic types?
As a person who has spent a crazy amount of time doing ABI work and
static analysis this is what I would like: (I'm kind of assembling this
by cutting and pasting and editing so please excuse minor errors like
sizes and ignoring siblings. It is hand written hand-wavy DWARF)
*Factored out preamble to all of them:*
[0] base_type abbrev: 3
byte_size (data1) 4
encoding (data1) float (4)
name (strp) "float"
[5] base_type abbrev: 3
byte_size (data1) 4
encoding (data1) unsigned (4)
name (strp) "unsigned int"
[8] base_type abbrev: 3
byte_size (data1) 4
encoding (data1) signed (4)
name (strp) "int"
[10] base_type abbrev: 3
byte_size (data1) 8
encoding (data1) double (4)
name (strp) "double float"
[15] subprogram abbrev: 32
external (flag_present) yes
name (string) "f"
[20] formal_parameter abbrev: 15
name (string) "a"
type (ref4) [30]
*void f( float *a){}**
*[30] pointer_type abbrev: 5
byte_size (implicit_const) 8
type (ref4) [0]
*void f( float a[]){}*
[30] array_type abbrev: 5
type (ref4) [0]
*void f( float a[4]){}
*[30] array_type abbrev: 5
type (ref4) [0]
[40] subrange_type abbrev: 31
upper_bound (data1) 3*
*
*void f( float a[s], **unsigned s**){} // C only*
[30] array_type abbrev: 5
type (ref4) [0]
[40] subrange_type abbrev: 31
upper_bound (data1) DW_OP_reg reg4
[50]formal_parameter abbrev: 15
name (string) "s"
type (ref4) [5]
*void f( __m128 a){} // floats implied*
[30] typedef abbrev: 8
name (strp) "__m128"
decl_file (data1) xmmintrin.h (2)
decl_line (data1) 69
decl_column (data1) 15
type (ref4) [40]
[40] array_type abbrev: 5
vector (flag_present) yes
type (ref4) [0]
[50] subrange_type abbrev: 31
upper_bound (data1) 3*
*
*void f( __m128i a){} // integer*
[30] typedef abbrev: 8
name (strp) "__m128i"
decl_file (data1) xmmintrin.h (2)
decl_line (data1) 69
decl_column (data1) 15
type (ref4) [40]
[40] array_type abbrev: 5
vector (flag_present) yes
type (ref4) [8]
[50] subrange_type abbrev: 31
upper_bound (data1) 3
*void f( __m128d a){}*
[30] typedef abbrev: 8
name (strp) "__m128d"
decl_file (data1) xmmintrin.h (2)
decl_line (data1) 69
decl_column (data1) 15
type (ref4) [40]
[40] array_type abbrev: 5
vector (flag_present) yes
type (ref4) [10]
[50] subrange_type abbrev: 31
upper_bound (data1) 2
*void f( __m128u a){} // unsigned*
[30] typedef abbrev: 8
name (strp) "__m128u"
decl_file (data1) xmmintrin.h (2)
decl_line (data1) 69
decl_column (data1) 15
type (ref4) [40]
[40] array_type abbrev: 5
vector (flag_present) yes
