[Lldb-commits] [PATCH] D28945: Add completed_plan_stack to LLDB ThreadStateCheckpoint
Boris Ulasevich via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Jan 23 10:40:46 PST 2017
boris.ulasevich added a comment.
In https://reviews.llvm.org/D28945#651806, @jingham wrote:
> The plans should do whatever cleanup they are going to do when they get popped, and should not rely on the destructors to do this work.
Yes, you already made a note a time ago:
r123869 | jingham | 2011-01-20
Back up both the register AND the stop state when calling functions.
--------------------------------------------------------------------
123869 jingham // N.B. Don't wait to do clean up target state till the destructor, since that will usually get called when
123869 jingham // the target resumes, and you want to leave the target state correct for new plans in the time between when
123869 jingham // your plan gets unshipped and the next resume.
> I don't think that letting the completed plans live a little longer should pose any problems
It is not something extraordinary, but just a life frame the plans intended to live without unexpected internall call.
By the way, I fixed my issue by restoring specific Thread's property - don't you think it is a potential bug for somebody who will use another property (destroyed plans?) without proper treatment in Thread State Checkpoint?
> But it would be worth a quick audit
As I see, actually destructors clears breakpoints - it is important, but not urgent job.
> we should document that requirement in the ThreadPlan dissertation at the beginning of ThreadPlan.h
For me the ThreadPlan dissertation is like the Bible: I feel it is very old and complicated, a lot on wisdom is hidden there, but nobody around have ever read it attentively :)
I would add words about Thread State there and define stack direction to make words 'below' and 'higher' more definite. Please see new diff.
Repository:
rL LLVM
https://reviews.llvm.org/D28945
More information about the lldb-commits
mailing list