From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1519 invoked by alias); 5 Feb 2016 16:36:55 -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 1485 invoked by uid 89); 5 Feb 2016 16:36:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=chopped, holiday, UD:write, dry X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 05 Feb 2016 16:36:52 +0000 Received: by mail-wm0-f43.google.com with SMTP id p63so34340131wmp.1 for ; Fri, 05 Feb 2016 08:36:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=y9x4SuVV33stbnM51G0wmKB47Et0Qd1wWPJ06c5wvJI=; b=VadrQpeB0AMSWt6AKrbRuUDEMYFZv3x61OQmVz85MzhEH42Rz2UWKSbZHjW2dM4Eh8 fmC92IQ7V8ueZYjdtGtcrcZTHjgOrf+RXbaF7d1mwQH9GjLNHX7y0sNkXsKu9UeL8oo8 jbIesaOkt/Gc1L+J8vF6P1YySbgqOJNKwAruzCmQe4OLqSu4YhfIcuymTMrut02fUY4I 09PIoZGFMa6mWFLWafdX34AREZgwK9h1i2cDDgphkJss2HzDX3b/9LBIKMsw9kOH81c6 qmfZG0rXdAbdtJ4wEoDtJl6uisze39QI9RReMgRh7joCoi+STRANXgW60byax+H1HaU8 thpA== X-Gm-Message-State: AG10YOS/kcAeP7fR92n/U+y6HnePRFuVyHUTx9izD4fKKB1qen5rPot8I+XddXXZNvsUNg== X-Received: by 10.195.13.129 with SMTP id ey1mr14616132wjd.132.1454690209817; Fri, 05 Feb 2016 08:36:49 -0800 (PST) Received: from [192.168.0.31] (cpc87017-aztw30-2-0-cust65.18-1.cable.virginm.net. [92.232.232.66]) by smtp.gmail.com with ESMTPSA id e14sm17959336wmi.21.2016.02.05.08.36.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 08:36:48 -0800 (PST) Subject: Re: [RFC] Target Layer Python Interface To: Ales Novak , Kieran Bingham References: <56AB5C11.1020800@linaro.org> <56AE2674.5060101@redhat.com> <56AFA1B8.6060402@linaro.org> Cc: Phil Muldoon , gdb@sourceware.org, Yao Qi , Peter Griffin , Jan Kiszka , Lee Jones , Jeff Mahoney , ptesarik@suse.com From: Kieran Bingham X-Enigmail-Draft-Status: N1110 Message-ID: <56B4CF9F.5040103@gmail.com> Date: Fri, 05 Feb 2016 16:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00004.txt.bz2 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/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 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 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