10:18 p.m.
Hi:
Six years ago Dave and I were discussing using gdb on KDUMP files:
http://www.redhat.com/archives/crash-utility/2008-March/msg00039.html
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:
http://lse.sourceforge.net/kdump/patches/1.101-kdump10/broken-out/x86_64-...
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 ========
422
423 Before analyzing the dump image, you should reboot into a stable kernel.
424
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:
428
429 gdb vmlinux <dump-file>
430
431 Stack trace for the task on processor 0, register display, and memory
432 display work fine.
433
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:
https://sourceware.org/bugzilla/buglist.cgi?quicksearch=elf64
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<mailto:piet.delaney@gmail.com>
[Unity_Email_Sig]
3:27 a.m.
On Thu, 2 Oct 2014 03:18:55 +0000
Pete Delaney <pdelaney(a)silver-peak.com> wrote:
Hi:
Six years ago Dave and I were discussing using gdb on KDUMP files:
[...]
Anyone know what's going on?
Yes, sure. GDB works very differently from crash. There main conceptual
difference is that GDB only handles with VIRTUAL addresses, while the
crash utility first translates everything to PHYSICAL addresses.
Consequently, GDB ignores the PhysAddr field in ELF program headers,
and crash ignores the VirtAddr field.
I have looked at some of my ELF dump files, and it seems to me that
VirtAddr is not filled correctly, except for kernel text and static
data (address range 0xffffffff80000000-0xffffffff9fffffff). Your linked
list is most likely allocated in the direct mapping
(0xffff880000000000-0xffffc7ffffffffff). However, I found out that the
virtual addresses for the direct mapping segments are wrong, e.g. my
dump file specifies it at 0xffff810000000000 (hypervisor area). This is
most likely a bug in the kernel code that implements /proc/vmcore.
But that's beside the point. Why? The Linux kernel maps many physical
pages more than once into the virtual address space. It would be waste
of space if you saved it multiple times (for each virtual address that
maps to it). The crash utility can translate each virtual address to
the physical address and map it onto ELF segments using PhysAddr.
Incidentally, the PhysAddr fields are correct in my dump files...
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.
Last time I looked (approx. 1.5 years ago) the main missing pieces were:
1. Use of physical addresses (described above)
2. Support for multiple virtual address spaces (for different process
contexts)
3. Ability to read compressed kdump files
4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
HTH,
Petr Tesarik
8:31 a.m.
Hello Dave,
For some reason the following posting did not arrive at the crash
mailing list:
https://www.sourceware.org/ml/gdb/2014-10/msg00061.html
https://www.sourceware.org/ml/gdb/2014-10/msg00062.html
Any idea why?
Michael
On Thu, 2 Oct 2014 10:27:00 +0200
Petr Tesarik <ptesarik(a)suse.cz> wrote:
On Thu, 2 Oct 2014 03:18:55 +0000
Pete Delaney <pdelaney(a)silver-peak.com> wrote:
> Hi:
>
> Six years ago Dave and I were discussing using gdb on KDUMP files:
>[...]
>
> Anyone know what's going on?
Yes, sure. GDB works very differently from crash. There main conceptual
difference is that GDB only handles with VIRTUAL addresses, while the
crash utility first translates everything to PHYSICAL addresses.
Consequently, GDB ignores the PhysAddr field in ELF program headers,
and crash ignores the VirtAddr field.
I have looked at some of my ELF dump files, and it seems to me that
VirtAddr is not filled correctly, except for kernel text and static
data (address range 0xffffffff80000000-0xffffffff9fffffff). Your linked
list is most likely allocated in the direct mapping
(0xffff880000000000-0xffffc7ffffffffff). However, I found out that the
virtual addresses for the direct mapping segments are wrong, e.g. my
dump file specifies it at 0xffff810000000000 (hypervisor area). This is
most likely a bug in the kernel code that implements /proc/vmcore.
But that's beside the point. Why? The Linux kernel maps many physical
pages more than once into the virtual address space. It would be waste
of space if you saved it multiple times (for each virtual address that
maps to it). The crash utility can translate each virtual address to
the physical address and map it onto ELF segments using PhysAddr.
Incidentally, the PhysAddr fields are correct in my dump files...
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.
Last time I looked (approx. 1.5 years ago) the main missing pieces were:
1. Use of physical addresses (described above)
2. Support for multiple virtual address spaces (for different process
contexts)
3. Ability to read compressed kdump files
4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
HTH,
Petr Tesarik
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8:52 a.m.
----- Original Message -----
Hello Dave,
For some reason the following posting did not arrive at the crash
mailing list:
https://www.sourceware.org/ml/gdb/2014-10/msg00061.html
https://www.sourceware.org/ml/gdb/2014-10/msg00062.html
I note that the posters are not members of the crash-utility mailing
list. I keep the list moderated because it receives dozens of spam messages
on a daily basis. I do my best to scan the Subjects of the held messages,
and if it's a legitimate message from a non-subscriber, I allow it through,
and set the poster's email address as somebody whose messages should be
accepted unconditionally in the future. So I must have mistakenly missed
the messages. Sorry about that.
Dave
Any idea why?
Michael
On Thu, 2 Oct 2014 10:27:00 +0200
Petr Tesarik <ptesarik(a)suse.cz> wrote:
> On Thu, 2 Oct 2014 03:18:55 +0000
> Pete Delaney <pdelaney(a)silver-peak.com> wrote:
>
> > Hi:
> >
> > Six years ago Dave and I were discussing using gdb on KDUMP files:
> >[...]
> >
> > Anyone know what's going on?
>
> Yes, sure. GDB works very differently from crash. There main conceptual
> difference is that GDB only handles with VIRTUAL addresses, while the
> crash utility first translates everything to PHYSICAL addresses.
> Consequently, GDB ignores the PhysAddr field in ELF program headers,
> and crash ignores the VirtAddr field.
>
> I have looked at some of my ELF dump files, and it seems to me that
> VirtAddr is not filled correctly, except for kernel text and static
> data (address range 0xffffffff80000000-0xffffffff9fffffff). Your linked
> list is most likely allocated in the direct mapping
> (0xffff880000000000-0xffffc7ffffffffff). However, I found out that the
> virtual addresses for the direct mapping segments are wrong, e.g. my
> dump file specifies it at 0xffff810000000000 (hypervisor area). This is
> most likely a bug in the kernel code that implements /proc/vmcore.
>
> But that's beside the point. Why? The Linux kernel maps many physical
> pages more than once into the virtual address space. It would be waste
> of space if you saved it multiple times (for each virtual address that
> maps to it). The crash utility can translate each virtual address to
> the physical address and map it onto ELF segments using PhysAddr.
> Incidentally, the PhysAddr fields are correct in my dump files...
>
> 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.
> Last time I looked (approx. 1.5 years ago) the main missing pieces were:
>
> 1. Use of physical addresses (described above)
> 2. Support for multiple virtual address spaces (for different process
> contexts)
> 3. Ability to read compressed kdump files
> 4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
>
> HTH,
> Petr Tesarik
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
3610
days inactive
3628
days old
devel@lists.crash-utility.osci.io
3 comments
4 participants
participants (4)
-
Dave Anderson -
Michael Holzheu -
Pete Delaney -
Petr Tesarik