From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39088 invoked by alias); 1 Feb 2016 11:27:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 39066 invoked by uid 89); 1 Feb 2016 11:27:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=complement, Hx-languages-length:2313, Fork, slab 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; Mon, 01 Feb 2016 11:27:09 +0000 Received: by mail-wm0-f47.google.com with SMTP id r129so65443331wmr.0 for ; Mon, 01 Feb 2016 03:27:08 -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:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8hRW5IbgCrNGxSsySubLb7ep2p3OfiviJkgtYBcEAdI=; b=GLuqy0+x9UuTwGfk50FyZ6/kV/yHnrfO3w9FSyIVX3OXCCj4JsXZU3pjhl4wI84GqB 8s1fSPjaHfuiUwL0FI1kTQuNshNFlBeHAh8PtpZGdq4tyV3VzAkVsEvzDrMZVX+9TYvl tHJOfIMsHm/cf5dHfd2mFGTDaPuYZQvKU6yglQT6O5I/gkLYEIi4qbVSaiz7YYZapPn0 +2j+pPhhYGM/wETuG7y/jgltQZ3+HLrlUzIr+ZXqQQgoDZZa80Ikt46uGKuHkbTTiXzo kY9dLqdnkIDPLJGJtsssSAz6bnfKAY3sAVCI15nqPpV7MlvjoCVpXyYG8nyKu0Y/8OV2 /IDA== X-Gm-Message-State: AG10YOTPUVvnwYcxR+hifbNJgeYcAZothUqtnMbNNn24aDJ0D0ygDSQqYdcrdDVaIrAfV1/E X-Received: by 10.28.100.134 with SMTP id y128mr2880880wmb.87.1454326026296; Mon, 01 Feb 2016 03:27:06 -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 jc7sm14141962wjb.33.2016.02.01.03.27.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 03:27:05 -0800 (PST) Subject: Re: Enable gdb to open Linux kernel dumps To: Ales Novak , gdb-patches@sourceware.org References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> From: Kieran Bingham X-Enigmail-Draft-Status: N1110 Message-ID: <56AF4109.4070904@linaro.org> Date: Mon, 01 Feb 2016 11:27: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: <1454276692-7119-1-git-send-email-alnovak@suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00005.txt.bz2 Hi Ales, I'm just checking out your tree now to try locally. It sounds like there is a high level of cross over in our work, but I believe our work can complement each other's if we work together. On 31/01/16 21:44, Ales Novak wrote: > Following patches are adding basic ability to access Linux kernel > dumps using the libkdumpfile library. They're creating new target > "kdump", so all one has to do is to provide appropriate debuginfo and > then run "target kdump /path/to/vmcore". > > The tasks of the dumped kernel are mapped to threads in gdb. > > Except for that, there's a code adding understanding of Linux SLAB > memory allocator, which means we can tell for the given address to > which SLAB does it belong, or list objects for give SLAB name - and > more. > > Patches are against "gdb-7.10-release" (but will apply elsewhere). > > Note: registers of task are fetched accordingly - either from the dump > metadata (the active tasks) or from their stacks. It should be noted > that as this mechanism varies amongst the kernel versions and > configurations, my naive implementation currently covers only the > dumps I encounter, handling of different kernel versions is to be > added. In the work that I am doing, I had expected this to be done in python for exactly this reason. The kernel version specifics, (and architecture specifics) can then live alongside their respective trees. > In the near future, our plan is to remove the clumsy C-code handling > this and reimplement it in Python - only the binding to certain gdb > structures (e.g. thread, regcache) has to be added. A colleague of > mine is already working on that. This sounds exactly like the work I am doing right now. Could you pass on my details to your colleague so we can discuss? I recently made a posting on gdb@ suggesting the addition of a gdb.Target object to work towards implementing this, and I have been liasing with Jan Kiszka to manage the Linux/scripts/gdb/ integration. > The github home of these patches is at: > > https://github.com/alesax/gdb-kdump/tree/for-next > > libkdumpfile lives at: > > https://github.com/ptesarik/libkdumpfile > > Fork adding the SLAB support lives at: > > https://github.com/tehcaster/gdb-kdump/tree/slab-support > > Regards Kieran Bingham