From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8219 invoked by alias); 5 Feb 2016 16:38:43 -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 8197 invoked by uid 89); 5 Feb 2016 16:38:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:5400, dry X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 05 Feb 2016 16:38:41 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 03CF3AABB; Fri, 5 Feb 2016 16:38:38 +0000 (UTC) Subject: Re: [RFC] Target Layer Python Interface To: Kieran Bingham , Ales Novak , Kieran Bingham References: <56AB5C11.1020800@linaro.org> <56AE2674.5060101@redhat.com> <56AFA1B8.6060402@linaro.org> <56B4CF9F.5040103@gmail.com> Cc: Phil Muldoon , gdb@sourceware.org, Yao Qi , Peter Griffin , Jan Kiszka , Lee Jones , ptesarik@suse.com From: Jeff Mahoney Message-ID: <56B4D00B.4060802@suse.com> Date: Fri, 05 Feb 2016 16:38:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B4CF9F.5040103@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00005.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/5/16 11:36 AM, Kieran Bingham wrote: > On 04/02/16 22:16, Ales Novak wrote: >> 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/efba160691273ef3c154711255 4584088b5dba75 >> >> >> >> (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 > > Were you going to say something else here? ... looks like it got > chopped! > > > Pulling the const's through is pretty neat, and that does make an > effective way to implement the read overrides to a file! > > > By the way, I'd started to add thread support - but I'm on holiday > now. > > Adding an add_thread(pid,lwp,tid) method to the inferior allows Ok, I have code doing that too. There's a big messy commit at the top of my repo last night that I'm going to refactor but I got most of this working. - -Jeff > def to_update_thread_list(self): > gdb.write("LX.to_update_thread_list\n") inferior = > gdb.selected_inferior() threads = inferior.threads() for task in > tasks.task_lists(): # Build ptid_t ... class object better here > still ptid = (inferior.pid, 0, task['pid']) # (pid, lwp, tid) if > ptid not in threads: gdb.write("- New Task [{} {}]\n" > .format(task['pid'], task['comm'].string())) > inferior.add_thread(ptid) > > > The 'if ptid not in tasks' is not working yet. That was going to be > next on my list. > > I think the comparison function is in the wrong place, it should > be implementing __contains__ instead of compare I think. > > Then it's just a matter of wiring up Jeff's Regcache ... > > If you're interested: My latest patches are at: > > http://git.linaro.org/people/kieran.bingham/binutils-gdb.git > lkd-python > > And the Kernel Awareness object is at > http://git.linaro.org/people/kieran.bingham/linux.git lkd-python > > Feel free to have a go at wiring up while I'm away if it's useful > to you. > > >> >> >>> 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). > > Indeed - but probably not too many hooks to implement to get > thread integration through python. > >> >>> 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. >> > > I'm glad you like the concept. I think it can work well with the > recent code Jeff has written. > > Although I may be slightly diverted for a bit when I get back from > holiday - so if it can go somewhere for you guys ... do have a go > until I return. (And let me know how it goes!) > > Regards > > Kieran > - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWtNAKAAoJEB57S2MheeWySjwP/RyE9xWolrCjFXo7f8yVFW8C aF/AP/zYa7A56fc9PtkdpDjqRzCnhoHK/9iBi62yN+F+gBdHOE13EytRLsdlimwi M+QNRqJf658oEho4s11G+WznCw5E8TLSBmx426nnOnfHDJ3umSo++az05WY3GX9e PH+UdUJRfEBLz7i0+Y2ZAv9b5oYUpLGwzXJJVwEHKYE6x30BWUUA/0NDUnaSRJpo +2b2xWLHUWGKis9po0H20zRyO5srAHPlwlNyA+p087GD1oRHttDExrSuYrHeikx1 6wfp7GVjFDl6D/iMa1f9Gf9QzoqI7zkwaGxX5C6ex7AmdNofRSVk/WaaZdzWuEgm 4xV9EDsy5BebU7rzDBE1dByW1Jo/3h8EQARS+RvuYA7xml8quqosKevH+iXDWFyZ aJG4bhhkTpV1+50AHQluJh7N8GxoUTBQTZtlgpbpSw2+0B/NyYlImZiLdQDesmkR TptueFkScOt7l5NZ3EkjglRaNURD1OyG+KP/t3Faf5EiyQrnAk/wkhtKX71R44Mk /F8PnlJRYDbPM9+VE326gH9VmXCLDDxqj2UMcAG0dNEYWlCeaYBZB90gLcQuxAvL ch28FAdI8qAJ85pMfXKEPrG9aEa55swTdLjmeIxcOsQMF8t0jfBigXfQ47TIhb/R Lt58vNw8Yu25Eh+/GujZ =UeOP -----END PGP SIGNATURE-----