This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
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-supportRegards Kieran Bingham
-- Ales Novak
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |