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

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43959

            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 at lists.llvm.org
          Reporter: mgorny at gentoo.org
                CC: jdevlieghere at apple.com, labath at google.com,
                    llvm-bugs at 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191111/08d045cd/attachment-0001.html>