From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86187 invoked by alias); 31 Jan 2016 15:21:30 -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 86172 invoked by uid 89); 31 Jan 2016 15:21:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=opens, exciting, balancing, Layer X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 31 Jan 2016 15:21:28 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0169F70D62; Sun, 31 Jan 2016 15:21:26 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-21.ams2.redhat.com [10.36.112.21]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0VFLOld025054; Sun, 31 Jan 2016 10:21:25 -0500 Subject: Re: [RFC] Target Layer Python Interface To: Kieran Bingham , gdb@sourceware.org References: <56AB5C11.1020800@linaro.org> From: Phil Muldoon Cc: Yao Qi , Peter Griffin Message-ID: <56AE2674.5060101@redhat.com> Date: Sun, 31 Jan 2016 15:21:00 -0000 MIME-Version: 1.0 In-Reply-To: <56AB5C11.1020800@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00059.txt.bz2 On 29/01/16 12:33, Kieran Bingham wrote: > 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) A snippet would be cool to see what you are doing here, if possible. > However, whilst these threads were added, they were immediately removed > by the next call to (target).to_update_thread_list() I presume you mean GDB's accounting of them, not the actual threads? > 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. At this point, there's just not enough information to form an opinion of this being a good thing or a bad thing. Do you have an interface in mind? An API? > > 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. Interesting! > Some of the interface can even hopefully be autogenerated by a > make-target-delegate equivalent Presume you mean the Python C code/interface? > 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. This is something that is always a balancing act with Python GDB. There are, as you allude too, some parts of GDB that are not suitable to be extended to the Python layer, and some parts that while theoretically OK, need a little work to make safe and accessible in a Pythonic way. I can't comment without more details though. My initial reaction though is yeah, this sounds useful and exciting. > 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!) The versioned API would also need some documenting first. I ask a few questions here that might provide you with some additional work! Sorry ;) But I find this an interesting proposal. Cheers Phil