<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - 'process signal ...' should probably NOT stop the process"
href="https://bugs.llvm.org/show_bug.cgi?id=43959">43959</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>'process signal ...' should probably NOT stop the process
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>9.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>lldb-dev@lists.llvm.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mgorny@gentoo.org
</td>
</tr>
<tr>
<th>CC</th>
<td>jdevlieghere@apple.com, labath@google.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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. <a class="bz_bug_link
bz_status_NEW "
title="NEW - SendSignalTestCase.test_with_dwarf_and_run_command fails on FreeBSD with "False is not True : It was the running state""
href="show_bug.cgi?id=23318">Bug #23318</a> 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>