From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46853 invoked by alias); 18 Jan 2016 19:41:04 -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 46837 invoked by uid 89); 18 Jan 2016 19:41:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=on-demand, ondemand, divided, integration X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Jan 2016 19:41:02 +0000 Received: by mail-wm0-f47.google.com with SMTP id n5so79773300wmn.0 for ; Mon, 18 Jan 2016 11:41:02 -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:to:cc:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=i6ACe5jhV+7NiUx2B/8PkWn75aVwv+aVFJ9OhVgCtZQ=; b=A9Ajd5G98rSt7qKFxuIk2kksC9oHHN53Tgp8R3sMI96SD07iiJ8qjPxDHnWirad7An wrlcYK61cqgnL0Akcq9M3+sA7frbL4fhC4QhY8bjtyq19ylJH2J9tSHxoJzMo9cXnhCi +N1AFwCdB2s53L0jYQqHcLW5fd+057pt5q3eY+ZYcaFYwmTiD/ttQucfvU+OYQdo+4AX F4iWquYPnysd0pfLMb/8uA/XgvCXuBlvGihALvFxRrSrjq4/6flZ2kM9LyXvcSrle+zB J5cTSe1ckrlnwzym4uXkXcoHG2urZAmnDfm1V9dKbJcJ9YvBNcmbQnfhodjaJ6LwhaUU 3b1w== X-Gm-Message-State: AG10YOTFslUqb9boREwTWcJFqzIIEb8CQN5oc51grwamGkLZhxc7OxF7nN26nOIZxUDAE5Ot X-Received: by 10.28.5.213 with SMTP id 204mr14438433wmf.20.1453146059478; Mon, 18 Jan 2016 11:40:59 -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 s129sm17053275wmf.18.2016.01.18.11.40.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 11:40:58 -0800 (PST) From: Kieran Bingham X-Enigmail-Draft-Status: N1110 To: Yao Qi , gdb@sourceware.org Cc: Peter Griffin , Lee Jones , Russell Wayman , kernel@stlinux.com, Jan Kiszka , dje@google.com, alnovak@suse.cz Subject: GDB Linux Awareness revisited Message-ID: <569D3FCA.1060600@linaro.org> Date: Mon, 18 Jan 2016 19:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-01/txt/msg00028.txt.bz2 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. Since Peter's original investigation, Jan Kiszka's work has been integrated into the Kernel - paving the way for this work to follow on and I have started taking functionality from ST's LKD implementation and re-implementing the helper commands into linux.git/scripts/gdb/ The Linux Awareness support provided by STLinux can be (very roughly) divided into the following categories: * Information inspection helper commands - /proc/{version,cmdline,mounts,iomem,ioports,meminfo,interrupts} - These are currently being implemented and will be sent for review to LKML/Jan * Module Symbol loading and break pointing support - Fairly well supported already by the existing linux.git/scripts/gdb work * Kernel thread awareness - thread list integration, and thread switching support - kernel frame-unwinder - syscall frame-unwinder - breakpoint filtering hooks * User space awareness support - process information - MMU control, and switching (yes, this is a big topic) - userspace frame-unwinder and symbol loading where available The first topic, for which I hope to establish a bit more discussion and (even encourage) bike-shedding for the moment is the Kernel Thread Awareness. 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. Previous discussions on this have mentioned defining a consistent location in the kernel to allow catching any new threads which are created while running, however an important feature of LKD is to be able to attach to an existing (either running, or crashed) target, so we need to be able to enumerate threads at connection time as well. If we implement a breakpointing method to add new threads as they are created, will this provide us any benefit over iterating them on-demand (breakpoint, target-stop)? I would have argued that breakpointing on new process creation could have a performance impact on a running target, but I suspect it will not be too much of an impact. Following this method as option A: To implement this I could see that we would need to: Export the thread_list as an object through the python interface: - gdb.inferior.threads{.clearall, add, remove, iterator... } - Add some means of updating the registers for each thread On load (gdb.linux.__init__()) - gdb.inferior.threads.clearall() - for thread in linux.inferior.threads(): gdb.inferior.threads.add(thread) Establish constant points in the kernel to break point on for new process creation and destruction - Creation at the end of wake_up_new_task() - Destruction (near/at) the start of do_exit() As an alternative option B: STLinux LKD handles threads by repopulating the thread_list through the to_update_thread_list() op, when the target is connected, or stopped. This means that it doesn't rely on knowing when threads are created, and simply walks the process list updating the thread list before the (debug)user interacts with it. Doing this however, would require the ability to 'hook' in gdb from python to update the thread list, and this hook and more is already supported through the target-ops layers. Just to throw it into the mix for debate's sake; what do you think to the idea of implementing a python object to represent a high-stratum level target ops, which would allow us to (incrementally) implement hooks in python and provide linux (or other application) specific operation overrides. Any operations not implemented would simply delegate down to the layer below. This would allow us to almost mirror much more of the implementation from ST in the kernel - but potentially be more complicated, so I would like to hear peoples thoughts on it (especially if it's "You're crazy" or "This is a minefield" and "Thar be dragons") I feel like having the ability to access more hooks through establishing a target layer would provide more extensibility as we move forwards, but I also realise that it may not be a suitable method for generic thread level functionality for other simpler applications such as the Go subroutines, or other language implementations. I look forward to any replies, thoughts, or suggestions Regards -- Kieran Bingham