From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129819 invoked by alias); 19 May 2017 17:05:55 -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 129801 invoked by uid 89); 19 May 2017 17:05:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=worlds, oss, H*o:Research, OSs X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 17:05:53 +0000 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4JH4BdJ110327 for ; Fri, 19 May 2017 13:05:54 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2aj39hc4eq-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 19 May 2017 13:05:54 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 May 2017 18:05:53 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 19 May 2017 18:05:49 +0100 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v4JH5nXc38469770; Fri, 19 May 2017 17:05:49 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA8D742045; Fri, 19 May 2017 18:04:06 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A241942041; Fri, 19 May 2017 18:04:06 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.109]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Fri, 19 May 2017 18:04:06 +0100 (BST) From: Andreas Arnez To: John Baldwin Cc: gdb-patches@sourceware.org, Yao Qi , Philipp Rudo , Omair Javaid , Yao Qi , Peter Griffin Subject: Re: [RFC v3 3/8] Add basic Linux kernel support References: <20170316165739.88524-1-prudo@linux.vnet.ibm.com> <86d1b5z142.fsf@gmail.com> <1715558.PXQs4KAMWY@ralph.baldwin.cx> Date: Fri, 19 May 2017 17:05:00 -0000 In-Reply-To: <1715558.PXQs4KAMWY@ralph.baldwin.cx> (John Baldwin's message of "Fri, 19 May 2017 09:24:50 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17051917-0040-0000-0000-0000039186DC X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051917-0041-0000-0000-000025738711 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-19_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705190107 X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00461.txt.bz2 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? -- Andreas