[lldb-dev] LLDB/NetBSD extended set of tasks

Kamil Rytarowski via lldb-dev lldb-dev at lists.llvm.org
Fri Mar 17 08:16:16 PDT 2017


On 17.03.2017 01:37, Jim Ingham wrote:
> The main consumer of thread stop reasons is the execution control (ThreadPlans - which handle stepping & function calling - and StopInfo::PerformAction which handles breakpoint/watchpoint hits).  The only bad effect of populating all the threads with the whole process signals is if any of the plans did anything special with that signal.  Some of the thread plans do care about a few signals, but those are mostly SIGSEGV and the like (the function calling plans care about this.)  I can't see what it would mean to send a whole process SIGSEGV, however, that seems like it is always going to be a thread specific thing.  Ditto for however you see a breakpoint hit (SIGTRAP?)  Those really have to be thread specific...
> 
> I can't think of anything else this would really affect, so going forward with your "process => all threads" fiction is probably fine for a first pass.
> 
> Jim
> 

Thank you for your analysis.

I can check siginfo(2) of each signal and verify it. ptrace(2)
(PT_GET_SIGINFO) gives me destination of a signal:
specific-thread/all-threads. The siginfo(2) structures gives signal's
source/reason. For example si_code can contain SI_USER for kill(2),
SI_QUEUE for sigqueue(2) etc.

Hypothetically someone would pass SIGSEGV manually for the whole process
- eg. using the kill(1) command - but it's rather anomaly and I don't
expect a debugger to have a defined behavior for such events. I would
just pass that sort of signals to the child and ignore in the
MonitorCallback code.

The NetBSD version of raise(3) uses _lwp_kill(2) a LWP-specific kill(2)
to emit a signal to a specified thread within the same process. Just for
sake of curiosity - the FreeBSD LLDB code breaks (assert(3) fires) after
calling "raise(SIGTRAP)" from the child.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170317/dacc18b1/attachment.sig>


More information about the lldb-dev mailing list