Thanks, all, for all the information and advice.
We've got it working in Windows now by removing the SetResumeState call
from WillResume in the Windows-specific Thread implementation.
POSIX/Linux isn't in my wheelhouse, so I'll leave that for others.
On Tue, Jun 2, 2015 at 2:53 AM, Pavel Labath
On 2 June 2015 at 00:53, Jim Ingham wrote:
> Anyway, try taking that out and see if things go better. It would also be
> interesting to see what goes wrong if you take that out on the POSIXThread
> side.
These calls in POSIXThread are only used for linux local-only
debugging, which noone tests
> On Jun 1, 2015, at 4:47 PM, Zachary Turner wrote:
>
> Thanks! This has been very helpful. For reference, the reason why that
> SetResumeState() was ever there to begin with is because when I was first
> trying to make all this work I used the ProcessPOSIX as a model, and
> POSIXThread doe
Thanks! This has been very helpful. For reference, the reason why that
SetResumeState() was ever there to begin with is because when I was first
trying to make all this work I used the ProcessPOSIX as a model, and
POSIXThread does the same thing. There's even a comment saying that it
doesn't see
One other bit, just in case you're looking at this more closely... The other
place where we call SetResumeState in lldb is in "process continue" and "thread
continue". "process continue" sets all the states to running. The idea is
that "continue" should get all the threads that aren't user-sus
> On Jun 1, 2015, at 3:07 PM, Jim Ingham wrote:
>
> One thing to keep in mind is that there are two kinds of "resume state".
> There's the user-specified resume state, which is set by
> Thread::SetResumeState, and is stored in m_resume_state in the thread. It
> should start out "running" an
One thing to keep in mind is that there are two kinds of "resume state".
There's the user-specified resume state, which is set by
Thread::SetResumeState, and is stored in m_resume_state in the thread. It
should start out "running" and never change unless some user command does so.
I don't kno
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, becau
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 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
>
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
anything.
But looking over the code, it looks like WillResume() actually
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 subcl
On Mon, Jun 1, 2015 at 1:29 PM Zachary Turner wrote:
> 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
I think Zach's right. The only plugin that calls SetResumeState inside
WillResume is POSIXThread, and that seems to be overridden by FreeBSDThread.
If I remove the call of SetResumeState from
TargetThreadWindows::WillResume, everything starts to work.
I'll look into adding some logging in Thread
Currently ThreadWindows::WillResume() looks like this:
void
TargetThreadWindows::WillResume(lldb::StateType resume_state)
{
SetResumeState(resume_state);
}
I originally put this code in because that's what one or two of the other
plugins did and I wasn't sure what the "correct" thing to do w
>The way this works is that when we go to resume the process, all the
thread's get asked whether they need to stop other threads to implement
whatever strategy they are currently pursuing. That query ends up calling
the currently active thread plan's "StopOthers" method.
Right, and since the Thre
The way this works is that when we go to resume the process, all the thread's
get asked whether they need to stop other threads to implement whatever
strategy they are currently pursuing. That query ends up calling the currently
active thread plan's "StopOthers" method. If one thread returns t
Thanks for the info.
This is not theoretical. I'm trying to get TestBreakAfterJoin to pass on
Windows. Step 1 was to convert it use instead of .
Step 2 was to fix some minor issues in TargetThreadWindows.
But now the inferior deadlocks because the one thread that's not suspended
is waiting on
When stepping over a breakpoint, the ThreadPlanStepOverBreakpoint gets pushed,
handles the single instruction step - during which it does suspend the other
threads - then it gets popped. When you next resume, whatever plan was
handling the stepping before the breakpoint was hit will resume with
[I'm trying to make TestBreakAfterJoin work on Windows.]
I'm unclear how continuing from a breakpoint in a multi-threaded inferior
is supposed to work.
A breakpoint is set, and the inferior runs until one of its threads hits
the breakpoint. The user then selects continue.
The thread that had hi
19 matches
Mail list logo
