2016-01-22 15:08:40 +03:00
|
|
|
"""
|
|
|
|
This python script adds a new gdb command, "dump-guest-memory". It
|
|
|
|
should be loaded with "source dump-guest-memory.py" at the (gdb)
|
|
|
|
prompt.
|
|
|
|
|
|
|
|
Copyright (C) 2013, Red Hat, Inc.
|
|
|
|
|
|
|
|
Authors:
|
|
|
|
Laszlo Ersek <lersek@redhat.com>
|
|
|
|
Janosch Frank <frankja@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
This work is licensed under the terms of the GNU GPL, version 2 or later. See
|
|
|
|
the COPYING file in the top-level directory.
|
|
|
|
"""
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
2016-01-22 15:08:39 +03:00
|
|
|
import ctypes
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
UINTPTR_T = gdb.lookup_type("uintptr_t")
|
|
|
|
|
2016-01-22 15:08:35 +03:00
|
|
|
TARGET_PAGE_SIZE = 0x1000
|
|
|
|
TARGET_PAGE_MASK = 0xFFFFFFFFFFFFF000
|
|
|
|
|
|
|
|
# Special value for e_phnum. This indicates that the real number of
|
|
|
|
# program headers is too large to fit into e_phnum. Instead the real
|
|
|
|
# value is in the field sh_info of section 0.
|
|
|
|
PN_XNUM = 0xFFFF
|
|
|
|
|
2016-01-22 15:08:39 +03:00
|
|
|
EV_CURRENT = 1
|
|
|
|
|
|
|
|
ELFCLASS32 = 1
|
|
|
|
ELFCLASS64 = 2
|
|
|
|
|
|
|
|
ELFDATA2LSB = 1
|
|
|
|
ELFDATA2MSB = 2
|
|
|
|
|
|
|
|
ET_CORE = 4
|
|
|
|
|
|
|
|
PT_LOAD = 1
|
|
|
|
PT_NOTE = 4
|
|
|
|
|
|
|
|
EM_386 = 3
|
|
|
|
EM_PPC = 20
|
|
|
|
EM_PPC64 = 21
|
|
|
|
EM_S390 = 22
|
|
|
|
EM_AARCH = 183
|
|
|
|
EM_X86_64 = 62
|
|
|
|
|
|
|
|
class ELF(object):
|
|
|
|
"""Representation of a ELF file."""
|
|
|
|
|
|
|
|
def __init__(self, arch):
|
|
|
|
self.ehdr = None
|
|
|
|
self.notes = []
|
|
|
|
self.segments = []
|
|
|
|
self.notes_size = 0
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = None
|
2016-01-22 15:08:39 +03:00
|
|
|
self.elfclass = ELFCLASS64
|
|
|
|
|
|
|
|
if arch == 'aarch64-le':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2LSB
|
2016-01-22 15:08:39 +03:00
|
|
|
self.elfclass = ELFCLASS64
|
2016-03-21 21:21:26 +03:00
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_AARCH
|
|
|
|
|
|
|
|
elif arch == 'aarch64-be':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2MSB
|
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_AARCH
|
|
|
|
|
|
|
|
elif arch == 'X86_64':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2LSB
|
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_X86_64
|
|
|
|
|
|
|
|
elif arch == '386':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2LSB
|
2016-01-22 15:08:39 +03:00
|
|
|
self.elfclass = ELFCLASS32
|
2016-03-21 21:21:26 +03:00
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_386
|
|
|
|
|
|
|
|
elif arch == 's390':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2MSB
|
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_S390
|
|
|
|
|
|
|
|
elif arch == 'ppc64-le':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2LSB
|
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_PPC64
|
|
|
|
|
|
|
|
elif arch == 'ppc64-be':
|
2016-03-21 21:21:26 +03:00
|
|
|
self.endianness = ELFDATA2MSB
|
|
|
|
self.ehdr = get_arch_ehdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ehdr.e_machine = EM_PPC64
|
|
|
|
|
|
|
|
else:
|
|
|
|
raise gdb.GdbError("No valid arch type specified.\n"
|
|
|
|
"Currently supported types:\n"
|
|
|
|
"aarch64-be, aarch64-le, X86_64, 386, s390, "
|
|
|
|
"ppc64-be, ppc64-le")
|
|
|
|
|
|
|
|
self.add_segment(PT_NOTE, 0, 0)
|
|
|
|
|
|
|
|
def add_note(self, n_name, n_desc, n_type):
|
|
|
|
"""Adds a note to the ELF."""
|
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
note = get_arch_note(self.endianness, len(n_name), len(n_desc))
|
2016-01-22 15:08:39 +03:00
|
|
|
note.n_namesz = len(n_name) + 1
|
|
|
|
note.n_descsz = len(n_desc)
|
|
|
|
note.n_name = n_name.encode()
|
|
|
|
note.n_type = n_type
|
|
|
|
|
|
|
|
# Desc needs to be 4 byte aligned (although the 64bit spec
|
|
|
|
# specifies 8 byte). When defining n_desc as uint32 it will be
|
|
|
|
# automatically aligned but we need the memmove to copy the
|
|
|
|
# string into it.
|
|
|
|
ctypes.memmove(note.n_desc, n_desc.encode(), len(n_desc))
|
|
|
|
|
|
|
|
self.notes.append(note)
|
|
|
|
self.segments[0].p_filesz += ctypes.sizeof(note)
|
|
|
|
self.segments[0].p_memsz += ctypes.sizeof(note)
|
|
|
|
|
|
|
|
def add_segment(self, p_type, p_paddr, p_size):
|
|
|
|
"""Adds a segment to the elf."""
|
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
phdr = get_arch_phdr(self.endianness, self.elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
phdr.p_type = p_type
|
|
|
|
phdr.p_paddr = p_paddr
|
|
|
|
phdr.p_filesz = p_size
|
|
|
|
phdr.p_memsz = p_size
|
|
|
|
self.segments.append(phdr)
|
|
|
|
self.ehdr.e_phnum += 1
|
|
|
|
|
|
|
|
def to_file(self, elf_file):
|
|
|
|
"""Writes all ELF structures to the the passed file.
|
|
|
|
|
|
|
|
Structure:
|
|
|
|
Ehdr
|
|
|
|
Segment 0:PT_NOTE
|
|
|
|
Segment 1:PT_LOAD
|
|
|
|
Segment N:PT_LOAD
|
|
|
|
Note 0..N
|
|
|
|
Dump contents
|
|
|
|
"""
|
|
|
|
elf_file.write(self.ehdr)
|
|
|
|
off = ctypes.sizeof(self.ehdr) + \
|
|
|
|
len(self.segments) * ctypes.sizeof(self.segments[0])
|
|
|
|
|
|
|
|
for phdr in self.segments:
|
|
|
|
phdr.p_offset = off
|
|
|
|
elf_file.write(phdr)
|
|
|
|
off += phdr.p_filesz
|
|
|
|
|
|
|
|
for note in self.notes:
|
|
|
|
elf_file.write(note)
|
|
|
|
|
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
def get_arch_note(endianness, len_name, len_desc):
|
|
|
|
"""Returns a Note class with the specified endianness."""
|
2016-01-22 15:08:39 +03:00
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
if endianness == ELFDATA2LSB:
|
2016-01-22 15:08:39 +03:00
|
|
|
superclass = ctypes.LittleEndianStructure
|
|
|
|
else:
|
|
|
|
superclass = ctypes.BigEndianStructure
|
|
|
|
|
|
|
|
len_name = len_name + 1
|
|
|
|
|
|
|
|
class Note(superclass):
|
|
|
|
"""Represents an ELF note, includes the content."""
|
|
|
|
|
|
|
|
_fields_ = [("n_namesz", ctypes.c_uint32),
|
|
|
|
("n_descsz", ctypes.c_uint32),
|
|
|
|
("n_type", ctypes.c_uint32),
|
|
|
|
("n_name", ctypes.c_char * len_name),
|
|
|
|
("n_desc", ctypes.c_uint32 * ((len_desc + 3) // 4))]
|
|
|
|
return Note()
|
|
|
|
|
|
|
|
|
|
|
|
class Ident(ctypes.Structure):
|
|
|
|
"""Represents the ELF ident array in the ehdr structure."""
|
|
|
|
|
|
|
|
_fields_ = [('ei_mag0', ctypes.c_ubyte),
|
|
|
|
('ei_mag1', ctypes.c_ubyte),
|
|
|
|
('ei_mag2', ctypes.c_ubyte),
|
|
|
|
('ei_mag3', ctypes.c_ubyte),
|
|
|
|
('ei_class', ctypes.c_ubyte),
|
|
|
|
('ei_data', ctypes.c_ubyte),
|
|
|
|
('ei_version', ctypes.c_ubyte),
|
|
|
|
('ei_osabi', ctypes.c_ubyte),
|
|
|
|
('ei_abiversion', ctypes.c_ubyte),
|
|
|
|
('ei_pad', ctypes.c_ubyte * 7)]
|
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
def __init__(self, endianness, elfclass):
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ei_mag0 = 0x7F
|
|
|
|
self.ei_mag1 = ord('E')
|
|
|
|
self.ei_mag2 = ord('L')
|
|
|
|
self.ei_mag3 = ord('F')
|
|
|
|
self.ei_class = elfclass
|
2016-03-21 21:21:26 +03:00
|
|
|
self.ei_data = endianness
|
2016-01-22 15:08:39 +03:00
|
|
|
self.ei_version = EV_CURRENT
|
|
|
|
|
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
def get_arch_ehdr(endianness, elfclass):
|
|
|
|
"""Returns a EHDR64 class with the specified endianness."""
|
2016-01-22 15:08:39 +03:00
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
if endianness == ELFDATA2LSB:
|
2016-01-22 15:08:39 +03:00
|
|
|
superclass = ctypes.LittleEndianStructure
|
|
|
|
else:
|
|
|
|
superclass = ctypes.BigEndianStructure
|
|
|
|
|
|
|
|
class EHDR64(superclass):
|
|
|
|
"""Represents the 64 bit ELF header struct."""
|
|
|
|
|
|
|
|
_fields_ = [('e_ident', Ident),
|
|
|
|
('e_type', ctypes.c_uint16),
|
|
|
|
('e_machine', ctypes.c_uint16),
|
|
|
|
('e_version', ctypes.c_uint32),
|
|
|
|
('e_entry', ctypes.c_uint64),
|
|
|
|
('e_phoff', ctypes.c_uint64),
|
|
|
|
('e_shoff', ctypes.c_uint64),
|
|
|
|
('e_flags', ctypes.c_uint32),
|
|
|
|
('e_ehsize', ctypes.c_uint16),
|
|
|
|
('e_phentsize', ctypes.c_uint16),
|
|
|
|
('e_phnum', ctypes.c_uint16),
|
|
|
|
('e_shentsize', ctypes.c_uint16),
|
|
|
|
('e_shnum', ctypes.c_uint16),
|
|
|
|
('e_shstrndx', ctypes.c_uint16)]
|
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
super(superclass, self).__init__()
|
2016-03-21 21:21:26 +03:00
|
|
|
self.e_ident = Ident(endianness, elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.e_type = ET_CORE
|
|
|
|
self.e_version = EV_CURRENT
|
|
|
|
self.e_ehsize = ctypes.sizeof(self)
|
|
|
|
self.e_phoff = ctypes.sizeof(self)
|
2016-03-21 21:21:26 +03:00
|
|
|
self.e_phentsize = ctypes.sizeof(get_arch_phdr(endianness, elfclass))
|
2016-01-22 15:08:39 +03:00
|
|
|
self.e_phnum = 0
|
|
|
|
|
|
|
|
|
|
|
|
class EHDR32(superclass):
|
|
|
|
"""Represents the 32 bit ELF header struct."""
|
|
|
|
|
|
|
|
_fields_ = [('e_ident', Ident),
|
|
|
|
('e_type', ctypes.c_uint16),
|
|
|
|
('e_machine', ctypes.c_uint16),
|
|
|
|
('e_version', ctypes.c_uint32),
|
|
|
|
('e_entry', ctypes.c_uint32),
|
|
|
|
('e_phoff', ctypes.c_uint32),
|
|
|
|
('e_shoff', ctypes.c_uint32),
|
|
|
|
('e_flags', ctypes.c_uint32),
|
|
|
|
('e_ehsize', ctypes.c_uint16),
|
|
|
|
('e_phentsize', ctypes.c_uint16),
|
|
|
|
('e_phnum', ctypes.c_uint16),
|
|
|
|
('e_shentsize', ctypes.c_uint16),
|
|
|
|
('e_shnum', ctypes.c_uint16),
|
|
|
|
('e_shstrndx', ctypes.c_uint16)]
|
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
super(superclass, self).__init__()
|
2016-03-21 21:21:26 +03:00
|
|
|
self.e_ident = Ident(endianness, elfclass)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.e_type = ET_CORE
|
|
|
|
self.e_version = EV_CURRENT
|
|
|
|
self.e_ehsize = ctypes.sizeof(self)
|
|
|
|
self.e_phoff = ctypes.sizeof(self)
|
2016-03-21 21:21:26 +03:00
|
|
|
self.e_phentsize = ctypes.sizeof(get_arch_phdr(endianness, elfclass))
|
2016-01-22 15:08:39 +03:00
|
|
|
self.e_phnum = 0
|
|
|
|
|
|
|
|
# End get_arch_ehdr
|
|
|
|
if elfclass == ELFCLASS64:
|
|
|
|
return EHDR64()
|
|
|
|
else:
|
|
|
|
return EHDR32()
|
|
|
|
|
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
def get_arch_phdr(endianness, elfclass):
|
|
|
|
"""Returns a 32 or 64 bit PHDR class with the specified endianness."""
|
2016-01-22 15:08:39 +03:00
|
|
|
|
2016-03-21 21:21:26 +03:00
|
|
|
if endianness == ELFDATA2LSB:
|
2016-01-22 15:08:39 +03:00
|
|
|
superclass = ctypes.LittleEndianStructure
|
|
|
|
else:
|
|
|
|
superclass = ctypes.BigEndianStructure
|
|
|
|
|
|
|
|
class PHDR64(superclass):
|
|
|
|
"""Represents the 64 bit ELF program header struct."""
|
|
|
|
|
|
|
|
_fields_ = [('p_type', ctypes.c_uint32),
|
|
|
|
('p_flags', ctypes.c_uint32),
|
|
|
|
('p_offset', ctypes.c_uint64),
|
|
|
|
('p_vaddr', ctypes.c_uint64),
|
|
|
|
('p_paddr', ctypes.c_uint64),
|
|
|
|
('p_filesz', ctypes.c_uint64),
|
|
|
|
('p_memsz', ctypes.c_uint64),
|
|
|
|
('p_align', ctypes.c_uint64)]
|
|
|
|
|
|
|
|
class PHDR32(superclass):
|
|
|
|
"""Represents the 32 bit ELF program header struct."""
|
|
|
|
|
|
|
|
_fields_ = [('p_type', ctypes.c_uint32),
|
|
|
|
('p_offset', ctypes.c_uint32),
|
|
|
|
('p_vaddr', ctypes.c_uint32),
|
|
|
|
('p_paddr', ctypes.c_uint32),
|
|
|
|
('p_filesz', ctypes.c_uint32),
|
|
|
|
('p_memsz', ctypes.c_uint32),
|
|
|
|
('p_flags', ctypes.c_uint32),
|
|
|
|
('p_align', ctypes.c_uint32)]
|
|
|
|
|
|
|
|
# End get_arch_phdr
|
|
|
|
if elfclass == ELFCLASS64:
|
|
|
|
return PHDR64()
|
|
|
|
else:
|
|
|
|
return PHDR32()
|
|
|
|
|
2016-01-22 15:08:35 +03:00
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
def int128_get64(val):
|
2016-01-22 15:08:38 +03:00
|
|
|
"""Returns low 64bit part of Int128 struct."""
|
|
|
|
|
2017-03-10 14:28:19 +03:00
|
|
|
try:
|
|
|
|
assert val["hi"] == 0
|
|
|
|
return val["lo"]
|
|
|
|
except gdb.error:
|
|
|
|
u64t = gdb.lookup_type('uint64_t').array(2)
|
|
|
|
u64 = val.cast(u64t)
|
|
|
|
if sys.byteorder == 'little':
|
|
|
|
assert u64[1] == 0
|
|
|
|
return u64[0]
|
|
|
|
else:
|
|
|
|
assert u64[0] == 0
|
|
|
|
return u64[1]
|
2016-01-22 15:08:36 +03:00
|
|
|
|
2016-01-22 15:08:38 +03:00
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
def qlist_foreach(head, field_str):
|
2016-01-22 15:08:38 +03:00
|
|
|
"""Generator for qlists."""
|
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
var_p = head["lh_first"]
|
2016-01-22 15:08:38 +03:00
|
|
|
while var_p != 0:
|
2016-01-22 15:08:36 +03:00
|
|
|
var = var_p.dereference()
|
|
|
|
var_p = var[field_str]["le_next"]
|
2016-01-22 15:08:38 +03:00
|
|
|
yield var
|
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
|
2016-02-22 13:02:12 +03:00
|
|
|
def qemu_map_ram_ptr(block, offset):
|
2016-01-22 15:08:38 +03:00
|
|
|
"""Returns qemu vaddr for given guest physical address."""
|
|
|
|
|
2016-02-22 13:02:12 +03:00
|
|
|
return block["host"] + offset
|
2016-01-22 15:08:36 +03:00
|
|
|
|
2016-01-22 15:08:38 +03:00
|
|
|
|
|
|
|
def memory_region_get_ram_ptr(memory_region):
|
|
|
|
if memory_region["alias"] != 0:
|
|
|
|
return (memory_region_get_ram_ptr(memory_region["alias"].dereference())
|
|
|
|
+ memory_region["alias_offset"])
|
|
|
|
|
2016-02-22 13:02:12 +03:00
|
|
|
return qemu_map_ram_ptr(memory_region["ram_block"], 0)
|
2016-01-22 15:08:38 +03:00
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
|
|
|
|
def get_guest_phys_blocks():
|
2016-01-22 15:08:38 +03:00
|
|
|
"""Returns a list of ram blocks.
|
|
|
|
|
|
|
|
Each block entry contains:
|
|
|
|
'target_start': guest block phys start address
|
|
|
|
'target_end': guest block phys end address
|
|
|
|
'host_addr': qemu vaddr of the block's start
|
|
|
|
"""
|
|
|
|
|
2016-01-22 15:08:36 +03:00
|
|
|
guest_phys_blocks = []
|
2016-01-22 15:08:38 +03:00
|
|
|
|
2016-01-22 15:08:37 +03:00
|
|
|
print("guest RAM blocks:")
|
|
|
|
print("target_start target_end host_addr message "
|
|
|
|
"count")
|
|
|
|
print("---------------- ---------------- ---------------- ------- "
|
|
|
|
"-----")
|
2016-01-22 15:08:36 +03:00
|
|
|
|
|
|
|
current_map_p = gdb.parse_and_eval("address_space_memory.current_map")
|
|
|
|
current_map = current_map_p.dereference()
|
2016-01-22 15:08:37 +03:00
|
|
|
|
|
|
|
# Conversion to int is needed for python 3
|
|
|
|
# compatibility. Otherwise range doesn't cast the value itself and
|
|
|
|
# breaks.
|
|
|
|
for cur in range(int(current_map["nr"])):
|
2016-01-22 15:08:38 +03:00
|
|
|
flat_range = (current_map["ranges"] + cur).dereference()
|
|
|
|
memory_region = flat_range["mr"].dereference()
|
2016-01-22 15:08:36 +03:00
|
|
|
|
|
|
|
# we only care about RAM
|
2016-01-22 15:08:38 +03:00
|
|
|
if not memory_region["ram"]:
|
2016-01-22 15:08:36 +03:00
|
|
|
continue
|
|
|
|
|
|
|
|
section_size = int128_get64(flat_range["addr"]["size"])
|
|
|
|
target_start = int128_get64(flat_range["addr"]["start"])
|
2016-01-22 15:08:38 +03:00
|
|
|
target_end = target_start + section_size
|
|
|
|
host_addr = (memory_region_get_ram_ptr(memory_region)
|
|
|
|
+ flat_range["offset_in_region"])
|
2016-01-22 15:08:36 +03:00
|
|
|
predecessor = None
|
|
|
|
|
|
|
|
# find continuity in guest physical address space
|
2016-01-22 15:08:38 +03:00
|
|
|
if len(guest_phys_blocks) > 0:
|
2016-01-22 15:08:36 +03:00
|
|
|
predecessor = guest_phys_blocks[-1]
|
|
|
|
predecessor_size = (predecessor["target_end"] -
|
|
|
|
predecessor["target_start"])
|
|
|
|
|
|
|
|
# the memory API guarantees monotonically increasing
|
|
|
|
# traversal
|
2016-01-22 15:08:38 +03:00
|
|
|
assert predecessor["target_end"] <= target_start
|
2016-01-22 15:08:36 +03:00
|
|
|
|
|
|
|
# we want continuity in both guest-physical and
|
|
|
|
# host-virtual memory
|
|
|
|
if (predecessor["target_end"] < target_start or
|
|
|
|
predecessor["host_addr"] + predecessor_size != host_addr):
|
|
|
|
predecessor = None
|
|
|
|
|
2016-01-22 15:08:38 +03:00
|
|
|
if predecessor is None:
|
2016-01-22 15:08:36 +03:00
|
|
|
# isolated mapping, add it to the list
|
|
|
|
guest_phys_blocks.append({"target_start": target_start,
|
2016-01-22 15:08:38 +03:00
|
|
|
"target_end": target_end,
|
|
|
|
"host_addr": host_addr})
|
2016-01-22 15:08:36 +03:00
|
|
|
message = "added"
|
|
|
|
else:
|
|
|
|
# expand predecessor until @target_end; predecessor's
|
|
|
|
# start doesn't change
|
|
|
|
predecessor["target_end"] = target_end
|
|
|
|
message = "joined"
|
|
|
|
|
2016-01-22 15:08:37 +03:00
|
|
|
print("%016x %016x %016x %-7s %5u" %
|
|
|
|
(target_start, target_end, host_addr.cast(UINTPTR_T),
|
|
|
|
message, len(guest_phys_blocks)))
|
2016-01-22 15:08:36 +03:00
|
|
|
|
|
|
|
return guest_phys_blocks
|
|
|
|
|
|
|
|
|
2016-01-22 15:08:40 +03:00
|
|
|
# The leading docstring doesn't have idiomatic Python formatting. It is
|
|
|
|
# printed by gdb's "help" command (the first line is printed in the
|
|
|
|
# "help data" summary), and it should match how other help texts look in
|
|
|
|
# gdb.
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
class DumpGuestMemory(gdb.Command):
|
|
|
|
"""Extract guest vmcore from qemu process coredump.
|
|
|
|
|
2016-01-22 15:08:39 +03:00
|
|
|
The two required arguments are FILE and ARCH:
|
|
|
|
FILE identifies the target file to write the guest vmcore to.
|
|
|
|
ARCH specifies the architecture for which the core will be generated.
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
|
|
|
This GDB command reimplements the dump-guest-memory QMP command in
|
|
|
|
python, using the representation of guest memory as captured in the qemu
|
|
|
|
coredump. The qemu process that has been dumped must have had the
|
2016-01-22 15:08:39 +03:00
|
|
|
command line option "-machine dump-guest-core=on" which is the default.
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
|
|
|
For simplicity, the "paging", "begin" and "end" parameters of the QMP
|
|
|
|
command are not supported -- no attempt is made to get the guest's
|
|
|
|
internal paging structures (ie. paging=false is hard-wired), and guest
|
|
|
|
memory is always fully dumped.
|
|
|
|
|
2016-01-22 15:08:39 +03:00
|
|
|
Currently aarch64-be, aarch64-le, X86_64, 386, s390, ppc64-be,
|
|
|
|
ppc64-le guests are supported.
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
|
|
|
The CORE/NT_PRSTATUS and QEMU notes (that is, the VCPUs' statuses) are
|
|
|
|
not written to the vmcore. Preparing these would require context that is
|
|
|
|
only present in the KVM host kernel module when the guest is alive. A
|
|
|
|
fake ELF note is written instead, only to keep the ELF parser of "crash"
|
|
|
|
happy.
|
|
|
|
|
|
|
|
Dependent on how busted the qemu process was at the time of the
|
|
|
|
coredump, this command might produce unpredictable results. If qemu
|
|
|
|
deliberately called abort(), or it was dumped in response to a signal at
|
|
|
|
a halfway fortunate point, then its coredump should be in reasonable
|
|
|
|
shape and this command should mostly work."""
|
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
super(DumpGuestMemory, self).__init__("dump-guest-memory",
|
|
|
|
gdb.COMMAND_DATA,
|
|
|
|
gdb.COMPLETE_FILENAME)
|
2016-01-22 15:08:39 +03:00
|
|
|
self.elf = None
|
2016-01-22 15:08:36 +03:00
|
|
|
self.guest_phys_blocks = None
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
2016-01-22 15:08:39 +03:00
|
|
|
def dump_init(self, vmcore):
|
|
|
|
"""Prepares and writes ELF structures to core file."""
|
|
|
|
|
|
|
|
# Needed to make crash happy, data for more useful notes is
|
|
|
|
# not available in a qemu core.
|
|
|
|
self.elf.add_note("NONE", "EMPTY", 0)
|
|
|
|
|
|
|
|
# We should never reach PN_XNUM for paging=false dumps,
|
|
|
|
# there's just a handful of discontiguous ranges after
|
|
|
|
# merging.
|
|
|
|
# The constant is needed to account for the PT_NOTE segment.
|
|
|
|
phdr_num = len(self.guest_phys_blocks) + 1
|
|
|
|
assert phdr_num < PN_XNUM
|
|
|
|
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
for block in self.guest_phys_blocks:
|
2016-01-22 15:08:39 +03:00
|
|
|
block_size = block["target_end"] - block["target_start"]
|
|
|
|
self.elf.add_segment(PT_LOAD, block["target_start"], block_size)
|
|
|
|
|
|
|
|
self.elf.to_file(vmcore)
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
|
|
|
def dump_iterate(self, vmcore):
|
2016-01-22 15:08:39 +03:00
|
|
|
"""Writes guest core to file."""
|
|
|
|
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
qemu_core = gdb.inferiors()[0]
|
|
|
|
for block in self.guest_phys_blocks:
|
2016-01-22 15:08:38 +03:00
|
|
|
cur = block["host_addr"]
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
left = block["target_end"] - block["target_start"]
|
2016-01-22 15:08:37 +03:00
|
|
|
print("dumping range at %016x for length %016x" %
|
|
|
|
(cur.cast(UINTPTR_T), left))
|
2016-01-22 15:08:39 +03:00
|
|
|
|
2016-01-22 15:08:38 +03:00
|
|
|
while left > 0:
|
2016-01-22 15:08:35 +03:00
|
|
|
chunk_size = min(TARGET_PAGE_SIZE, left)
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
chunk = qemu_core.read_memory(cur, chunk_size)
|
|
|
|
vmcore.write(chunk)
|
2016-01-22 15:08:38 +03:00
|
|
|
cur += chunk_size
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
left -= chunk_size
|
|
|
|
|
|
|
|
def invoke(self, args, from_tty):
|
2016-01-22 15:08:39 +03:00
|
|
|
"""Handles command invocation from gdb."""
|
|
|
|
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
# Unwittingly pressing the Enter key after the command should
|
|
|
|
# not dump the same multi-gig coredump to the same file.
|
|
|
|
self.dont_repeat()
|
|
|
|
|
|
|
|
argv = gdb.string_to_argv(args)
|
2016-01-22 15:08:39 +03:00
|
|
|
if len(argv) != 2:
|
|
|
|
raise gdb.GdbError("usage: dump-guest-memory FILE ARCH")
|
|
|
|
|
|
|
|
self.elf = ELF(argv[1])
|
|
|
|
self.guest_phys_blocks = get_guest_phys_blocks()
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
2016-01-22 15:08:39 +03:00
|
|
|
with open(argv[0], "wb") as vmcore:
|
|
|
|
self.dump_init(vmcore)
|
|
|
|
self.dump_iterate(vmcore)
|
Python-lang gdb script to extract x86_64 guest vmcore from qemu coredump
When qemu dies unexpectedly, for example in response to an explicit
abort() call, or (more importantly) when an external signal is delivered
to it that results in a coredump, sometimes it is useful to extract the
guest vmcore from the qemu process' memory image. The guest vmcore might
help understand an emulation problem in qemu, or help debug the guest.
This script reimplements (and cuts many features of) the
qmp_dump_guest_memory() command in gdb/Python,
https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html
working off the saved memory image of the qemu process. The docstring in
the patch (serving as gdb help text) describes the limitations relative to
the QMP command.
Dependencies of qmp_dump_guest_memory() have been reimplemented as needed.
I sought to follow the general structure, sticking to original function
names where possible. However, keeping it simple prevailed in some places.
The patch has been tested with a 4 VCPU, 768 MB, RHEL-6.4
(2.6.32-358.el6.x86_64) guest:
- The script printed
> guest RAM blocks:
> target_start target_end host_addr message count
> ---------------- ---------------- ---------------- ------- -----
> 0000000000000000 00000000000a0000 00007f95d0000000 added 1
> 00000000000a0000 00000000000b0000 00007f960ac00000 added 2
> 00000000000c0000 00000000000ca000 00007f95d00c0000 added 3
> 00000000000ca000 00000000000cd000 00007f95d00ca000 joined 3
> 00000000000cd000 00000000000d0000 00007f95d00cd000 joined 3
> 00000000000d0000 00000000000f0000 00007f95d00d0000 joined 3
> 00000000000f0000 0000000000100000 00007f95d00f0000 joined 3
> 0000000000100000 0000000030000000 00007f95d0100000 joined 3
> 00000000fc000000 00000000fc800000 00007f960ac00000 added 4
> 00000000fffe0000 0000000100000000 00007f9618800000 added 5
> dumping range at 00007f95d0000000 for length 00000000000a0000
> dumping range at 00007f960ac00000 for length 0000000000010000
> dumping range at 00007f95d00c0000 for length 000000002ff40000
> dumping range at 00007f960ac00000 for length 0000000000800000
> dumping range at 00007f9618800000 for length 0000000000020000
- The vmcore was checked with "readelf", comparing the results against a
vmcore written by qmp_dump_guest_memory():
> --- theirs 2013-09-12 17:38:59.797289404 +0200
> +++ mine 2013-09-12 17:39:03.820289404 +0200
> @@ -27,16 +27,16 @@
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000
> - 0x0000000000000ca0 0x0000000000000ca0 0
> - LOAD 0x0000000000000e30 0x0000000000000000 0x0000000000000000
> + 0x000000000000001c 0x000000000000001c 0
> + LOAD 0x00000000000001ac 0x0000000000000000 0x0000000000000000
> 0x00000000000a0000 0x00000000000a0000 0
> - LOAD 0x00000000000a0e30 0x0000000000000000 0x00000000000a0000
> + LOAD 0x00000000000a01ac 0x0000000000000000 0x00000000000a0000
> 0x0000000000010000 0x0000000000010000 0
> - LOAD 0x00000000000b0e30 0x0000000000000000 0x00000000000c0000
> + LOAD 0x00000000000b01ac 0x0000000000000000 0x00000000000c0000
> 0x000000002ff40000 0x000000002ff40000 0
> - LOAD 0x000000002fff0e30 0x0000000000000000 0x00000000fc000000
> + LOAD 0x000000002fff01ac 0x0000000000000000 0x00000000fc000000
> 0x0000000000800000 0x0000000000800000 0
> - LOAD 0x00000000307f0e30 0x0000000000000000 0x00000000fffe0000
> + LOAD 0x00000000307f01ac 0x0000000000000000 0x00000000fffe0000
> 0x0000000000020000 0x0000000000020000 0
>
> There is no dynamic section in this file.
> @@ -47,13 +47,6 @@
>
> No version information found in this file.
>
> -Notes at offset 0x00000190 with length 0x00000ca0:
> +Notes at offset 0x00000190 with length 0x0000001c:
> Owner Data size Description
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> - QEMU 0x000001b0 Unknown note type: (0x00000000)
> + NONE 0x00000005 Unknown note type: (0x00000000)
- The vmcore was checked with "crash" too, again comparing the results
against a vmcore written by qmp_dump_guest_memory():
> --- guest.vmcore.log2 2013-09-12 17:52:27.074289201 +0200
> +++ example.dump.log2 2013-09-12 17:52:15.904289203 +0200
> @@ -22,11 +22,11 @@
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
> - DUMPFILE: /home/lacos/tmp/guest.vmcore
> + DUMPFILE: /home/lacos/tmp/example.dump
> CPUS: 4
> - DATE: Thu Sep 12 17:16:11 2013
> - UPTIME: 00:01:09
> -LOAD AVERAGE: 0.07, 0.03, 0.00
> + DATE: Thu Sep 12 17:17:41 2013
> + UPTIME: 00:00:38
> +LOAD AVERAGE: 0.18, 0.05, 0.01
> TASKS: 130
> NODENAME: localhost.localdomain
> RELEASE: 2.6.32-358.el6.x86_64
> @@ -38,12 +38,12 @@
> COMMAND: "swapper"
> TASK: ffffffff81a8d020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> - STATE: TASK_RUNNING (PANIC)
> + STATE: TASK_RUNNING (ACTIVE)
> + WARNING: panic task not found
>
> crash> bt
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> - #0 [ffffffff81a01ed0] default_idle at ffffffff8101495d
> - #1 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> + #0 [ffffffff81a01ef0] cpu_idle at ffffffff81009fc6
> crash> task ffffffff81a8d020
> PID: 0 TASK: ffffffff81a8d020 CPU: 0 COMMAND: "swapper"
> struct task_struct {
> @@ -75,7 +75,7 @@
> prev = 0xffffffff81a8d080
> },
> on_rq = 0,
> - exec_start = 8618466836,
> + exec_start = 7469214014,
> sum_exec_runtime = 0,
> vruntime = 0,
> prev_sum_exec_runtime = 0,
> @@ -149,7 +149,7 @@
> },
> tasks = {
> next = 0xffff88002d621948,
> - prev = 0xffff880029618f28
> + prev = 0xffff880023b74488
> },
> pushable_tasks = {
> prio = 140,
> @@ -165,7 +165,7 @@
> }
> },
> mm = 0x0,
> - active_mm = 0xffff88002929b780,
> + active_mm = 0xffff8800297eb980,
> exit_state = 0,
> exit_code = 0,
> exit_signal = 0,
> @@ -177,7 +177,7 @@
> sched_reset_on_fork = 0,
> pid = 0,
> tgid = 0,
> - stack_canary = 2483693585637059287,
> + stack_canary = 7266362296181431986,
> real_parent = 0xffffffff81a8d020,
> parent = 0xffffffff81a8d020,
> children = {
> @@ -224,14 +224,14 @@
> set_child_tid = 0x0,
> clear_child_tid = 0x0,
> utime = 0,
> - stime = 3,
> + stime = 2,
> utimescaled = 0,
> - stimescaled = 3,
> + stimescaled = 2,
> gtime = 0,
> prev_utime = 0,
> prev_stime = 0,
> nvcsw = 0,
> - nivcsw = 1000,
> + nivcsw = 1764,
> start_time = {
> tv_sec = 0,
> tv_nsec = 0
- <name_dropping>I asked for Dave Anderson's help with verifying the
extracted vmcore, and his comments make me think I should post
this.</name_dropping>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-12-17 04:37:06 +04:00
|
|
|
|
|
|
|
DumpGuestMemory()
|