[lldb-dev] Continuing from a breakpoint with multiple threads
amccarth at google.com
Mon Jun 1 14:07:39 PDT 2015
I agree that the naming of these functions are suboptimal indicators of
what they do.
On Mon, Jun 1, 2015 at 1:59 PM, Zachary Turner <zturner at google.com> wrote:
> Ahh, I find it a little confusing that ShouldResume() calls WillResume().
> ShouldResume() to me sounds like a function that should be const. It seems
> like it should just ask a question and gets a yes/no answer, but not modify
> But looking over the code, it looks like WillResume() actually means "I
> don't know if you need to resume or not, but if you do, then do it, and if
> you don't, then tell me that by returning false"
> On Mon, Jun 1, 2015 at 1:40 PM Adrian McCarthy <amccarth at google.com>
>> ThreadList::WillResume, near the bottom, ends up calling
>> ShouldResume(eStateSuspended) on the other threads, because the
>> ThreadPlanStepOverBreakpoint::StopOthers says it should.
>> Thread::ShouldResume effectively passes its parameter on to the thread's
>> WillResume, with the comment, "Let Thread subclasses do any special work
>> they need to prior to resuming."
>> On Mon, Jun 1, 2015 at 1:30 PM, Zachary Turner <zturner at google.com>
>>> On Mon, Jun 1, 2015 at 1:29 PM Zachary Turner <zturner at google.com>
>>>> I'm not quite ready to throw the blanket over this one yet :)
>>>> What was the value of resume_state when it called WillResume()? It
>>>> sounds like it was eStateSuspended, which if that's the case, then it still
>>>> seems like something deeper inside of LLDB's thread plans is confused about
>>>> something, because calling WillResume(eStateSuspended) means "The process
>>>> is seriously about to resume, and when it does, this thread is not going to
>>>> remain suspended".
>>> s/is not going to/is going to/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev