[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#2718456 <https://reviews.llvm.org/D101237#2718456>, @shafik wrote:

> I think @dblaikie original idea of adding a DWARF attribute for this case is the right way to go here. AFAICT this will change the answer to basic questions such as what size a `struct` is and this will likely lead to confusion from our users who will expect the answers in expression parsing to match what they are seeing elsewhere e.g.:
>
>   struct X {
>       int i;
>       [[no_unique_address]] Empty e;
>   };
>    
>   struct X2 {
>       int i;
>       Empty e;
>   };
>    
>   struct Z {
>       char c;
>       [[no_unique_address]] Empty e1, e2;
>   };
>   
>   struct Z2 {
>       char c;
>       Empty e1, e2;
>   };
>   
>   
>   struct W {
>       char c[2];
>       [[no_unique_address]] Empty e1, e2;
>   };
>   
>   struct W2 {
>       char c[2];
>       Empty e1, e2;
>   };
>   
>   
>   int main()
>   {
>       std::cout << sizeof(Empty) << "\n"
>                 << "X: " << sizeof(X) << "\n"
>                 << "X2: " << sizeof(X2) << "\n"
>                 << "Z: " << sizeof(Z) << "\n"
>                 << "Z2: " << sizeof(Z2) << "\n"
>                 << "W: " << sizeof(W) << "\n"
>                 << "W2: " << sizeof(W2) << "\n";
>     
>   }
>
> See godbolt <https://godbolt.org/z/qYzWeEh7n> which shows this result:
>
>   1
>   X: 4
>   X2: 8
>   Z: 2
>   Z2: 3
>   W: 3
>   W2: 4

Hmm, but is this still a problem for the particular way lldb does things - where it simultaneiously marks all the fields as no_unique_address (in this patch), but then still tells clang exactly where the fields will go? (and it could tell clang exactly how large the structure is too - from the DWARF)

@jankratochvil - have you been able to use these examples from @shafik to demonstrate problems with this patch when applied to lldb? What sort of problems arise in lldb?

(that said, an extension flag attribute should be fairly low cost to add and nice to explicitly encode this parameter in any case, I think - but I'd like to understand the tradeoffs/justification/etc)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237