Andreas Arnez
2014-10-17 11:24:01 UTC
Petr,
I'm copying the GDB mailing list, because this is probably of interest
to the GDB community as well.
pointer to one of these proposals (and discussions, if any)?
addresses, using the kernel's page tables?
address spaces as multiple inferiors.
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
I'm copying the GDB mailing list, because this is probably of interest
to the GDB community as well.
On Thu, 2 Oct 2014 03:18:55 +0000
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[...]
Anyone know what's going on?
[...]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.
pointer to one of these proposals (and discussions, if any)?
1. Use of physical addresses (described above)
I guess this includes the capability to translate virtual to physicaladdresses, 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 virtualcontexts)
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:4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
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