[Lldb-commits] [PATCH] D101237: [lldb] Fix [[no_unique_address]] and libstdc++ 11's std::unique_ptr

Jan Kratochvil via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Sun Apr 25 01:48:02 PDT 2021


jankratochvil added a comment.

In D101237#2714971 <https://reviews.llvm.org/D101237#2714971>, @teemperor wrote:

> grep tells me that attribute also influences a bunch of other things in subtle ways (It seems to potentially influence ABIs and Obj-C encodings?) and we don't really know what other things this might influence in the future. So I have the suspicion that putting that attr on all record fields might break something in a subtle way.

I have a similar feeling but without a proof of anything ...

> In any case, what LLDB is usually doing is these situations is inferring from the existing debug information. I assume by looking at the `DW_AT_data_member_locations` values we could determine what the no_unique_address fields are in our record (and then only put the attributes on that)?

... LLDB can become overcomplicated as if you remove the `[[no_unique_address]]` from this testcase's `class B` the only effect on DWARF is for `class C`:

   0x00000033:   DW_TAG_structure_type
                   DW_AT_calling_convention       (DW_CC_pass_by_value)
                   DW_AT_name     ("C")
  -                DW_AT_byte_size        (0x01)
  +                DW_AT_byte_size        (0x02)
                   DW_AT_decl_file        ("uniqX.C")
                   DW_AT_decl_line        (5)
  
   0x0000003c:     DW_TAG_inheritance
                     DW_AT_type   (0x0000004f "B")
                     DW_AT_data_member_location   (0x00)
  
   0x00000042:     DW_TAG_member
                     DW_AT_name   ("c")
                     DW_AT_type   (0x0000006e "char")
                     DW_AT_decl_file      ("uniqX.C")
                     DW_AT_decl_line      (6)
  -                  DW_AT_data_member_location   (0x00)
  +                  DW_AT_data_member_location   (0x01)
  
   0x0000004e:     NULL

As LLDB could be already using `class B` as `CompilerType` LLDB will need to create a second/new `CompilerType` for `class B` when creating `CompilerType` for `class C`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237



More information about the lldb-commits mailing list