[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