[llvm][DebugInfo] LLVM adds redundant DW_AT_data_member_location to C++ union members

[Michael137]

GCC and LLVM diverge in this. GCC chooses to omit DW_AT_data_member_location for union members because it's going to be 0x0 anyway. LLVM still adds the attribute: Godbolt

Here's the LLVM DWARF:

0x00000034:     DW_TAG_member
                  DW_AT_name	("x")
                  DW_AT_type	(0x00000047 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(2)
                  DW_AT_data_member_location	(0x00)

0x0000003d:     DW_TAG_member
                  DW_AT_name	("y")
                  DW_AT_type	(0x00000047 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(3)
                  DW_AT_data_member_location	(0x00)

This came up in #159401. LLDB already knows how to handle both cases, so LLVM could choose to omit it. Not sure if the size benefits would be particularly appealing, to warrant the extra complexity. Though if it's just a case of "don't emit DW_AT_data_member_location for union types", that's rather trivial to implement.

[Michael137]

Side-note, if the union members are bitfields, then the DW_AT_bit_offset between LLVM and GCC differ Godbolt:

// GCC
0x0000003e:     DW_TAG_member
                  DW_AT_name	("x")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(2)
                  DW_AT_decl_column	(9)
                  DW_AT_type	(0x0000005d "int")
                  DW_AT_byte_size	(4)
                  DW_AT_bit_size	(0x01)
                  DW_AT_bit_offset	(0x1f)

0x00000048:     DW_TAG_member
                  DW_AT_name	("y")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(3)
                  DW_AT_decl_column	(9)
                  DW_AT_type	(0x0000005d "int")
                  DW_AT_byte_size	(4)
                  DW_AT_bit_size	(0x02)
                  DW_AT_bit_offset	(0x1e)

versus

// LLVM
0x00000034:     DW_TAG_member
                  DW_AT_name	("x")
                  DW_AT_type	(0x00000052 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(2)
                  DW_AT_bit_size	(0x01)
                  DW_AT_data_bit_offset	(0x00)

0x0000003e:     DW_TAG_member
                  DW_AT_name	("y")
                  DW_AT_type	(0x00000052 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(3)
                  DW_AT_bit_size	(0x02)
                  DW_AT_data_bit_offset	(0x00)

But that's probably just a consequence of how the compilers choose to layout the union?

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Michael Buch (Michael137)

GCC and LLVM diverge in this. GCC chooses to omit `DW_AT_data_member_location` for union members because it's going to be `0x0` anyway. LLVM still adds the attribute: [Godbolt](https://godbolt.org/z/jvfMj9Ko7)

Here's the LLVM DWARF:

0x00000034:     DW_TAG_member
                  DW_AT_name	("x")
                  DW_AT_type	(0x00000047 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(2)
                  DW_AT_data_member_location	(0x00)

0x0000003d:     DW_TAG_member
                  DW_AT_name	("y")
                  DW_AT_type	(0x00000047 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(3)
                  DW_AT_data_member_location	(0x00)

This came up in #159401. LLDB already knows how to handle both cases, so LLVM could choose to omit it. Not sure if the size benefits would be particularly appealing, to warrant the extra complexity. Though if it's just a case of "don't emit DW_AT_data_member_location for union types", that's rather trivial to implement.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Michael Buch (Michael137)

GCC and LLVM diverge in this. GCC chooses to omit `DW_AT_data_member_location` for union members because it's going to be `0x0` anyway. LLVM still adds the attribute: [Godbolt](https://godbolt.org/z/jvfMj9Ko7)

Here's the LLVM DWARF:

0x00000034:     DW_TAG_member
                  DW_AT_name	("x")
                  DW_AT_type	(0x00000047 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(2)
                  DW_AT_data_member_location	(0x00)

0x0000003d:     DW_TAG_member
                  DW_AT_name	("y")
                  DW_AT_type	(0x00000047 "int")
                  DW_AT_decl_file	("/app/example.cpp")
                  DW_AT_decl_line	(3)
                  DW_AT_data_member_location	(0x00)

This came up in #159401. LLDB already knows how to handle both cases, so LLVM could choose to omit it. Not sure if the size benefits would be particularly appealing, to warrant the extra complexity. Though if it's just a case of "don't emit DW_AT_data_member_location for union types", that's rather trivial to implement.

[tromey]

Side-note, if the union members are bitfields, then the DW_AT_bit_offset between LLVM and GCC differ Godbolt:

// GCC
                  DW_AT_bit_offset	(0x1f)
// LLVM
                  DW_AT_data_bit_offset	(0x00)

But that's probably just a consequence of how the compilers choose to layout the union?

GCC still emits the obsolete DW_AT_bit_offset, which has weird semantics on little-endian. I think in this case the compilers lay out the types the same and the DWARF is correct in both cases -- it's just easy to miss that the attribute names are slightly different.