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

[Jim Ingham <jingham%apple.com@localhost>]

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

> On Mar 16, 2017, at 4:16 PM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> 
> On 16.03.2017 22:59, Jim Ingham wrote:
>> But it looks like all the "whole process" events you are talking about are not stop reasons but more start actions.  That makes sense, but what whole process stop events do you mean?
> 
> A process can be stopped with a signal. A signal can be emitted to:
> (1) a particular thread,
> (2) the whole process.
> 
> A particular thread can be stopped due to:
> - [PL_EVENT_SIGNAL] being signaled (a signal emitted to the whole
> process or this particular thread)
> - [PL_EVENT_SUSPENDED] being suspended (PT_SUSPEND, _lwp_suspend(2) or
> similar),
> - [PL_EVENT_NONE] no action the whole process stopped, because of a
> sibling thread that was signaled
> 
> If there was no particular thread targeted with a signal we cannot
> retrieve the thread that caused interruption of the process. It differs
> to FreeBSD and Linux as these systems offer always a thread that is
> culprit for interruption. In this scenario we would use "currentthread =
> whole process".
> 
> The GDB Remote Protocol handles it with special thread numbers 0 and -1.
> (I'm not certain what's the exact difference between "all threads" and
> "any thread" in the protocol).
> 
> In my local code, I'm populating all threads within the tracee
> (NativeThread) with exactly the same stop reason - for the "whole
> process" case. I can see - on the client side - that it prints out the
> same message for each thread within the process as all of them captured
> a stop action.
> 
> In Linux, it is possible to trigger multiple stop reasons on each thread
> separately, on NetBSD the first one wins. LLDB offers an extension in
> the GDB Remote Protocol to transfer stop reasons from all threads that
> were stopped due to some occurred event. This is not applicable on
> NetBSD. Faking it, this or that way, can be good enough for the first
> initial and functional port, but there is in my opinion technical dept
> over the port.
> 
> This can be kludged and I can set as the current thread (the one that
> caused interruption) the previously used one or the first one in the list.
> 
> I'm evaluating it from the point of view of a tracee with 10.000 threads
> and getting efficient debugging experience. This is why I would ideally
> reduce NativeThread to a container that is sorted, hashale box of
> integers (lwpid_t) and shut down stopped reason extension called for
> each stopped in debuggee.
> 
> But first things first, I need to make it functional with dummy
> solutions first.
> 
> And yes, I actually want to be able to debug 10.000 LWPs within a debugger.
>