Re: [RFC] Target Layer Python Interface

Hello,

On 2016-2-1 19:19, Kieran Bingham wrote:
> [...]
> The API, I would expect to match that of the Target API operations. I
> would expect a one-to-one mapping of (required) operation names to
> perform functions.
>
> For instance, to support thread listings, I would expect something along
> the lines of:
>
> .to_update_thread_list
> .to_pid_to_str
> .to_extra_thread_info
> .to_thread_alive
> .to_fetch_registers
> ...

FTR I've slightly tweaked your gdb.Target to process "to_xfer_partial", 
the respective commit is:

https://github.com/alesax/gdb-kdump/commit/efba160691273ef3c1547112554584088b5dba75

(and the respective branch is "gdb-target")

Then the target code which is accessing virtual (!) memory of the kernel 
dump on the disk (using libkdumpfile library) is as small as:

===
from gdb import Target
from _kdumpfile import kdumpfile

class MyTarget(Target):
     def __init__(self, fil):
         self.kdump = kdumpfile(fil)
         self.kdump.symbol_func = \
             lambda nam: long(gdb.lookup_minimal_symbol(nam).value())
         self.kdump.vtop_init()
         super(MyTarget, self).__init__()
     def to_xfer_partial(self, obj, annex, readbuf, writebuf, offset, ln):
         if obj == self.TARGET_OBJECT_MEMORY:
             r = self.kdump.read (self.kdump.KDUMP_KVADDR, offset, ln)
             readbuf[:] = r
         return ln

MyTarget(file("/tmp/vmcore"))
===

which is really nice, I'd say. Now it would be interesting


> And having seen Jeff's work today, we could utilise Jeff's py-regcache
> object quite effectively
>
> [...]
>
> Yes, I suspect some of the functionality to implement will be very
> repeatable throughout each of the operation call implementations.
>
>
> However, the more I look into it - the more I see each function is
> likely to need very specific bindings, as it is not simple passing from
> c function to c function.

Yes, the mentioned to_xfer_partial being a good example (of not simple 
passing).

> Perhaps we can factor out commonality as we go - and try to keep as DRY
> as possible, but I suspect it will be an iterative implementation process.
>
>
>> I can't comment without more details though. My initial reaction
>> though is yeah, this sounds useful and exciting.
>
> Perfect :)

Yes, this definitely is worth pursuing.

-- 
Ales Novak
SUSE L3 Team