Re: [RFC] Target Layer Python Interface

[Phil Muldoon <pmuldoon at redhat dot com>]

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