From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128970 invoked by alias); 29 Jan 2016 12:33:29 -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 128937 invoked by uid 89); 29 Jan 2016 12:33:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 spammy=opens, audience, integration, Interface X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 29 Jan 2016 12:33:25 +0000 Received: by mail-wm0-f41.google.com with SMTP id l66so52494998wml.0 for ; Fri, 29 Jan 2016 04:33:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=ky6z92LppZLsOzhoX+XVcuEPr6+y2OUgp/7bXH4WjBY=; b=K66/04ujku9MaqjdCfhds5HM+NYaR9fnpqNCWJEzhjzqBWipsAzQZHbBe7wTzYxVzb uiMKUp67UiRgitjxYIJ5W5snHooM7uLsd6qpFYs1BC8I1Cm4bgSAP7nmREtyCeeJ7p0G veimjcsN91if1YUBb1KJ56bbR4CklRvqC+sE0tWFPQBt7D00L5ZjBMOFSURA/alnfoYR zX3yLbL1ODiX6vuyUulb1S3A2WLkTHuOu7W/rFpCPS1MqRE3fe/+4cXno6vto/jIXwBs NKJHLWZvqDKo1zYpOT3izVngWBeLKQgMaZmWNKRgOZ05PtZvP53j8q7jkWzSmZ3vozZM Bq4w== X-Gm-Message-State: AG10YOQubdyRXC7TTbiqbz5tnpoKwEIYTl2GD23oYN9/g32TYML7n63VoNaw8HMffhtj6TXg X-Received: by 10.28.176.131 with SMTP id z125mr9322454wme.5.1454070802845; Fri, 29 Jan 2016 04:33:22 -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 17sm7294556wmy.15.2016.01.29.04.33.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 04:33:22 -0800 (PST) To: gdb@sourceware.org Cc: Yao Qi , Peter Griffin From: Kieran Bingham Subject: [RFC] Target Layer Python Interface X-Enigmail-Draft-Status: N1110 Message-ID: <56AB5C11.1020800@linaro.org> Date: Fri, 29 Jan 2016 12:33: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/msg00057.txt.bz2 While investigating how to get Python to define the threads presented by the application layer (in my instance the linux kernel) I found that I could create threads with a call from Python, (by writing a hook through the inferior object) However, whilst these threads were added, they were immediately removed by the next call to (target).to_update_thread_list() This has led me to believe I should create a Python Target layer interface, which I have started, and have been able to register a target, and provide Python bindings so that (currently _to_thread_name) calls into the python layer object, and returns a new name. My intention is that this can be extended to provide the whole set of target operations allowing me to implement much of the Linux Kernel Debugger interface in Python. Through this layer, we can even tackle some of the issues with memory address spaces, by adding appropriate hooks to adjust MMU context, or interpret page tables through the relevant target_ops hooks. Some of the interface can even hopefully be autogenerated by a make-target-delegate equivalent This layer interface, will mean that I can provide a Linux Thread Awareness layer to implement a thread_stratum layer, and can even go further to provide extra layers for other functionality later. With a example implementation looking like the start of this: ====================================================================== class LxAwarenessTarget(gdb.Target): """ Provide a Linux Awareness Target Layer This will provide hooks for our Thread implementation, and later extra architecture specific target layers to handle memory """ def __init__(self): self.shortname = "LxThreads" self.longname = "Linux Thread Integration Layer" super(LxAwarenessTarget, self).__init__(gdb.Stratums.thread) def to_thread_name(self, gdbthread): return "A thread" ... (gdb) maintenance print target-stack The current target stack is: - LxThreads (Linux Thread Integration Layer) - remote (Remote serial target in gdb-specific protocol) - exec (Local exec file) - None (None) (gdb) info threads Id Target Id Frame 2 Thread 2 "A thread" (CPU#1 [halted ]) default_idle () at /home/linaro/sources/linux/arch/x86/kernel/process.c:305 * 1 Thread 1 "A thread" (CPU#0 [halted ]) default_idle () at /home/linaro/sources/linux/arch/x86/kernel/process.c:305 ====================================================================== By implementing this as a layer, it will also allow other implementations from OS's or targets to define their specific implementation detail in their source trees Before I head too much further, I wanted to ask the opinions of the community as to whether this is an acceptable interface to implement, or if it opens up too much of the GDB internals, to external dependencies. Whilst the target layer may be defined as 'fairly' stable - It has undergone changes, and this may cause issues if exposed to an external interface. We could of course tackle this by providing a versioned API which would allow adaptation in the Python objects, but I thought it was a big enough question that it should be posed to a wider audience (wider than just me!) Regards -- Kieran