使用gcc的sso bi-endian代码矮化生成问题
sso bi-endian code dwarf generation issue using gcc
你好,我正在尝试使用 gcc 的 sso-endianity 属性为 biendian 代码生成 dwarf 信息,
struct __attribute__((scalar_storage_order("big-endian"))) ms1 {
int a;
};
struct __attribute__((scalar_storage_order("little-endian"))) ms2 {
int b;
};
struct ms1 a;
struct ms2 b;
目标文件中生成的矮人信息是,
./test.o: file format elf64-x86-64
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length: 0x76 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x1e): GNU C11 7.3.0 -mtune=generic -march=x86-64 -g -fstack-protector-strong
<10> DW_AT_language : 12 (ANSI C99)
<11> DW_AT_name : (indirect string, offset: 0x17): test.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x0): /home/neo/Desktop/test
<19> DW_AT_stmt_list : 0x0
<1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e> DW_AT_name : ms1
<22> DW_AT_byte_size : 4
<23> DW_AT_decl_file : 1
<24> DW_AT_decl_line : 1
<25> DW_AT_sibling : <0x34>
<2><29>: Abbrev Number: 3 (DW_TAG_member)
<2a> DW_AT_name : a
<2c> DW_AT_decl_file : 1
<2d> DW_AT_decl_line : 2
<2e> DW_AT_type : <0x34>
<32> DW_AT_data_member_location: 0
<2><33>: Abbrev Number: 0
<1><34>: Abbrev Number: 4 (DW_TAG_base_type)
<35> DW_AT_byte_size : 4
<36> DW_AT_encoding : 5 (signed)
<37> DW_AT_endianity : 1 (big)
<38> DW_AT_name : int
<1><3c>: Abbrev Number: 2 (DW_TAG_structure_type)
<3d> DW_AT_name : ms2
<41> DW_AT_byte_size : 4
<42> DW_AT_decl_file : 1
<43> DW_AT_decl_line : 5
<44> DW_AT_sibling : <0x53>
<2><48>: Abbrev Number: 3 (DW_TAG_member)
<49> DW_AT_name : b
<4b> DW_AT_decl_file : 1
<4c> DW_AT_decl_line : 6
<4d> DW_AT_type : <0x34>
<51> DW_AT_data_member_location: 0
<2><52>: Abbrev Number: 0
<1><53>: Abbrev Number: 5 (DW_TAG_variable)
<54> DW_AT_name : a
<56> DW_AT_decl_file : 1
<57> DW_AT_decl_line : 9
<58> DW_AT_type : <0x1d>
<5c> DW_AT_external : 1
<5c> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
<1><66>: Abbrev Number: 5 (DW_TAG_variable)
<67> DW_AT_name : b
<69> DW_AT_decl_file : 1
<6a> DW_AT_decl_line : 10
<6b> DW_AT_type : <0x3c>
<6f> DW_AT_external : 1
<6f> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
<1><79>: Abbrev Number: 0
这里的 ms1 是 TAG_base_type int a 的大端,ms2 是 TAG_base_type 的小端(显式) int 命名为 b.
但是矮树看起来很奇怪,因为没有 TAG_base_type b 的条目。
所以我的问题是这是 gcc 的错误,它排除了使标记节点唯一的可选参数,或者我错误地测试了它?
使用的gcc版本,
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
使用的objdump版本,
GNU objdump(Ubuntu 的 GNU Binutils)2.30
是的,这看起来像一个 gcc 错误。如果 gcc 要发出数据成员类型的字节顺序,那么这种情况下的两个成员必须具有不同的类型。
你好,我正在尝试使用 gcc 的 sso-endianity 属性为 biendian 代码生成 dwarf 信息,
struct __attribute__((scalar_storage_order("big-endian"))) ms1 {
int a;
};
struct __attribute__((scalar_storage_order("little-endian"))) ms2 {
int b;
};
struct ms1 a;
struct ms2 b;
目标文件中生成的矮人信息是,
./test.o: file format elf64-x86-64
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length: 0x76 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x1e): GNU C11 7.3.0 -mtune=generic -march=x86-64 -g -fstack-protector-strong
<10> DW_AT_language : 12 (ANSI C99)
<11> DW_AT_name : (indirect string, offset: 0x17): test.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x0): /home/neo/Desktop/test
<19> DW_AT_stmt_list : 0x0
<1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e> DW_AT_name : ms1
<22> DW_AT_byte_size : 4
<23> DW_AT_decl_file : 1
<24> DW_AT_decl_line : 1
<25> DW_AT_sibling : <0x34>
<2><29>: Abbrev Number: 3 (DW_TAG_member)
<2a> DW_AT_name : a
<2c> DW_AT_decl_file : 1
<2d> DW_AT_decl_line : 2
<2e> DW_AT_type : <0x34>
<32> DW_AT_data_member_location: 0
<2><33>: Abbrev Number: 0
<1><34>: Abbrev Number: 4 (DW_TAG_base_type)
<35> DW_AT_byte_size : 4
<36> DW_AT_encoding : 5 (signed)
<37> DW_AT_endianity : 1 (big)
<38> DW_AT_name : int
<1><3c>: Abbrev Number: 2 (DW_TAG_structure_type)
<3d> DW_AT_name : ms2
<41> DW_AT_byte_size : 4
<42> DW_AT_decl_file : 1
<43> DW_AT_decl_line : 5
<44> DW_AT_sibling : <0x53>
<2><48>: Abbrev Number: 3 (DW_TAG_member)
<49> DW_AT_name : b
<4b> DW_AT_decl_file : 1
<4c> DW_AT_decl_line : 6
<4d> DW_AT_type : <0x34>
<51> DW_AT_data_member_location: 0
<2><52>: Abbrev Number: 0
<1><53>: Abbrev Number: 5 (DW_TAG_variable)
<54> DW_AT_name : a
<56> DW_AT_decl_file : 1
<57> DW_AT_decl_line : 9
<58> DW_AT_type : <0x1d>
<5c> DW_AT_external : 1
<5c> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
<1><66>: Abbrev Number: 5 (DW_TAG_variable)
<67> DW_AT_name : b
<69> DW_AT_decl_file : 1
<6a> DW_AT_decl_line : 10
<6b> DW_AT_type : <0x3c>
<6f> DW_AT_external : 1
<6f> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
<1><79>: Abbrev Number: 0
这里的 ms1 是 TAG_base_type int a 的大端,ms2 是 TAG_base_type 的小端(显式) int 命名为 b.
但是矮树看起来很奇怪,因为没有 TAG_base_type b 的条目。 所以我的问题是这是 gcc 的错误,它排除了使标记节点唯一的可选参数,或者我错误地测试了它?
使用的gcc版本, gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
使用的objdump版本, GNU objdump(Ubuntu 的 GNU Binutils)2.30
是的,这看起来像一个 gcc 错误。如果 gcc 要发出数据成员类型的字节顺序,那么这种情况下的两个成员必须具有不同的类型。