Sorry, my brain is not working this morning, I answered your question in the
review comments…
Jim
> On Nov 4, 2019, at 7:28 AM, Pavel Labath <pa...@labath.sk> wrote:
>
> On 31/10/2019 20:51, Jim Ingham via lldb-dev wrote:
>> It looks like this change is causing problems with swift. I was talking a
>> little bit with Davide about this and it seems like it wasn't obvious how
>> this was designed to work. So here's what this was intended to do
>> (apologies if this is at too basic a level and the issue was something
>> deeper I missed, but anyway this might get us started...)
>> The lldb ValueObject system supports two fairly different kinds of values,
>> live and frozen.
>> The classic example of a live ValueObject is ValueObjectVariable. That
>> ValueObject is backed by an entity in the target, and knows when that entity
>> is valid and not. So it can always try to do "UpdateValueIfNeeded" and that
>> will always return good values. However, there's on complication with this,
>> which is that we also want ValueObjectVariable to be able to answer
>> "IsChanged". That's so in a UI you can mark values that change over a step
>> in red, which is very helpful for following along in a debugging session.
>> So you have to copy the values into host memory, in order to have something
>> to compare against when you stop again. That's why there's this slightly
>> complex dance between host and target memory for the live ValueObjects.
>> The example of a frozen object is the ValueObjectConstResult that is
>> returned from expression evaluation. That value is fixed to a StopID, so
>> the backing entity is only known to be good at that stop id. This is
>> implemented by copying the value into Host memory and fetching it from there
>> when requested.
>> The use case for this is for people like me who have a bad memory. So I can
>> stop somewhere and do:
>> (lldb) expr foo
>> struct baz $1 = {
>> bar = 20
>> }
>> Then later on when I forget what foo.bar was at that time, I can do:
>> (lldb) expr $1.bar
>> bar = 20
>> At a first approximation, this leads to the statement that ConstValues
>> should fetch what they fetch when made, and then not offer any information
>> that wasn't gathered when the variable was fetched, and you certainly don't
>> ever want these values to be updated.
>> A little complication arises because I might do:
>> (lldb) expr foo_which_has_a_pointer
>> $1 = ...
>> (lldb) expr *$1->the_pointer
>> If the StopID is the same between the first and second evaluation, then you
>> should follow the pointer into target memory and fetch the value. But if
>> the StopID has changed, then trying to dereference a pointer should be an
>> error. After all, you are now accessing an incoherent object, and if you
>> try to do anything fancier with it than just print some memory (like asking
>> the Swift Language Runtime what this value happens to be) you are very
>> likely to get into trouble.
>> So it's clear we need two different behaviors w.r.t. how we treat live or
>> frozen values. Pavel's change was addressing a failure in ValueObjectChild,
>> and the solution was to move the ValueObjectVariable behavior up to the
>> ValueObject level. But then that means that ValueObjectConstResults are no
>> longer obeying the ConstResult rules.
>> But it seems like the problem really is that we have only one
>> ValueObjectChild class, but child value objects can either be live or
>> frozen, depending on the nature of their Root ValueObject. And this is made
>> a little more complicated by the fact that frozen values only freeze when
>> the stop ID changes.
>
> Thanks for the writeup Jim. I haven't managed to dive into the source code
> yet, but the thing that's not clear to me from this otherwise detailed an
> understandable explanation is what is the interaction between this
> ConstResult stuff and the above patch.
>
> Superficially, it doesn't sound like that patch should do anything bad here.
> As the ValueObjectConstResult's data is located in host memory, the patch
> will compute that its pointer children will be of "load address" type, which
> sounds like precisely what's needed here.
>
> Of course, under the surface, there are plenty of ways this can go wrong, but
> precisely because of that, it's hard to say what's the right thing to do. Is
> it that ValueObjectConstResult uses the "address type" field to implement the
> "are the children valid at this stop ID" logic, and so this patch interferes
> with that? What's exactly the nature of the crash/misbehavior you were
> witnessing?
>
> pl
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
