jimingham wrote:
> Makes sense to me. Not quite sure if this is the best way to get the scratch
> type system, but I don't see a better way either.
>
> @jimingham Should DIL return persistent variables as well? I've already
> thought about implementing this, can create a separate patch.
Before the DIL could generate NEW values, the answer to that was clearly no.
After all, the original path expressions were about finding extant or lazily
evaluated ValueObjects. So there was always some VO child or synthetic child
that was the end result of the expression. We didn't need to make up another
container type for them.
Now that the DIL can return new values (e.g. the result of "a + b") we need to
make up containers for the results. The most obvious solution to that is
ValueObjectConstResult. These expression results are pretty much always going
to be const, so that seems the natural container.
The thing that persistent variables and result variables add is the ability to
use the result VO from one expression in another expression. For instance,
persistent definition variables have to support:
(lldb) expr char *$my_ptr = "something"
(lldb) expr printf("%s", $my_ptr)
Both result variables and persistent definitions are wrappers around some kind
of ValueObject that manage inserting them in memory, and also giving them a
real location so that `AddressOf` works in the target.
So the only advantage to making these persistent definitions (or result
variables if you want them to be const) is if you wanted to have DIL results
available to the expression evaluator. Otherwise you'd be paying the cost of
sticking every DIL expression result in target memory and keeping them there
forever since you really don't know when you could release them.
I don't see any really strong motivation for doing this.
Also, you'd need to be careful to only do this for definitions, not references
to extant things.
After all, if I ran the DIL expression `foo.bar.baz` and got the ValueObject
that represented that result, I would expect that if I step over a line that
changes `baz`, I could ask that result ValueObject if it has changed, and I
would expect it to say "yes" and give me the new value. If the VO we hand out
is just a reference to the child `baz` of the VO for the child `bar` in the VO
representing the local variable `foo`, then that's all going to work naturally
because ValueObjects know how to update themselves. But a persistent variable
version of `baz` wouldn't know how to do that since it's disconnected from
whatever defined it.
The TL;DR is: unless you see a persuasive use case for using the result of a
DIL evaluation in the the expression evaluator, there's no reason to make
persistent results for them.
https://github.com/llvm/llvm-project/pull/215706
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
