[Lldb-commits] [PATCH] D79554: [lldb/Dataformatter] Add support to CF{Dictionary, Set}Ref types

Raphael Isemann via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri May 8 08:33:03 PDT 2020


teemperor requested changes to this revision.
teemperor added a comment.
This revision now requires changes to proceed.

I don't see a huge problem with things like `__lldb_autogen_nspair` as it's a single obviously generated type hardcoded into LLDB. But this really generic approach here can generate all kind of structs whenever some formatter decides that some random incomplete record has a synthetic value.

But in any case, I think we're kind of talking about different problems here. We do have the following type:

  TypedefType 0x7fc9cd04f440 'CFDictionaryRef' sugar
  |-Typedef 0x7fc9cd04f3e0 'CFDictionaryRef'
  `-PointerType 0x7fc9cd04f3a0 'const struct __CFDictionary *'
    `-QualType 0x7fc9cd04f381 'const struct __CFDictionary' const
      `-RecordType 0x7fc9cd04f380 'struct __CFDictionary'
        `-CXXRecord 0x7fc9cd04f2d0 '__CFDictionary'

So we do have an underlying type for `*CFDictionaryRef` which is just the `__CFDictionary` record. The problem is just that this is an incomplete type. So we could make a ValueObject that has an incomplete struct type which seems to work for me just fine? We probably need to adjust the formatter for this prints an actual empty value: `(const __CFDictionary) *dict = {}`



================
Comment at: lldb/source/Core/ValueObject.cpp:2853
+            ConstString g___lldb_opaque_ptr_type(
+                compiler_type.GetTypeName().AsCString());
+
----------------
teemperor wrote:
> This is the name of the typedef, not the underlying incomplete struct. So this creates a new empty record with the name of the typedef which seems weird. If we fake that some type is actually empty instead of incomplete, then I think the underlying struct makes more sense to emulate. Also this variable name is kinda weird with it's `g____` prefix even though it's not a global or a static.
This is still the name of the typedef:
```
lang=c++
            child_compiler_type =
                type_system->GetEmptyStructType(compiler_type.GetTypeName());
```

So we end up with an AST like we get from here:
```
lang=c++
typedef NSDictionary* CFDictionaryRef;
struct CFDictionaryRef {}; // conflict
```

This should at least have some kind of `__lldb_made_up_type_unique_stringy_` prefix in the generated name to make this not ambiguous.

Also a log statement would be useful that we know when these types are created when someone reports a bug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79554





More information about the lldb-commits mailing list