From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58644 invoked by alias); 29 Jan 2016 19:09:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 58634 invoked by uid 89); 29 Jan 2016 19:09:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=follow-ups, followups, 00000, slides X-HELO: e06smtp12.uk.ibm.com Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 29 Jan 2016 19:09:36 +0000 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 29 Jan 2016 19:09:33 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 29 Jan 2016 19:09:31 -0000 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0299217D8042 for ; Fri, 29 Jan 2016 19:09:41 +0000 (GMT) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0TJ9VrW12386624 for ; Fri, 29 Jan 2016 19:09:31 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0TJ9UZE027010 for ; Fri, 29 Jan 2016 12:09:31 -0700 Received: from oc1027705133.ibm.com (dyn-9-152-212-180.boeblingen.de.ibm.com [9.152.212.180]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0TJ9TPV026994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2016 12:09:30 -0700 From: Andreas Arnez To: Kieran Bingham Cc: Yao Qi , gdb@sourceware.org, Peter Griffin , Lee Jones , Russell Wayman , kernel@stlinux.com, Jan Kiszka , dje@google.com, alnovak@suse.cz Subject: Re: GDB Linux Awareness revisited References: <569D3FCA.1060600@linaro.org> Date: Fri, 29 Jan 2016 19:09:00 -0000 In-Reply-To: <569D3FCA.1060600@linaro.org> (Kieran Bingham's message of "Mon, 18 Jan 2016 19:40:58 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16012919-0009-0000-0000-000007743A56 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00058.txt.bz2 On Mon, Jan 18 2016, Kieran Bingham wrote: > Hi Yao, et al, > > I am currently working through the GDB Linux Awareness project, started > by Peter Griffin and originally discussed in the gdb{,-patches} > mailinglist in June 2015 > [https://sourceware.org/ml/gdb-patches/2015-06/msg00040.html] > > The main points that I took from that discussion were that it was a > valuable contribution to make, and that the main focus should be on > writing the support using the Python Extensions, so my hope is to try to > extend the python interfaces where possible to maximise the kernel > specific code living in the kernel. I am sure everybody agrees that "Linux awareness" would be a valuable contribution to GDB. And I doubt that you will encounter much opposition against adding kernel specific code to GDB, unless it is actually kernel *version* specific. IMO, then it depends on the expected amount of change over time. Just in case you haven't seen, I presented this slide deck at the last GNU Tools Cauldron: https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=get&target=Andreas+Arnez_+Debugging+Linux+kernel+dumps+with+GDB.pdf These slides were mainly intended to give food for thought and get the discussion going. There were some follow-ups on the GDB mailing list, e.g.: * About the gdb-kdump project: https://sourceware.org/ml/gdb/2015-09/threads.html#00014 * About Linux Awareness and LKD: https://sourceware.org/ml/gdb/2015-10/threads.html#00000 [...] > * Module Symbol loading and break pointing support > - Fairly well supported already by the existing linux.git/scripts/gdb > work This only works if the debug target uses *virtual* rather than physical kernel addresses, right? Is this typical for the scenarios you want to support? [...] > Support for the frame-unwinders are already exposed via the Python > API's, however access to the gdb thread_list is not yet available, and > this is where I will be hacking next. > > > Briefly chatting on IRC, Pedro mentioned that exposing this support > could help for other runtimes such as Go subroutines, so my hope is that > this work will be re-usable in other places too. Right, such a Python interface may be usable for Goroutines. Here's the Golang community's current approach to this: https://golang.org/src/runtime/runtime-gdb.py Due to the Python interface's limitations, that script defines a command "info goroutines" instead of supporting "info threads". It also offers a command prefix "goroutine ", rather than allowing the user to switch contexts with "thread ". Also note that gccgo has a different runtime and is not supported by the script above. -- Andreas