[Lldb-commits] [PATCH] D83433: Fix how we handle bit-fields for Objective-C when creating an AST

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

I think I'm really out of the loop how this is supposed to work. From what I understand in the description it says we (=Clang when emitting DWARF?) is not generating offsets, but my DWARF dump of the test clearly has offsets (but they are clearly wrong).

  0x00000033:   DW_TAG_structure_type
                  DW_AT_APPLE_objc_complete_type	(true)
                  DW_AT_name	("HasBitfield2")
                  DW_AT_byte_size	(0x10)
                  DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                  DW_AT_decl_line	(3)
                  DW_AT_APPLE_runtime_class	(DW_LANG_ObjC)
  
  0x0000003c:     DW_TAG_inheritance
                    DW_AT_type	(0x0000007a "NSObject")
                    DW_AT_data_member_location	(0x00)
  
  0x00000042:     DW_TAG_member
                    DW_AT_name	("x")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(5)
                    DW_AT_data_member_location	(0x00)
                    DW_AT_accessibility	(DW_ACCESS_public)
  
  0x0000004f:     DW_TAG_member
                    DW_AT_name	("field1")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(7)
                    DW_AT_bit_size	(0x0f)
                    DW_AT_data_bit_offset	(0x00)
                    DW_AT_accessibility	(DW_ACCESS_public)
  
  0x0000005d:     DW_TAG_member
                    DW_AT_name	("field2")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(8)
                    DW_AT_bit_size	(0x04)
                    DW_AT_data_bit_offset	(0x07)
                    DW_AT_accessibility	(DW_ACCESS_public)
  
  0x0000006b:     DW_TAG_member
                    DW_AT_name	("field3")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(9)
                    DW_AT_bit_size	(0x04)
                    DW_AT_data_bit_offset	(0x03)
                    DW_AT_accessibility	(DW_ACCESS_public)

And when I change the bitfields to the sizes 2/4/4 then I actually get kinda right looking offsets in DWARF (ignoring the fact that they miss the 32-bit offset because of the first member) and the whole test seems to work fine from what I can see?

  0x0000004f:     DW_TAG_member
                    DW_AT_name	("field1")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(7)
                    DW_AT_bit_size	(0x02)
                    DW_AT_data_bit_offset	(0x00)
                    DW_AT_accessibility	(DW_ACCESS_public)
  
  0x0000005d:     DW_TAG_member
                    DW_AT_name	("field2")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(8)
                    DW_AT_bit_size	(0x04)
                    DW_AT_data_bit_offset	(0x02)
                    DW_AT_accessibility	(DW_ACCESS_public)
  
  0x0000006b:     DW_TAG_member
                    DW_AT_name	("field3")
                    DW_AT_type	(0x000000a6 "unsigned int")
                    DW_AT_decl_file	("/Users/teemperor/test/bit.m")
                    DW_AT_decl_line	(9)
                    DW_AT_bit_size	(0x04)
                    DW_AT_data_bit_offset	(0x06)
                    DW_AT_accessibility	(DW_ACCESS_public)

So, if I understand correctly with this patch we add the bitfields with the wrong values (as they get fixed in the runtime later). Should we even do any bitfield offset checking for them at all if it doesn't matter? There is also some Obj-C unnamed bitfield support code below that seems to use those values, so ignoring the fact that the values are bogus seems a bit risk...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83433/new/

https://reviews.llvm.org/D83433