Re: Enable gdb to open Linux kernel dumps

[Jeff Mahoney <jeffm@suse.com>]

-----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-----