Commit Graph

19 Commits

Author SHA1 Message Date
Andrew Jones
4b17bc933f dump-guest-memory: more descriptive lookup_type failure
We've seen a few reports of

 (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py
 Traceback (most recent call last):
   File "/usr/share/qemu-kvm/dump-guest-memory.py", line 19, in <module>
     UINTPTR_T = gdb.lookup_type("uintptr_t")
 gdb.error: No type named uintptr_t.

This occurs when symbols haven't been loaded first, i.e. neither a
QEMU binary was loaded nor a QEMU process was attached first. Let's
better inform the user of how to fix the issue themselves in order
to avoid more reports.

Acked-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Signed-off-by: Andrew Jones <drjones@redhat.com>
Message-Id: <20180314153820.18426-1-drjones@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Tested-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2018-03-21 15:02:00 +01:00
Marc-André Lureau
ce6b9e421a dump-guest-memory.py: skip vmcoreinfo section if not available
On some architectures, qemu doesn't support vmcoreinfo device,
and dump-guest-memory fails:

(gdb) dump-guest-memory /tmp/vmcore  ppc64-le
guest RAM blocks:
target_start     target_end       host_addr        message count
---------------- ---------------- ---------------- ------- -----
0000000000000000 0000000200000000 00003ffd86980000 added       1
0000200080000000 0000200080800000 00003ffd86170000 added       2
Python Exception <class 'gdb.error'> No symbol "vmcoreinfo_realize" in current context.:
Error occurred in Python command: No symbol "vmcoreinfo_realize" in current context.

Check that vmcoreinfo_realize symbol exists before evaluating an
expression with it.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-02-01 12:13:52 +01:00
Marc-André Lureau
6f49ec4034 dump-guest-memory.py: fix python 2 support
Python GDB support may use Python 2 or 3.

Inferior.read_memory() may return a 'buffer' with Python 2 or a
'memoryview' with Python 3 (see also
https://sourceware.org/gdb/onlinedocs/gdb/Inferiors-In-Python.html)

The elf.add_vmcoreinfo_note() method expects a "bytes" object. Wrap
the returned memory with bytes(), which works with both 'memoryview'
and 'buffer'.

Fixes a regression introduced with commit
d23bfa91b7 ("add vmcoreinfo").

Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2018-01-20 20:59:00 +01:00
Marc-André Lureau
c3b1642b9b dump-guest-memory.py: fix "You can't do that without a process to debug"
If the script is run with a core (no running process), it produces an
error:

(gdb)  dump-guest-memory /tmp/vmcore X86_64
guest RAM blocks:
target_start     target_end       host_addr        message count
---------------- ---------------- ---------------- ------- -----
0000000000000000 00000000000a0000 00007f7935800000 added       1
00000000000a0000 00000000000b0000 00007f7934200000 added       2
00000000000c0000 00000000000ca000 00007f79358c0000 added       3
00000000000ca000 00000000000cd000 00007f79358ca000 joined      3
00000000000cd000 00000000000e8000 00007f79358cd000 joined      3
00000000000e8000 00000000000f0000 00007f79358e8000 joined      3
00000000000f0000 0000000000100000 00007f79358f0000 joined      3
0000000000100000 0000000080000000 00007f7935900000 joined      3
00000000fd000000 00000000fe000000 00007f7934200000 added       4
00000000fffc0000 0000000100000000 00007f7935600000 added       5
Python Exception <class 'gdb.error'> You can't do that without a process to debug.:
Error occurred in Python command: You can't do that without a process
to debug.

Replace the object_resolve_path_type() function call with a local
volatile variable.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-01-02 14:49:54 +01:00
Marc-André Lureau
d36d0a9d15 dump-guest-memory.py: fix No symbol "vmcoreinfo_find"
When qemu is compiled without debug, the dump gdb python script can fail with:

Error occurred in Python command: No symbol "vmcoreinfo_find" in current context.

Because vmcoreinfo_find() is inlined and not exported.

Use the underlying object_resolve_path_type() to get the instance instead.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-12-01 19:05:58 +02:00
Marc-André Lureau
d23bfa91b7 scripts/dump-guest-memory.py: add vmcoreinfo
Add a vmcoreinfo ELF note in the dump if vmcoreinfo device has the
memory location details.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-10-15 05:54:40 +03:00
Marc-André Lureau
9b4b157ef6 scripts/dump-guest-memory.py: fix int128_get64 on recent gcc
The Int128 is no longer a struct, reaching a python exception:
Python Exception <class 'gdb.error'> Attempt to extract a component of a value that is not a (null).:

Replace struct access with a cast to uint64[] instead.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1427466

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20170310112819.16760-1-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-14 13:26:36 +01:00
Paolo Bonzini
0878d0e11b exec: hide mr->ram_addr from qemu_get_ram_ptr users
Let users of qemu_get_ram_ptr and qemu_ram_ptr_length pass in an
address that is relative to the MemoryRegion.  This basically means
what address_space_translate returns.

Because the semantics of the second parameter change, rename the
function to qemu_map_ram_ptr.

Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-29 09:11:12 +02:00
Stefan Weil
1d817db3a0 Fix typo in variable name (found and fixed by codespell)
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2016-05-18 15:04:26 +03:00
Fam Zheng
8e41fb63c5 memory: Drop MemoryRegion.ram_addr
All references to mr->ram_addr are replaced by
memory_region_get_ram_addr(mr) (except for a few assertions that are
replaced with mr->ram_block).

Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1456813104-25902-5-git-send-email-famz@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-07 13:26:29 +01:00
Janosch Frank
28fbf8f67b scripts/dump-guest-memory.py: Fix module docstring
The module docstring is changed into a multi-line comment to comply
with pep 257.

The comment about the docstring that gets used by gdb to print the
help is moved to the location of the docstring.

Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1453464520-3882-7-git-send-email-frankja@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26 15:58:14 +01:00
Janosch Frank
368e3adc89 scripts/dump-guest-memory.py: Introduce multi-arch support
By modelling the ELF with ctypes we not only gain full python 3
support but can also create dumps for different architectures more easily.

Tested-by: Andrew Jones <drjones@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1453464520-3882-6-git-send-email-frankja@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26 15:58:14 +01:00
Janosch Frank
6782c0e785 scripts/dump-guest-memory.py: Cleanup functions
Increase readability by adding newlines and comments, as well as
removing wrong whitespaces and C style braces around conditionals and
loops.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1453464520-3882-5-git-send-email-frankja@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26 15:58:14 +01:00
Janosch Frank
7cb1089d5f scripts/dump-guest-memory.py: Improve python 3 compatibility
This commit does not make the script python 3 compatible, it is a
preparation that fixes the easy and common incompatibilities.

Print is a function in python 3 and therefore needs braces around its
arguments.

Range does not cast a gdb.Value object to int in python 3, we have to
do it ourselves.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1453464520-3882-4-git-send-email-frankja@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26 15:58:14 +01:00
Janosch Frank
4789020384 scripts/dump-guest-memory.py: Make methods functions
The functions dealing with qemu components rarely used parts of the
class, so they were moved out of the class.

As the uintptr_t variable is needed both within and outside the class,
it was made a constant and moved to the top.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1453464520-3882-3-git-send-email-frankja@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26 15:58:14 +01:00
Janosch Frank
ca81ce72b4 scripts/dump-guest-memory.py: Move constants to the top
The constants bloated the class definition and were therefore moved to
the top.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Message-Id: <1453464520-3882-2-git-send-email-frankja@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-01-26 15:58:14 +01:00
Michael S. Tsirkin
0c71d41e2a scripts/dump-guest-memory.py: fix after RAMBlock change
commit 9b8424d573
    "exec: split length -> used_length/max_length"
changed field names in struct RAMBlock

It turns out that scripts/dump-guest-memory.py was
poking at this field, update it accordingly.

Cc: qemu-stable@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <1440666378-3152-1-git-send-email-mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-09-09 15:34:55 +02:00
Mike Day
0d53d9fe8a exec: convert ram_list to QLIST
QLIST has RCU-friendly primitives, so switch to it.

Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Mike Day <ncmike@ncultra.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-02-16 17:30:20 +01:00
Laszlo Ersek
3e16d14fd9 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>
2014-01-26 13:06:48 +02:00