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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
