Re: Enable gdb to open Linux kernel dumps

[Kieran Bingham <kieranbingham at gmail dot com>]

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