[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Crash-utility] gdb on KDUMP files



Six years ago Dave and I were discussing using gdb on KDUMP files:



At the time you weren’t sure of gdb could read 64bit elf headers.


I’m trying to look at KDUMP files with gdb and seeing similar problems.

I configured and built gdb with –enable-largefile but it didn’t help.

I also tried uncommenting _LARGE_FILE in gdb/config.h thought I doubt that’s correct.



Wondering what’s been done in the last six years on this. The kernel I’m

Running with is only using 4GB but is running in 64 bit mode.

Looking at the kexec src if seems KEXEC use to support:


            #   KEXEC_ARGS="--elf32-core-headers"


This was used to force the dump to be elf32 just so gdb could read the core file

It appears that this support was dropped for 64 bit machines by Vivek Goyak

Who seems was concerned for the health of the crash utility:




The Linux kernel Documentation/kdump/kdump.txt was last

Updated on July 4th of this year and clearly says that gdb can

Read KDUMP files but says the crash-dumping kernel should

Be started with --elf32-core-headers kernel option:


420 Analysis

421 ========


423 Before analyzing the dump image, you should reboot into a stable kernel.


425 You can do limited analysis using GDB on the dump file copied out of

426 /proc/vmcore. Use the debug vmlinux built with -g and run the following

427 command:


429    gdb vmlinux <dump-file>


431 Stack trace for the task on processor 0, register display, and memory

432 display work fine.


434 Note: GDB cannot analyze core files generated in ELF64 format for x86.

435 On systems with a maximum of 4GB of memory, you can generate

436 ELF32-format headers using the --elf32-core-headers kernel option on the

437 dump kernel.


But I can’t fine the string elf32-core-headers in the kernel source code.


Looking at the gdb Bugzilla page:




Reading a few bug reports seems to indicate that gdb supports 64 bit elf.


I’m just trying to get the normal stack back-trace to work,

With formal and local variables, from a crash dump as well

as mapping the normal kernel memory so I can follow list like

that for the the system tasks.


With gdb I can read the init_task with both gdb and crash but can only

follow the list with crash.


Anyone know what’s going on?



Pete/Piet Delaney                                              

O: +1 408 935-1813

C: +1 408 646-8557

H: +1 408 243-8872

Home Email: piet delaney gmail com





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]