From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74303 invoked by alias); 3 Feb 2017 19:46:47 -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 74267 invoked by uid 89); 3 Feb 2017 19:46:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*o:Research, compete, atop, user-space X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Feb 2017 19:46:40 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v13JY1le026737 for ; Fri, 3 Feb 2017 14:46:39 -0500 Received: from e06smtp08.uk.ibm.com (e06smtp08.uk.ibm.com [195.75.94.104]) by mx0a-001b2d01.pphosted.com with ESMTP id 28cv6ehkmh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 03 Feb 2017 14:46:38 -0500 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 3 Feb 2017 19:46:36 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp08.uk.ibm.com (192.168.101.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 3 Feb 2017 19:46:34 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0475D1B08023; Fri, 3 Feb 2017 19:49:25 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v13JkXLt3277292; Fri, 3 Feb 2017 19:46:33 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A12DBA4055; Fri, 3 Feb 2017 19:46:29 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6C9ABA4040; Fri, 3 Feb 2017 19:46:29 +0000 (GMT) Received: from oc1027705133.ibm.com (unknown [9.152.212.222]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Fri, 3 Feb 2017 19:46:29 +0000 (GMT) From: Andreas Arnez To: Yao Qi Cc: Philipp Rudo , Peter Griffin , gdb-patches@sourceware.org, yao.qi@arm.com Subject: Re: [RFC 0/7] Support for Linux kernel debugging References: <20170112113217.48852-1-prudo@linux.vnet.ibm.com> <20170125180950.GA10609@griffinp-ThinkPad-X1-Carbon-2nd> <20170126141225.321a5bf6@ThinkPad> <20170203174521.GC11916@E107787-LIN> Date: Fri, 03 Feb 2017 19:46:00 -0000 In-Reply-To: <20170203174521.GC11916@E107787-LIN> (Yao Qi's message of "Fri, 3 Feb 2017 17:45:21 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17020319-0032-0000-0000-00000716D209 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17020319-0033-0000-0000-0000234F668F Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-03_13:,, 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-1612050000 definitions=main-1702030185 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00106.txt.bz2 On Fri, Feb 03 2017, Yao Qi wrote: > On 17-01-26 14:12:25, Philipp Rudo wrote: [...] >> Andreas and I see the ravenscar-approach as a workaround for >> limitations in GDB. Thus while discussing it we thought about possible >> scenarios for the future which would be impossible to implement using >> this approach. The userspace-on-kernel was just meant to be an example. >> Other examples would be a Go target where the libthreaddb >> (POSIX-threads) and Go (goroutines) targets would compete on >> thread stratum. Or (for switching targets) a program that runs >> simultaneous on CPU and GPU and needs different targets for both code >> parts. >> > > IMO, https://sourceware.org/gdb/wiki/MultiTarget is the right way to > solve such problem. We can have one JTAG remote target debugging kernel, > and one GDBserver debugging user-space app on that machine. Interesting thought; I haven't looked much into that yet. This would only be applicable to live debugging, though, right? Philipp's and my line of thought was more directed towards an extension of the current target stack. We considered the possibility to have a target stack like this: - goroutine (Goroutine) - multi-thread (multi-threaded child process.) <-- linux-thread-db - lk-user (User-space task) <-- focuses on one user-space process - lk-thread (Linux kernel threads) <-- uses the kernel's task list - core (Local core dump file) <-- "threads" are actually CPUs - exec (Local exec file) - None (None) I.e., having multiple thread layers stacked one atop another. In this scenario the user should be able to specify which layer to focus on, going up and down in the hierarchy. When at the lk-thread layer, "info threads" would show kernel threads; when at the "goroutine" layer, it would show the Goroutines of a certain user-space process in the given system dump. Some of these layers would have their own notion of exec file, solibs, symbols, etc. The layers above "core" would generally apply to a running target as well. Of course, this is a long-range vision and not something I'd expect to be implemented as part of the Linux kernel debugging support. For now we'd just need the lk-thread layer, where mostly just the thread list needs to be overridden. And such a "thread-only" layering infrastructure would also be usable for a goroutine layer in a usual user-space debugging scenario. -- Andreas