gcc - 使用 gcc 的 sso 双端代码矮生成问题

Question

您好，我正在尝试使用 gcc 的 sso-endianity 属性为 biendian 代码生成矮人信息，

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

Answer 1

是的，这看起来像一个 gcc bug。如果 gcc 要发出数据成员类型的字节顺序，则此场景中的两个成员必须具有不同的类型。