[Bug 43959] New: 'process signal ...' should probably NOT stop the process

Bug ID 43959
Summary ‘process signal …’ should probably NOT stop the process
Product lldb
Version 9.0
Hardware PC
OS Linux
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@lists.llvm.org
Reporter mgorny@gentoo.org
CC jdevlieghere@apple.com, labath@google.com, llvm-bugs@lists.llvm.org

I think that the current behavior of 'process signal', i.e. that it causes the
process to stop with the delivered signal is incorrect and rather incidental of
the implementation.

While it is expected that a debugger should stop if the signal is sent from
outside.  However, if a debugger sends the signal there is no reason why the
process would stop telling the debugger that it just sent a signal (it should
know that!).  FWICS this only happens because the signal is sent via kill()
rather than ptrace(PTRACE_CONT, ...).  Furthermore, I suspect that it doesn't
work that way with the per-thread signal logic which actually uses resume
actions (but doesn't seem to be used at the moment).

The thing is, the ptrace() API doesn't provide the distinction between:

(a) sending signal for the 'first' time, i.e. when it should apparently go back
to the debugger,

(b) sending signal for the 'second' time, i.e. when you decide whether it
should hit the process or be discarded.

The generic assumption is that signal from debugger falls into (b).  While it
is technically possible to hack the current behavior using LLDB API (i.e. make
::Signal()+::Resume() pretend that the process was stopped with a signal rather
than resuming it), I think that would be a gross hack.  It would also require
writing another hack for the per-thread signal logic to match.

I think it would be better to actually change the behavior to match ptrace()
expectations, and make 'process signal ...' deliver the signal without stopping
the process.  Bug #23318 suggests that FreeBSD is already doing that, and my
local NetBSD code was also updated to work the same way.  Ideally, we would
remove ::Signal() altogether and use resume actions for all signals.