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

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

The way the ValueObject code works w.r.t. Synthetic child providers is that you first look up and make a ValueObject for the actual value the user requested, (for instance a ValueObjectVariable or a ValueObjectChild or a ValueObjectConstResult for expressions, etc.), then you hand that to the printer.  The printer will look at whether the current settings prefer Synthetic Values, and if they do they ask the actual value if it has any Synthetic children.  So when you do something like:

(lldb) frame var *opaque_ptr

we first have to make a ValueObject for *opaque_ptr (in this case the dereference is a ValueObjectChild of the ValueObjectVariable representing the variable `opaque_ptr` and return that to the printer.

But you can't currently make a ValueObject that doesn't have a type, and the problem here is that we don't have a type for * of the opaque pointer.  Making an empty struct definition and returning a ValueObject with that struct definition is one fairly straightforward way of doing that.  And we already inject custom types in other places to manage synthetic children (look for `__lldb_autogen_nspair` for instance).  So this seemed the most straightforward choice.

Note, you could also make a new ValueObject subclass for these purposes: ValueObjectOpaqueDereference to forward the Synthetic Children.  The ValueObject base class doesn't require a type so you could make such a thing. But it would somehow fake handing out the type so you'd have to be careful how you did that.  Then its job would be to hand out the synthetic children.  If people really hate making the fake structure we could go this way instead, but it seems better to use an extant facility if we can, and "fake handing out the type" seems to me at least as dangerous as injecting synthesized types into the TypeSystem.  The latter we already do, the former we don't.

I'm not happy with the notion of just hard-coding this to CF types or making it about bridged types at all.  It is not uncommon to have a client library that vends opaque pointers, but you've figured out what some of the fields are.  One solution to debugging this scenario is to introduce another shadow type, either in lldb or actually in your code, and cast types to that when printing.  But that means you can't use "frame var" since it doesn't support casting, and you have to remember to cast every time in the expression parser which is annoying.  if you made a synthetic child provider, and if what Ismail is trying to get working here works generally, then once you've made the provider, you can just print * of the pointer, and it will work.  So I think this should be a general facility for opaque pointer types with synthetic child providers.  So I'd much prefer to keep this a general facility.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79554