From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41334 invoked by alias); 19 May 2017 17:40:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 41302 invoked by uid 89); 19 May 2017 17:40:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=worlds, oss, OSs X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 17:40:09 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 93FA810A82D; Fri, 19 May 2017 13:40:10 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Cc: Andreas Arnez , Yao Qi , Philipp Rudo , Omair Javaid , Yao Qi , Peter Griffin Subject: Re: [RFC v3 3/8] Add basic Linux kernel support Date: Fri, 19 May 2017 17:40:00 -0000 Message-ID: <62347400.WPoiX4QSWM@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20170316165739.88524-1-prudo@linux.vnet.ibm.com> <1715558.PXQs4KAMWY@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00464.txt.bz2 On Friday, May 19, 2017 07:05:47 PM Andreas Arnez wrote: > 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. Yes, a target up/down might work. Right now you can push/pop targets so in theory you can do this today with "target push kthread" and then "target pop". I hadn't played with this enough to know if that would be sufficient or not or if we wanted the targets to be more persistent to avoid having to recreate the thread list during each push. One thing I wanted to look at in more detail is how this interaction worked for the older M:N threading targets. FreeBSD used to use M:N threading in userland but abandoned that a while ago. The old thread target for that used libthread_db and you only had the one thread list, never a way to pop back down to the LWP view. > > 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 Hmm. > > (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? They definitely can. The same is true for user-level thread with LWPs on systems with M:N threading (e.g. scheduler activations on Solaris or FreeBSD's old KSE M:N threading model). -- John Baldwin