This is the mail archive of the
mailing list for the GDB project.
Re: [RFC v3 3/8] Add basic Linux kernel support
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: John Baldwin <jhb at freebsd dot org>
- Cc: gdb-patches at sourceware dot org, Yao Qi <qiyaoltc at gmail dot com>, Philipp Rudo <prudo at linux dot vnet dot ibm dot com>, Omair Javaid <omair dot javaid at linaro dot org>, Yao Qi <yao dot qi at linaro dot org>, Peter Griffin <peter dot griffin at linaro dot org>
- Date: Fri, 19 May 2017 19:05:47 +0200
- Subject: Re: [RFC v3 3/8] Add basic Linux kernel support
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <1715558.PXQs4KAMWY@ralph.baldwin.cx>
On Fri, May 19 2017, John Baldwin wrote:
> 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.
Exactly! Note that GDB already has a stack of "layers" -- the target
stack. Thus I'm considering commands like "target up/down" for this
purpose. Of course this requires per-target thread lists.
> 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.
M:N user-thread implementations have probably become more popular with
Go. In that scenario we have the following layers:
* Threads == Goroutines (user-thread implementation)
* Threads == OS threads
> (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).
So kernel-level threads can not be rescheduled on a different vCPU?