This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Enable gdb to open Linux kernel dumps
- From: Kieran Bingham <kieran dot bingham at linaro dot org>
- To: Ales Novak <alnovak at suse dot cz>, gdb-patches at sourceware dot org
- Date: Mon, 1 Feb 2016 11:27:05 +0000
- Subject: Re: Enable gdb to open Linux kernel dumps
- Authentication-results: sourceware.org; auth=none
- References: <1454276692-7119-1-git-send-email-alnovak at suse dot cz>
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?
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