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

[David Blaikie via Phabricator via lldb-commits]

dblaikie added a comment.

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

>> (and it could tell clang exactly how large the structure is too - from the DWARF)
>
> We are actually doing that to my knowledge and return the `DW_AT_byte_size` value for the record type. The relevant API that LLDB implements to get layout/size info back to Clang is:
>
>   bool layoutRecordType(
>       const clang::RecordDecl *Record, uint64_t &Size, uint64_t &Alignment,
>       llvm::DenseMap<const clang::FieldDecl *, uint64_t> &FieldOffsets,
>       llvm::DenseMap<const clang::CXXRecordDecl *, clang::CharUnits>
>           &BaseOffsets,
>       llvm::DenseMap<const clang::CXXRecordDecl *, clang::CharUnits>
>           &VirtualBaseOffsets) override;
>
> I think the `sizeof` part actually works* in this regard as we just return whatever we got from DWARF. I get the correct results for the example above (both with and without this patch). There might be some weirder corner cases that could go wrong but I think the main concern are more complicated situations like in the crash that is fixed here.
>
> FWIW, I took a look at the DWARF standard and I think that is actually something we should already emit in the form of a `DW_AT_byte_size 0` attribute at the field? Quote:
>
>   If the size of a data member is not the same as the size of the type given for the data member, the data member has either a DW_AT_byte_size or a DW_AT_bit_size attribute whose integer constant value (see Section 2.19) is the amount of storage needed to hold the value of the data member.
>
> I am not a DWARF laywer so maybe I understand that part wrong.
>
> (*I actually found a bug that miscalculated empty structs while testing, but that's unrelated. Patch incoming).

Hmm, sounds sort of plausible - but might not be right. The cppreference article on no_unique_address presents some interesting challenges that will be maybe surprising (well, I guess not, given the need to render these situations for empty bases already) - yeah, I guess probably the question to ask is: How are empty bases rendered today? I think the trick is they're rendered not as zero length, but as having a location that overlaps with another field - and having a length of 1 (which is the real length of the "empty" object).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237