labath added subscribers: jingham, labath.
labath requested changes to this revision.
labath added a reviewer: jingham.
labath added a comment.
This revision now requires changes to proceed.
I'm afraid you're fixing this at the wrong end. This kind of complex thread
control does not belong inside the debug stub.
IIUC, the problematic sequence of events is:
1. lldb sends a `vCont:s` packet
2. lldb-server resumes (PTRACE_SINGLESTEP)
3. process immediatelly stops again (without stepping) due to a pending signal
4. lldb-server decides to inject the signal and resumes (steps) again
5. process stops inside the signal handler
6. confusion ensues
If that's the case, then I think the bug is at step 4, specifically in this
code:
// Check if debugger should stop at this signal or just ignore it and resume
// the inferior.
if (m_signals_to_ignore.contains(signo)) {
ResumeThread(thread, thread.GetState(), signo);
return;
}
I believe we should not be attempting to inject the signal if the thread was
stepping. I think we should change this to report the signal to the client and
let it figure out what to do. I.e., change this code into something like:
if (m_signals_to_ignore.contains(signo) && thread.GetState() ==
eStateRunning) {
ResumeThread(thread, eStateRunning, signo);
return;
}
// else report the signal as usual
If that is not enough to fix the bug, then we can figure out what needs to be
done on the client. @jingham might have something to say about that.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D144392/new/
https://reviews.llvm.org/D144392
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
