Re: Interface to retrieve LWPs via ptrace(2)

[christos%astron.com@localhost (Christos Zoulas)]

In article <21d0d3ee-043a-ac7c-3352-57beafde6e3f%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>There are two basic BSD interfaces to retrieve kernel processes
>associated to a process:
>
>FreeBSD:
>
>PT_GETNUMLWPS
>        This request returns the number of kernel threads
>        associated with the traced process.
>PT_GETLWPLIST
>        This request can be used to get the current thread list.  A
>        pointer to an array of type lwpid_t should be passed in
>        addr, with the array size specified by data.  The return
>        value from ptrace() is the count of array entries filled
>        in.
>
>OpenBSD:
>
>PT_GET_THREAD_FIRST
>       This request reads the thread ID of the traced process' first
>       thread into the â??struct ptrace_thread_stateâ?? pointed to by addr.
>       The data argument should be set to
>       sizeof(struct ptrace_thread_state).
>PT_GET_THREAD_NEXT
>       This request is just like PT_GET_THREAD_FIRST, except it returns
>       the thread ID of the subsequent thread. The
>       â??struct ptrace_thread_stateâ?? pointed to by addr must be
>       initialized by a previous PT_GET_THREAD_FIRST or
>       PT_GET_THREAD_NEXT request.
>
>I need an equivalent interface for LLDB.
>
>Which one is preferred for NetBSD?
>
>In the OpenBSD one, as there is no timing window (likely harmless)
>between GETNUMLWPS and GETLWPLIST. The OpenBSD one can also omit
>allocations of intermediate arrays.
>
>On the other hand FreeBSD might need just two ptrace(2) calls for higher
>number of LWPs and it might scale better.
>
>Both functions construct equivalent algorithms.
>

NetBSD does this via libptread_dbg td_open() and friends. I don't
know how this API got created, but this is what gdb uses on NetBSD.
This is an artifact of the SA-threads where you could have N lwps
and M threads, so the kernel does not really know about the thread
state for all the threads necessitating a tight coupling between
libpthread and the debugger.  I believe this was inspired by old
Solaris code, but I can't find a trace of it. Perhaps we should
ask Nathan if he is still around.

Nevertheless, before implementing yet another way to get thread
information, we should decide if it is worth it, or if we can use
what we have (since these ptrace calls are not portable anyway).

christos