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.
Attachment:
signature.asc
Description: OpenPGP digital signature