From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87477 invoked by alias); 4 Feb 2016 22:16:19 -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 87466 invoked by uid 89); 4 Feb 2016 22:16:18 -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=nam, pursuing, repeatable, ftr 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; Thu, 04 Feb 2016 22:16:17 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 23A5CAB4B; Thu, 4 Feb 2016 22:16:14 +0000 (UTC) Date: Thu, 04 Feb 2016 22:16:00 -0000 From: Ales Novak To: Kieran Bingham cc: Phil Muldoon , gdb@sourceware.org, Yao Qi , Peter Griffin , Jan Kiszka , Lee Jones , Jeff Mahoney , ptesarik@suse.com Subject: Re: [RFC] Target Layer Python Interface In-Reply-To: <56AFA1B8.6060402@linaro.org> Message-ID: References: <56AB5C11.1020800@linaro.org> <56AE2674.5060101@redhat.com> <56AFA1B8.6060402@linaro.org> User-Agent: Alpine 2.03 (LSU 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00003.txt.bz2 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