From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25868 invoked by alias); 2 Oct 2018 13:21:23 -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 25606 invoked by uid 89); 2 Oct 2018 13:21:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=awareness, spending, presenting, sk:init_th X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Oct 2018 13:21:21 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 41B2F80F9C; Tue, 2 Oct 2018 13:21:20 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6615B1C929; Tue, 2 Oct 2018 13:21:19 +0000 (UTC) Subject: Re: [PATCH 3/3] Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc. To: John Baldwin , gdb-patches@sourceware.org References: <20181001103252.5150-1-palves@redhat.com> <20181001103252.5150-4-palves@redhat.com> From: Pedro Alves Message-ID: <1efaf61e-026c-1d90-2d62-369e7ebeae6b@redhat.com> Date: Tue, 02 Oct 2018 13:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00048.txt.bz2 On 10/01/2018 05:33 PM, John Baldwin wrote: > On 10/1/18 3:32 AM, Pedro Alves wrote: >> As preparation for multi-target, this patch makes each inferior have >> its own thread list. > > The BSD-related bits all look fine to me. Do you have an existing branch > for this on github that I can pull down to do some simple run-time testing? I've pushed it now to users/palves/per-inf-thread-list on sourceware.org. >> As for the init_thread_list calls sprinkled around, they're all >> eliminated by this patch, and a new, central call is added to >> inferior_appeared. Note how also related to that, there's a call to >> init_wait_for_inferior in remote.c that is eliminated. >> init_wait_for_inferior is currently responsible for discarding skipped >> inline frames, which had to be moved elsewhere. Given that nowadays >> we always have a thread even for single-threaded processes, the >> natural place is to delete a frame's inline frame info when we delete >> the thread. I.e., from clear_thread_inferior_resources. > > This brings up another question I have. I have out-of-tree patches to add > FreeBSD kernel-awareness (there's a mixture of authors and many of the > kernel-specific bits are BSD licensed, so I can't upstream it as is, though > at some point I might be able to upstream portions of it). One of the changes > in this branch is that I have a kernel target similar to bsd-kvm.c but with > awareness of threads (so it creates a GDB thread for each kernel thread in > the kernel image being examined). Right now this uses init_thread_list > (ugh). What is the right thing to do? Should it instead be creating a > new inferior to represent the kernel and its set of threads? What does it use init_thread_list for? Maybe the call you're thinking can just go away? With multi-target, you should be able to create an inferior for the kernel image, using that bsd-kvm-like target. And simultaneously, create other inferiors bound to the regular ptrace target. And debug all at the same time, if you find it useful. But just switching inferior 1 from the ptrace target to the kernel target I'd think would be done with "kill" to get rid of the ptrace process, and then do "target kernel" (or whatever it's spelled). This is just like switching inferior 1 from the native target to "target remote". And that should continue working unmodified. > A somewhat related question is one thing I haven't yet solved which is > how to "stack" kernel threads on top of a remote target that presents each > CPU as a thread to GDB (e.g. the GDB stub in qemu, or the one I'm working on > in FreeBSD's hypervisor). I still don't quite know how to think about > solving that, but that is a bit more of an ambitious change I suspect. Yeah, better and more generic support for such a use case has been a part of the community's wish list for a long while, for all sorts of similar cases: kernel debugging, userspace threading libraries, Go goroutines etc. Basically, you could think of it as the remote target presenting a process_stratum layer with its own set of threads, and then the logical kernel threads handled by a thread_stratum layer. The current ugliness relates to the fact that there's no clean way to get the process_stratum threads out of view, at least not without the target layers coordinating in some promiscuous fashion. Another related problem is of course that both target layers would be competing for the same single thread list. The ravenscar target would be a current example of a thread_stratum target that can sit on top of the remote target, today. I don't know whether that supports SMP at the "remote" level, it may be that it assumes that there's only ever one "bare-metal" thread, which simplifies things. Then there's the Solaris port, which adds both LWPs and threads to the same thread list, so if you do "info threads", given that Solaris is 1:1 nowadays, you see each thread twice... Made a bit more sense back when Solaris was M:N. dbx instead has separate "info threads" and "info lwp"-like commands: https://docs.oracle.com/cd/E37069_01/html/E37078/gevbl.html I guess a better fit for GDB, if you want to support seamlessly flipping between kernel-layer "views", may be to have a knob to switch between the "modes/views/target-layers" instead, and keep most of GDB thinking in terms of "threads". At the internals level, I am not exactly sure how it'd be implemented, but I could imagine making the inferior have a thread list per target stratum, per example. There seems to be so many ramifications from the user visible level level down to run control levels, that it's hard to come up with a solid plan without spending some time prototyping something, and inevitably throwing away a number of such prototypes along the process... That's what happened (or is happening) with multi-target too. Also, there's no current way to for example write the thread_stratum layer in Python, you'd have to embed the kernel-specific knowledge inside GDB, in C++. That's what the Linux kernel debugging patches were doing/proposing, I believe. I don't have a problem with it, though some sort of Python layer would be ideal, IMHO. Thanks, Pedro Alves