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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
