[all-commits] [llvm/llvm-project] a54c42: Fix how we handle bit-fields for Objective-C when ...

Shafik Yaghmour via All-commits all-commits at lists.llvm.org
Mon Jul 20 16:12:50 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: a54c42df9a7261eafc9291128be4ff5217302dd3
      https://github.com/llvm/llvm-project/commit/a54c42df9a7261eafc9291128be4ff5217302dd3
  Author: shafik <syaghmour at apple.com>
  Date:   2020-07-20 (Mon, 20 Jul 2020)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    A lldb/test/API/lang/objc/bitfield_ivars/Makefile
    M lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py
    M lldb/test/API/lang/objc/bitfield_ivars/main.m

  Log Message:
  -----------
  Fix how we handle bit-fields for Objective-C when creating an AST

Currently expressions dealing with bit-fields in Objective-C objects is pretty broken. When generating debug-info for Objective-C bit-fields DW_AT_data_bit_offset has a different meaning than it does to C and C++.
When we parse the DWARF we validate bit offsets for C and C++ correctly but not for ObjC. For ObjC in some cases we end up incorrectly flagging an error and we don't generate further bit-fields in the AST.
Later on when we do a name lookup we don't find the ObjCIvarDecl in the ObjCInterfaceDecl in some cases since we never added it and then we don't go to the runtime to obtain the offset.

This will fix how we handle bit-fields for the Objective-C case and add tests to verify this fix but also to documents areas that still don't work and will be addressed in follow-up PRs.

Note: we can never correctly calculate offsets statically because of how Objective-C deals with the fragile base class issue. Which means the runtime may need to shift fields over.

Differential Revision: https://reviews.llvm.org/D83433




More information about the All-commits mailing list