This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb on KDUMP files
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: "Discussion list for crash utility usage\, maintenance and development" <crash-utility at redhat dot com>
- Cc: GDB Development <gdb at sourceware dot org>
- Date: Fri, 17 Oct 2014 13:24:01 +0200
- Subject: Re: gdb on KDUMP files
- Authentication-results: sourceware.org; auth=none
- References: <b3a5a177772a47e8bf740e3422befa6a at BY2PR04MB173 dot namprd04 dot prod dot outlook dot com> <20141002102700 dot 3eba84a5 at suse dot cz>
Petr,
I'm copying the GDB mailing list, because this is probably of interest
to the GDB community as well.
On Thu, Oct 02 2014, Petr Tesarik wrote:
> On Thu, 2 Oct 2014 03:18:55 +0000
> Pete Delaney <pdelaney@silver-peak.com> wrote:
>
>> Hi:
>>
>> Six years ago Dave and I were discussing using gdb on KDUMP files:
>>[...]
>>
>> Anyone know what's going on?
>
> [...]
>
> I'm glad you're interested in using GDB to read kernel dump files,
> especially if you're willing to make it work for real. I have proposed
> more than once that the crash utility be re-implemented in pure gdb.
Incidentally, I've tossed this idea around as well. Do you have a
pointer to one of these proposals (and discussions, if any)?
> Last time I looked (approx. 1.5 years ago) the main missing pieces were:
>
> 1. Use of physical addresses (described above)
I guess this includes the capability to translate virtual to physical
addresses, using the kernel's page tables?
> 2. Support for multiple virtual address spaces (for different process
> contexts)
One way of dealing with this might be to represent the different virtual
address spaces as multiple inferiors.
> 3. Ability to read compressed kdump files
> 4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
In addition, there might be:
5. Support kernel modules and represent them as "shared objects".
6. Understand the kernel's task structures. Represent multiple tasks
within the same "inferior" as threads in GDB.
7. Format functions: Extract information from kernel data structures
and show it in a digested, more readable, form. Perhaps such
functions can be implemented as Python scripts.
Among others, I'd envision the following GDB commands:
file <vmlinux> Specify vmlinux Elf image
target kdump <kdump-file> Load kdump
info sharedlibrary List kernel modules
info inferiors List address spaces ("processes")
inferior <id> Switch to certain address space
info threads List threads in current address space
bt, up, down, frame <id> Usual behavior
generate-core-file Write core dump for the current inferior
linux cmdline Show kernel command line
linux kmesg Show kernel message buffer
linux cpuinfo List CPUs and their state
linux ... Other format functions
All of this together may not be a small task, and there are still
various open questions, e.g. how to deal with interrupt contexts. But I
think we could already provide useful functionality with a smaller
initial development stage and defer features like multiple address space
support, PAE support, format functions, etc., to a later stage.
--
Andreas