gdb-kdump (and libkdumpfile) needs a plenty of improvements and tasks to be done. For HackWeek 13, Vlastimil chose to work on SLAB memory support, Petr, amongst other things, reorganized the libkdumpfile code and alnovak begun with libkdumpfile's ppc64 support. Our status in 4/5 of HackWeek 13:

SLAB

Vlastimil has looked into support for SLAB, which means that when printing a pointer, gdb-kdump should recognize whether it points to an kmem object, and what is the object's starting address and status (allocated, free, on percpu/shared/alien array_cache). Basically an equivalent to the crash commands 'kmem -s' or 'kmem -S' and related options affecting printing pointers. The current status is:

• very basic struct page and memmap support needed to map object to its struct page and testing for PG_slab and PG_tail
• parsing the relevant SLAB structures: kmem_cache, kmem_list3, array_cache, slab...
• (in progress) employing gdb's hash tables to cache the parsed SLAB caches and marking objects as belonging to one of the array_caches - while determining whether object is allocated or free is relatively fast, consulting the array_caches again and again on each query would be costly. The hash tables will also allow recognizing objects that referenced more than once in the array_caches (due to a double-free).

The plan for friday is to finish the hash tables and hopefully the hook for printing pointers. If not, this should take just 1-2 extra days. There are more ideas that would be useful to implement, which would take at least another week.

• test on newer kernel versions (SLE11-SP3 was used in development), generalize code to adapt to SLAB implementation changes when needed
• more thorough sanity checking of all traversed structures, reporting all inconsistencies (this is where crash also doesn't seem quite thorough)
• python script bindings to work with the parsed structures
• a python script that would attempt to assign a struct to each object in one of the anonymous kmem caches. The idea is to start from the named caches and symbols as roots, and traverse the fields that are unambiguous pointers with known struct. See how much we can classify. This would be potentially very useful in crash dump analysis.

github

libkdumpfile for PPC64

Vtop seems to work, yet with some limitations (64k pages only, and without "book 3e" specialities, hugepages are problematic).

Plan for friday: fix fix and fix, also look for gdb-kdump part, i.e. learn how are the registers stored on the stack.

gdb-kdump

Small fixes, autoconf script updated in order to correctly search for libkdumpfile.

Still a lot of TODO:

• gdb-kdump: send patchset to gdb-patches
• libkdumpfile: s390x - dig registers of running CPUs
• gdb-kdump: python base library
• gdb-kdump: python examples
• libkdumpfile: python bindings
• gdb-kdump: multiple stacks (i.e. NMI, IRQ, doublefault ...) management
• gdb-kdump: config.gz access