From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111784 invoked by alias); 2 Feb 2016 09:12:45 -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 111767 invoked by uid 89); 2 Feb 2016 09:12:43 -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= 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; Tue, 02 Feb 2016 09:12:41 +0000 Received: by mail-wm0-f47.google.com with SMTP id l66so12493853wml.0 for ; Tue, 02 Feb 2016 01:12:41 -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=J5tMCOc6NK023pFLWY+904ikZJnYd/PnQGDBrSV0XJg=; b=Sju5B/nDx3utA0cG8I4Y/q859flIt4OnvL+GtITma/+it/g1s8hoX4hdc8JgC9WSAT 3GTp4OlFwz0uUwATLEc6RgjZFn8dAmojsm9HVUdXbXPEhFVi6ydO6aB0lMcz7lhaGhI+ JggcxDavVusUY3MUnP0nXSqf0yZI4RUqS+TT4b+t7oAB0Y4JKCXY+HGUROXJPxvEgHxi W0WVkNqjWvv8M3+xOGm3UwYsdQFGadVnAxjWVu0z8NOAAatwGEFwmV2L4B6HthUczf3I G/bMnu2KnVJpUca4vRlkw3CI/4/oDrprNEQNoxQ2OlSHknr5MznPbPWGFPSKw34BYk5B 3IGg== X-Gm-Message-State: AG10YOTW5u8MJx74C2w4GxjKDk0Jz8z3dgVoAIhwLYk15NyLfUpkyw3Mi6ikEbWQmSpF/g== X-Received: by 10.28.195.212 with SMTP id t203mr17935082wmf.46.1454404358903; Tue, 02 Feb 2016 01:12:38 -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 jc7sm443780wjb.33.2016.02.02.01.12.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 01:12:37 -0800 (PST) Subject: Re: Enable gdb to open Linux kernel dumps To: Jeff Mahoney , Ales Novak , Kieran Bingham References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <56AF4109.4070904@linaro.org> <56AF46C0.7000104@linaro.org> <56AF7332.2060702@suse.com> Cc: gdb-patches@sourceware.org, Peter Griffin , Lee Jones From: Kieran Bingham X-Enigmail-Draft-Status: N1110 Message-ID: <56B07305.7040905@gmail.com> Date: Tue, 02 Feb 2016 09:12: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: <56AF7332.2060702@suse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00042.txt.bz2 On 01/02/16 15:01, Jeff Mahoney wrote: > On 2/1/16 9:32 AM, Ales Novak wrote: >> On 2016-2-1 12:51, Kieran Bingham wrote: > >>> >>> 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. > >> Yes. Our primary intention is to open kdumps (i.e. dead images of >> the fallen kernels), but what can be shared between live and dead >> kernel debugging, should be shared... > >>>> 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. > >> No, it's Jeff Mahoney. His current efforts, which include Python >> binding to threads' regcaches and more, are at: > >> https://jeffm.io/git/cgit.cgi/gnu/binutils-gdb/log/ > >> And yes, you're right I've incorrectly removed autorship from some >> of his older patches (which in fact are not necessary for the >> current gdb-kdump to work, they are extending the Python binding). > >> And as you've already found, his older patches are at: > >> https://github.com/jeffmahoney/py-crash > > Hi guys - > > Ales gave me the heads up that you were discussing these. The github > repo is old and I haven't touched it in a year or so. The link to my > git server is the active one, but I should be clear that this is > currently a WIP from my perspective. I've been doing my work in the > rel-7.10.1-kdump branch, which is based on the gdb-7.10.1-release tag, > plus some SUSE patches to handle build-ids and external debuginfo files. Of course, unstable branches are expected at this point. Thanks for the reference. Have you used the kernel python commands at all (CONFIG_GDB_SCRIPTS)? I have implemented a few recently, although they're not quite finished yet (mainly just lx-interrupts left to complete, the radix-tree parser doesn't work yet) The expected working commands include: lx-version (although I think we've discovered a bug in gdb.Value.string()) lx-cmdline lx-iomem lx-ioports lx-meminfo lx-mounts I'd love to hear if they work for you on a non-running target, or if not, I can look at fixing them up. I believe these commands are probably even more useful on non-running targets than a running target! My python work lives at: https://git.linaro.org/people/kieran.bingham/linux.git gdb-patches > This branch is subject to rebasing as I make progess, but there should > be a stable base underneath it that I can condense and put into a > separate branch for public consumption. Of course the same applies to my branches I'm afraid :) -- Kieran > > -Jeff > > >>> >>> >>> >>>> >>>> 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 >>>> >>> > > > >