[PATCH] D144392: [lldb] Skip signal handlers for ignored signals on lldb-server's side when stepping

Pavel Labath via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 20 07:33:47 PST 2023


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



More information about the llvm-commits mailing list