From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99568 invoked by alias); 19 May 2017 16:28:32 -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 99488 invoked by uid 89); 19 May 2017 16:28:31 -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=Heavy, worlds, speak, cents 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 16:28:30 +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 7865F10A888; Fri, 19 May 2017 12:28:31 -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 16:28:00 -0000 Message-ID: <1715558.PXQs4KAMWY@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> <86d1b5z142.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00460.txt.bz2 On Friday, May 19, 2017 05:24:09 PM Andreas Arnez wrote: > On Fri, May 19 2017, Yao Qi wrote: > > > Philipp Rudo 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