From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76168 invoked by alias); 1 Feb 2016 11:51:35 -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 76155 invoked by uid 89); 1 Feb 2016 11:51:34 -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=arnez, Arnez, aha, gbd X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 01 Feb 2016 11:51:33 +0000 Received: by mail-wm0-f51.google.com with SMTP id l66so67181105wml.0 for ; Mon, 01 Feb 2016 03:51:32 -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=7xglBCvQgorjduxWs7xEE6/jhO45ZZbhAJvsjZKsSiM=; b=gjuqHlkg5ErdwBszS0MvZig4WL+Y8kDPfdfwaDKyJGZPD8xlcu3qXw3NWXhkgiducB 1vnnE3FTy6va8R7qZoVmW1hrTUCeVQzmWuR6JnYQHj0t1OoyruuW64FQBdcNPtyjVN1E viDOBzp/SvSeGUUM+b3Rwnr1DdoRe4Z5CFXxBT/ivOXXbS+LON8341+VCp1G8b62hhih Nt1zFeJqw5T2uDqQ2h4tyBQ8XeFZ7C6H5Zrsq8btQaax1+zUfBdu9PWluyULhiLBot8I 2Q2QMnexyLlBSPqrp6bZR6dujoNNQv1ZeCM4WCtlGJEGCv2mHvV4aji+K76i1B21xOvA FjZA== X-Gm-Message-State: AG10YOR3G97oyw8gebmyGa8LpsBv7K0YkS4s56lFmTK0LcN6T/ELFW2u2GF0TEBmdOoeLKuj X-Received: by 10.28.48.19 with SMTP id w19mr4865621wmw.18.1454327490106; Mon, 01 Feb 2016 03:51:30 -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 v22sm4919797wmv.12.2016.02.01.03.51.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 03:51:29 -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> <56AF4109.4070904@linaro.org> From: Kieran Bingham Message-ID: <56AF46C0.7000104@linaro.org> Date: Mon, 01 Feb 2016 11:51: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: <56AF4109.4070904@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00006.txt.bz2 On 01/02/16 11:27, Kieran Bingham wrote: > 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? Aha, or is your colleague Andreas Arnez? I'm just about to reply to his mail over on gbd@ next. > > 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 >