From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119923 invoked by alias); 2 Feb 2016 09:15:54 -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 119903 invoked by uid 89); 2 Feb 2016 09:15:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=follow-ups, followups, Extensions, thankyou X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 02 Feb 2016 09:15:51 +0000 Received: by mail-wm0-f48.google.com with SMTP id p63so107736341wmp.1 for ; Tue, 02 Feb 2016 01:15:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=o3yJZhRsKC3sae0DQfeBt1Q+MHYqAXplV8r4g6TaryQ=; b=b9sGXK7DOzFXzbGmz0p+C57MvfxhBsY7bR4zESjZJXfgad56KH9NKANJG8BTY2V0Bs mjMYe56Hreg8+Doug1S07YkvZ2Y98kRm0zYXpFF63FGYgVz9Tpre7vmIQ4h82TqKrajl DKNiQcVwnWCBvfPn3porUF4jNf/QmPtAfIC+xcToUn/d7FMshROxZPwdViBBUntpZnBX 81LbWI+5VmZs6DfkXM+ZJkA6S9++lnBJcp2RX4BAiApaen+kxJSu131PdB5Qens20mhE z/0j2ySR7IyPbxK6VQrRmFprxnEzR/oC+JJSyDSuQ9LkEr6KGQ4vxZ84/a8K+jDWtujH vFZA== X-Gm-Message-State: AG10YORz9ZIODZ1qj8JtRPybaUfHGsxZUBgQ+Ogu1uTdjqbSxIrO3xnQSEcGktsWOX387rjD X-Received: by 10.28.73.70 with SMTP id w67mr15506776wma.31.1454404548514; Tue, 02 Feb 2016 01:15:48 -0800 (PST) Received: from [192.168.0.31] (cpc87017-aztw30-2-0-cust65.18-1.cable.virginm.net. [92.232.232.66]) by smtp.gmail.com with ESMTPSA id lc3sm499577wjb.7.2016.02.02.01.15.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 01:15:47 -0800 (PST) From: Kieran Bingham Subject: Re: GDB Linux Awareness revisited To: Andreas Arnez , gdb@sourceware.org References: <569D3FCA.1060600@linaro.org> Cc: Yao Qi , gdb@sourceware.org, Peter Griffin , Lee Jones , Russell Wayman , kernel@stlinux.com, Jan Kiszka , dje@google.com, alnovak@suse.cz, Jeff Mahoney X-Enigmail-Draft-Status: N1110 Message-ID: <56B073C2.1090104@linaro.org> Date: Tue, 02 Feb 2016 09:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00001.txt.bz2 On 29/01/16 19:09, Andreas Arnez wrote: > 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. The code from ST, which has been used since Linux 2.6.32 has already been littered with various conditional paths for versions. This is partly why I am trying to get as much of the kernel specific code to function correctly in the python layer, so that it can live side by side in the correct versions. Backporting to earlier versions can become much cleaner, with simply making the adjustments on that branch, rather than a wave of conditionals. By ensuring that kernel specific code lives in the kernel (therefore as Python) GDB will not be tied to supporting only a select set of kernel versions. > 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? Yes, for the most part. STLinuxLKD does in fact implement various memory functions including virtual/physical address translations. It provided the ability to control the MMU and adjust accordingly. My discussions with Jan at the weekend suggested that this may not be a desired route forward so it will need some more consideration. And of course these were ARMv7 specific of course, and we would have to look at how things get layered to consider performing mappings in the future. > [...] > >> 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 Thankyou, I had not seen this. However, it does look very close of course to how they tasks are currently listed in linux/scripts/gdb/ so perhaps we could work towards a common way to implement this. Have you seen my RFC regarding the gdb.Target layer object representation? A python class here could iterate the tasks, and parse the information for the info threads through hooks on the .to_update_thread_list target operation and it's pals ... > 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 ". Ok - so perhaps we could fix this with GoSubroutineAwareness(gdb.Target) > Also note that gccgo has a different runtime and is not supported by > the script above. And perhaps a companion GccGoSubroutineAwareness(gdb.Target) could be written to support this. :) > -- > Andreas Thankyou for your input, I see you have been following these topics for a while, and you appear to be providing some of the glue between the separate parties involved! Regards Kieran