Re: [RFC v3 3/8] Add basic Linux kernel support

[John Baldwin <jhb@freebsd.org>]

On Friday, May 19, 2017 05:24:09 PM Andreas Arnez wrote:
> On Fri, May 19 2017, Yao Qi wrote:
> 
> > Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
> >
> >> * Implement separate thread_lists.
> >>   Allow every target to manage its own thread_list.  Heavy impact for you and a
> >>   lot work for me...
> >
> > Hi Philipp,
> > before you spend a lot of time implementing this, it is better to start
> > an RFC discussion on an appropriate time, so that people can well
> > understand why do we need this change.
> 
> FYI, I have just started investigating this a bit.
> 
> The reason for multiple thread lists has been covered in some of the
> discussions already, but let me give my few cents.
> 
> In the kernel live debug scenario we conceptually have two different
> thread models layered on top of each other:
> 
> * LK target: Thread == Linux kernel thread
> * Remote target: Thread == CPU
> 
> If we represent CPUs and Linux threads in a single thread list, then it
> becomes difficult to maintain consistency between the LK target and the
> remote target: Who owns which parts of the thread_info?  How to
> guarantee unique ptids across the board, etc.?  Not to speak of the
> confusing "info threads" output if CPUs and threads are munged
> together.
> 
> Unfortunately many places in GDB assume that there is just one thread
> list, one active target and one current inferior/thread.  In order to
> maintain multiple thread lists cleanly, we probably have to lift these
> restrictions and get rid of the global variables current_target,
> thread_list, inferior_ptid, etc., or most of their uses.  That's my
> preliminary conclusion, anyway.  Alternate suggestions are welcome.

FreeBSD's kernel GDB bits (which I maintain) have a similar issue, though for
now we only export kernel threads as threads in GDB and don't support CPUs as
a GDB-visible thing.  In some ways the model I would personally like would be
to have conceptual "layers" that you can bounce up and down between kind of
like a stack, but in this case a stack of thread targets, so that I could do
a kind of 'thread_down' and now 'info threads' would only show me CPUs, allow
me to select CPUs, etc. but then have a 'thread_up' to pop back up to the
kernel thread layer.  The best model I can think of is that this is similar
to M:N user-thread implementations where you have user threads multiplexed
onto LWPs.  In such a world (which I'm not sure many OS's use these days) it
would also be nice to kind of bounce between the worlds.  (In fact, the
model I have been toying with but have not yet implemented for adapting
FreeBSD's current kernel target support to qemu or the GDB stub I'm hacking
on for FreeBSD's native bhyve hypervisor would be to treat vCPUs as LWPs
so their ptid would have lwp == vcpu, and kernel-level threads as "threads",
so their ptid would have tid == kernel thread id).

-- 
John Baldwin