From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90194 invoked by alias); 5 Feb 2016 16:47:16 -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 90179 invoked by uid 89); 5 Feb 2016 16:47:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Might X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 05 Feb 2016 16:47:14 +0000 Received: by mail-wm0-f47.google.com with SMTP id 128so78465271wmz.1 for ; Fri, 05 Feb 2016 08:47:13 -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=9D+cTlY/qso2pJNzrwj4/MxIGrEh/HzvKJM3iZgx8UY=; b=ZqJ9JjLLG+pR3mNJKGwVzmoj+DbSMndEp63cLSfjG0K6EqdGEBAuhFpTFz8cbBtCrd 3h5TwYlWQCPPVeNqiVmpMvyAWE6UMR67wC/VgJ/BAcdK0PDakJn7TAgWU88IZEHZouv7 uP+BCw5fyGqpEQAfKZR6ertGKVne+Nc6XbVwFw8EqiyNeyXe6Nl2CTVqS59RFjHWXKg8 6O2uiG4cZw9JuvUdoSO8fyNQdXmjpNiKquBb6CDlGewtmMTY8Iazd/15nisOPAamjB6u Qe1m2ZxAwxAsUJiaH5Rk8az2RTA+70eKlD1ZySYMYcCBmn9QAymoaWpIM2fCeshZRuyG HN+w== X-Gm-Message-State: AG10YOR8JPJL88WZtD6zshelLVFOUl6KgaOtprpabZ8lAi1s0Rt07flp+5a0teoS6hX6kOoL X-Received: by 10.194.157.3 with SMTP id wi3mr14956688wjb.30.1454690831120; Fri, 05 Feb 2016 08:47:11 -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 n131sm17810479wmf.9.2016.02.05.08.47.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 08:47:10 -0800 (PST) Subject: Re: [RFC] Target Layer Python Interface To: Jeff Mahoney , Kieran Bingham , Ales Novak References: <56AB5C11.1020800@linaro.org> <56AE2674.5060101@redhat.com> <56AFA1B8.6060402@linaro.org> <56B4CF9F.5040103@gmail.com> <56B4D00B.4060802@suse.com> Cc: Phil Muldoon , gdb@sourceware.org, Yao Qi , Peter Griffin , Jan Kiszka , Lee Jones , ptesarik@suse.com From: Kieran Bingham X-Enigmail-Draft-Status: N1110 Message-ID: <56B4D20D.7010502@linaro.org> Date: Fri, 05 Feb 2016 16:47: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: <56B4D00B.4060802@suse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00006.txt.bz2 On 05/02/16 16:38, Jeff Mahoney wrote: > 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. Fantastic, you've probably spent more time on it than me so I'll bet your version works before I'm back from holiday! I'll go have a quick look now. :D I felt a bit like we need a bit better encapsulation on the ptid_t object. Might need a small object to wrap it up for passing around instead of just throwing Tuples everywhere. -- Kieran > > -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 > > > >