From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73589 invoked by alias); 1 Feb 2016 15:01:17 -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 73568 invoked by uid 89); 1 Feb 2016 15:01:17 -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,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hash, Darwin, darwin, fqh 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; Mon, 01 Feb 2016 15:01:13 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2F80FAC01; Mon, 1 Feb 2016 15:01:10 +0000 (UTC) Subject: Re: Enable gdb to open Linux kernel dumps To: Ales Novak , Kieran Bingham References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <56AF4109.4070904@linaro.org> <56AF46C0.7000104@linaro.org> Cc: gdb-patches@sourceware.org From: Jeff Mahoney X-Enigmail-Draft-Status: N1110 Message-ID: <56AF7332.2060702@suse.com> Date: Mon, 01 Feb 2016 15:01:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00013.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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. - -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 >>> >> > - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWr3MyAAoJEB57S2MheeWyZiMQAJOV3EqzTFwRRMQbfxjHLq1+ /CWB8N3nAiwh40rHWenHkjYDA34zN6mY2lQoS1PQVZHt1SmOc6qujQmC+s7GAx/Y MRnSqCp5F6err3bCLFx1tB/IhFboTFX8UfQvtjl9mNW5ghpA/Jyn5ler6h8A58Rc yE71nstYYUKEyjn2tYCHTRVtE4d5wAOWhMlrhvX3iEvy5Etl6WcV0uXrznhFoMyd QFZNJrYXSvLGgiZ9vToGOnpVk9eNHY7hfaxPViO7W0W++VxttbLQ4pbTzO7qMP3A r2ajW0Cavm96YMBiVyNvSzfz4ANp4EQPL8b6ZnYyou4qUMhR+4RX9XbSc7TnnDhx zUwchdDA8iiOw0Y1xc2Z2XTRUW6NgbhvHn5uKnUWkVFuZlXWb9WVjMpu34uYfJ3C oQYZ3/93llf8nh9OajwzlqTIw+af2hxZDwFS9dc7uYz3SIC6CcXOj8wBOQ3U02n1 1fVYXSDKI0k4unuJnIvfcZ6hs9i8cdNWQr03dcrwwHoe3Uc4CJT/FLz9dpH6ZQXV fQh/csaGuRS3V/DPnu+hQdo93NlPe95KHbx0nmU6/BGlE0g2DrzLf9z8G1/iEof1 QPew3gCdPWmJJ73JT3KqMrXfs5o0C9GSLZDkGADZkeF1Bmq8Qu+p9S88DuWJY9ja KcfFj6E8MJw6JXmnUc4K =WLYU -----END PGP SIGNATURE-----