Re: gdb on KDUMP files

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 <[email protected]> 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