[RFC] Target Layer Python Interface

[Kieran Bingham <kieran.bingham@linaro.org>]

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