tberghammer added a comment.
In https://reviews.llvm.org/D30272#686061, @jingham wrote:
> I also thought about having the synthetic child provider mark up the special
> child value objects when it made them. It bugs me a little but that you
> couldn't, for instance, have a synthetic child provider that doesn't display
> a child that is the result of the dereference in its view, but provides one
> when you do the dereference. And it looks like we're creating a system where
> we have somebody - the SCP - that knows what the dereference means to it, but
> then we lose the connection to that knowledge when we hand it out.
The current system already supports it to have a synthetic child what doesn't
displayed by default (can be referenced by name) so we can rely on that
functionality to have a child what is the result of the dereference while not
in view. We might have to gave it a special name (e.g. "$dereference") to make
it easy to access it from the value object but I am not sure if it will be
necessary (would certainly make the code simpler and more efficient).
I thought quite a bit about adding a Dereference method the the synthetic child
provider but I am not convinced it is a good idea as it would complicate the
API for it and I don't see how can we solve the problem I hit with the infinite
smart pointer loop when I added a synthetic child displayed by default what
contained the dereference of the pointed object without annotating the children
itself.
> Explain a bit more why you need to create a copy? Anything that makes two
> versions of the same value that we have to keep in sync makes me nervous.
> For instance, one of the things we want to do in the future is make
> write-back possible for synthetic children. That would allow you to change
> values of std::vector elements in the Locals view of a GUI debugger (which
> would naturally be based on SBValues) just like you can with the
> non-synthetic SBValues. Also, how would the SCP know to update this copy
> when you've stepped in the debugger and the dereference now points to another
> pointee?
Take the following (bit strange) example:
struct Foo {
int x;
int& operator*() { return x; }
}
If I implement a synthetic child provider for it then it will return the same
value object as we would return when accessing the "x" member variable. If we
annotate that value object as dereference of parent then it will effect the way
we are displaying the "x" member variable even when it is not used through the
"operator*". Creating a second separate ValueObject solves this problem by
separating the 2 solving this issue. For updating it we will rely on the same
logic what is currently used to update other synthetic children after a step
what is not backed by an actual variable. My current idea is to create a new
ValueObject with the memory address and compiler type copied from the original
value object and it will be updated using the Update method of the synthetic
child provider.
https://reviews.llvm.org/D30272
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
