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