crash (8.0.4-1ubuntu2.1) noble; urgency=medium

  * Enable crash to open coredumps generated on 6.14 HWE kernels (LP: #2125145)
    - d/p/0002-Fix-mount-command-failure-on-Linux-6.8-rc1-and-later.patch:
      Reflects a change in the kernel's tracking of mounts in an rbtree
    - d/p/0003-Reflect-__-start-end-_init_task-kernel-symbols-rename.patch: A
      corresponding commit to match a change in the kernel's memory map on 6.10
      and newer
    - d/p/0004-X86-64-fix-for-crash-session-loading-failure.patch: Resolve an
      issue that prevents crash session from loading on X86_64
    - d/p/0005-arm64-Add-gdb-stack-unwind-support.patch: Enable gdb to
      correctly traverse the call stack, preventing errors where crash cannot
      determine the starting task frame
    - d/p/0006-Fix-the-failing-of-cmd-files-for-v6.14-rc1-kernel.patch: Fix cmd
      files by matching rename of kernel struct member d_iname to d_shortname

 -- Bryan Fraschetti <bryan.fraschetti@canonical.com>  Fri, 03 Oct 2025 17:26:43 -0400

crash (8.0.4-1ubuntu2) noble; urgency=high

  * No change rebuild for 64-bit time_t and frame pointers.

 -- Julian Andres Klode <juliank@ubuntu.com>  Mon, 08 Apr 2024 17:55:38 +0200

crash (8.0.4-1ubuntu1) noble; urgency=medium

  * Merge with Debian unstable. Remaining changes: (LP: #2047861)
    - d/t/live: If the "live" autopkgtest fails with a recommendation to
      try /proc/kcore instead of the default, attempt that before
      failing the test. LP 1858958.
    - d/t/live: Fix logic issue in "live" autopkgtest introduced in the
      last upload.
    - d/t/live: Fix test, as if will return 0 when no cases were true.
    - d/t/control: Add linux-libc-dev dependency for the autopkg test.
      This package gets usually broken with kernel upgrades, so let it
      already show in the autopkg test.
    - d/t/control: Run autopkg test with allow-stderr.
  * Drop changes:
    - d/p/0002-Fix-compilation-error-due-to-new-strlcpy-function.patch
      [ included upstream in 8.0.4 ]
    - d/p/0003-Support-module-memory-layout-change-on-Linux-6.4.patch
      [ included upstream in 8.0.4 ]

 -- Mauricio Faria de Oliveira <mfo@canonical.com>  Tue, 02 Jan 2024 19:09:28 -0300

crash (8.0.4-1) unstable; urgency=medium

  * New upstream (Closes: #1057009)
  * a6832f608cb5 crash-8.0.3 -> crash-8.0.4
  * 262b1c71b485 Fix printing incorrect panic string issue
  * 55a43bcefa20 Fix compilation error and warning with gcc-4.8.5
  * fc6ed525407f gdb: Verify COFF symbol stringtab offset
  * a8e5e4cbae54 gdb: Avoid buffer overflow in ada_decode
  * 0172e35083b5 Fix "rd" command to display data on zram on Linux 5.17 and
    later
  * ac097d6cb157 diskdump: add hook for additional checks on prstatus notes
    validity
  * 5e758aaa0fd8 Make "clear" external command runnable without "!" and
    alias-able
  * 578fc08b8255 memory_driver: Support overriding kernel directory
  * 1cfd513ea9c8 memory_driver: Use designated initializer for 'crash_dev'
  * 3c44056efef2 memory_driver: Ensure PWD points to the current directory
  * c9a732d0f6ab arm64: Fix "vtop" command to display swap information on
    Linux 5.19 and later
  * a9291fc1bf61 ppc64: do page traversal if vmemmap_list not populated
  * 27f3ccd6c296 In verify_version() don't require specific syment type values
    for linux_banner symbol to get its address
  * 3253e5ac87c6 Fix "ps/vm" commands to display the memory usage for exiting
    tasks
  * 1aa93cd33fa1 RISCV64: Add KASLR support
  * f774fe0f59b4 deduplicate kernel_version open-coded parser
  * eeaed479a438 Fix "kmem -s|-S" not working properly when
    CONFIG_SLAB_FREELIST_HARDENED is enabled
  * bc145861bfeb Revert "Fix "kmem -s|-S" not working properly on RHEL8.6 and
    later"
  * ff963b795b3f RISCV64: Use va_kernel_pa_offset in VTOP()
  * 69f38d777450 Fix "ps/vm" commands to display correct memory usage
  * 558aecc98987 Fix "foreach" command with "DE" state to display only
    expected tasks
  * c74f375e0ef7 Fix get_linux_banner_from_vmlinux() for vmlinux without
    ".rodata" symbol
  * aa5763800d61 Fix warning about kernel version inconsistency during crash
    startup
  * f0b59524624b Fix segmentation fault by "tree -s" option with Maple Tree
  * 38d35bd1423c Fix "irq [-a|-s]" options on Linux 6.5-rc1 and later
  * d17d51a92a3a Exclude zero entries from do_maple_tree() return value
  * b76e116c50ff vmware: Improve output when we fail to read vmware 'vmsn'
    file
  * 6d0be1316aa3 Fix "irq -a" option on Linux 6.0 and later
  * 4ee56105881d Fix compilation error due to new strlcpy function that glibc
    added
  * 88580068b7dd Fix failure of gathering task table on Linux 6.5-rc1 and
    later
  * 7750e61fdb2a Support module memory layout change on Linux 6.4
  * 8b24b2025fb4 ppc64: Remove redundant PTE checks
  * 6c8cd9b5dcf4 arm64: Fix again segfault in
    arm64_is_kernel_exception_frame() when corrupt stack pointer address is
    given
  * 91a76958e4a8 Revert "Fix segfault in arm64_is_kernel_exception_frame()
    when corrupt stack pointer address is given"
  * ec1e61b33a70 Fix invalid structure size error during crash startup on
    ppc64
  * 77d8621876c1 x86_64: Fix "bt" command printing stale entries on Linux 6.4
    and later
  * 8527bbff71cb Output prompt when stdin is not a TTY
  * 9868ebc8e648 Fix segfault in arm64_is_kernel_exception_frame() when
    corrupt stack pointer address is given
  * db8c030857b4 diskdump/netdump: fix segmentation fault caused by failure of
    stopping CPUs
  * a0eceb041dfa arm64/x86_64: Enhance "vtop" command to show zero_pfn
    information
  * 342cf340ed03 Fix "kmem -v" option displaying no regions on Linux 6.3 and
    later
  * 58c1816521c2 Fix failure of "dev -d|-D" options on Linux 6.4 and later
    kernels
  * 040a56e9f9d0 Fix kernel version macros for revision numbers over 255
  * 2505a65ff547 Mark start of 8.0.4 development phase with version 8.0.3++

 -- Troy Heber <troyh@debian.org>  Mon, 27 Nov 2023 14:43:03 -0700

crash (8.0.3+ds1-3ubuntu1) noble; urgency=medium

  * Merge with Debian unstable. Remaining changes: (LP: #2042357)
    - d/t/live: If the "live" autopkgtest fails with a recommendation to
      try /proc/kcore instead of the default, attempt that before
      failing the test. LP 1858958.
    - d/t/live: Fix logic issue in "live" autopkgtest introduced in the
      last upload.
    - d/t/live: Fix test, as if will return 0 when no cases were true.
    - d/t/control: Add linux-libc-dev dependency for the autopkg test.
      This package gets usually broken with kernel upgrades, so let it
      already show in the autopkg test.
    - d/t/control: Run autopkg test with allow-stderr.
  * Drop changes:
    - d/rules: Build without lto. Fails to build gdb on ppc64el. That
      should be fixed, once gdb is updated to a more recent version
      (e.g. 10.x). [This line is already commented out since Mantic.]
  * New changes:
    - d/p/0002-Fix-compilation-error-due-to-new-strlcpy-function.patch:
      Fix FTBFS due to strlcpy() introduced in glibc 2.38.
    - d/p/0003-Support-module-memory-layout-change-on-Linux-6.4.patch:
      Fix fatal 'crash: invalid structure member offset: module_core_size'

 -- Mauricio Faria de Oliveira <mfo@canonical.com>  Tue, 07 Nov 2023 15:00:36 -0300

crash (8.0.3+ds1-3) unstable; urgency=medium

  * New upload to resolve missing gdb

 -- Troy Heber <troyh@debian.org>  Thu, 02 Nov 2023 14:23:03 -0600

crash (8.0.3-2) unstable; urgency=medium

  * Fix to include gdb

 -- Troy Heber <troyh@debian.org>  Mon, 30 Oct 2023 09:12:36 -0600

crash (8.0.3-1) unstable; urgency=medium

  * New upstream (Closes: #1054805)
  * https://github.com/crash-utility/crash/compare/8.0.2...8.0.3

 -- Troy Heber <troyh@debian.org>  Sat, 28 Oct 2023 12:21:36 -0600

crash (8.0.2-1ubuntu1) mantic; urgency=medium

  * Merge with Debian; remaining changes:
    - Add linux-libc-dev dependency for the autopkg test. This package
      gets usually broken with kernel upgrades, so let it already show
      in the autopkg test.
    - Run autopkg test with allow-stderr.

 -- Matthias Klose <doko@ubuntu.com>  Thu, 06 Jul 2023 16:49:16 +0200

crash (8.0.2-1) unstable; urgency=medium
  * New upstream
  * commit f1cd581d1c4afa5b8ffdfaa6a3ea9f545fe4ec91
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Nov 16 13:13:39 2022 +0900
  *
  *     crash-8.0.1 -> crash-8.0.2
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit a158590f475c8d6d504b0c5e28b3cd91cfd47877
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Wed Nov 9 14:21:57 2022 +0800
  *
  *     Fix for "ps/vm" commands to display correct %MEM and RSS values
  *
  *     The ps/vm commands may print the bogus value of the %MEM and RSS, the
  *     reason is that the counter of rss stat is updated in asynchronous manner
  *     and may become negative, when the SPLIT_RSS_COUNTING is enabled in
  *     kernel.
  *
  *     As a result, crash will read it from memory and convert from negative to
  *     unsigned long integer, eventually it overflows and gets a big integer.
  *     For example:
  *
  *       crash> ps 1393
  *           PID    PPID  CPU       TASK        ST  %MEM      VSZ      RSS  COMM
  *          1393       1  24  ffff9584bb542100  RU  541298032135.9     4132 18014398509481908  enlinuxpc64
  *                                                  ^^^^^^^^^^^^^^          ^^^^^^^^^^^^^^^^^
  *
  *     This is unexpected, crash needs to correct its value for this case.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 21139d9456ee41ffc8cec804dc530d6934ddac89
  * Author: Matias Ezequiel Vara Larsen <matiasevara@gmail.com>
  * Date:   Mon Oct 24 11:35:29 2022 +0200
  *
  *     Fix segmentation fault in page_flags_init_from_pageflag_names()
  *
  *     When read_string() fails in page_flags_init_from_pageflag_names(),
  *     error() dereferences the name variable to print the string that the
  *     variable points to. However, name points to a string that is not in
  *     crash's memory-space thus triggering a segmentation fault.
  *
  *     This patch replaces "%s" in the error message with "%lx" so the address
  *     is printed instead.  Also replaces "%ld" for mask with "%lx".
  *
  *     [ kh: changed the conversion specifiers and commit message ]
  *
  *     Signed-off-by: Matias Ezequiel Vara Larsen <matias.vara@vates.fr>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 487551488b15fcd135b29990593699a121730219
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Tue Oct 4 18:57:11 2022 +0800
  *
  *     ppc64: still allow oneto move on if the emergency stacks info fails to
  *     initialize
  *
  *     Currently crash will fail and then exit, if the initialization of
  *     the emergency stacks information fails. In real customer environments,
  *     sometimes, a vmcore may be partially damaged, although such vmcores
  *     are rare. For example:
  *
  *       # ./crash ../3.10.0-1127.18.2.el7.ppc64le/vmcore
  *       ../3.10.0-1127.18.2.el7.ppc64le/vmlinux  -s
  *       crash: invalid kernel virtual address: 38  type:
  *       "paca->emergency_sp"
  *       #
  *
  *     Lets try to keep loading vmcore if such issues happen, so call
  *     the readmem() with the RETURN_ON_ERROR instead of FAULT_ON_ERROR,
  *     which allows the crash move on.
  *
  *     Reported-by: Dave Wysochanski <dwysocha@redhat.com>
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 3b5e3e1583a1f596360c04e8a322e30cf88f27ab
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Mon Sep 19 17:49:23 2022 +0800
  *
  *     Let "kmem" print task context with physical address
  *
  *     Patch [1] enables "kmem" to print task context if the given virtual
  *     address is a vmalloced stack.
  *
  *     This patch lets "kmem" print task context also when the given address
  *     is a physical address.
  *
  *     Before:
  *         crash> kmem 1883700e28
  *            VMAP_AREA         VM_STRUCT                 ADDRESS RANGE                SIZE
  *         ffff94eb9102c640  ffff94eb9102b140  ffffb7efce9b8000 - ffffb7efce9bd000    20480
  *
  *               PAGE         PHYSICAL      MAPPING       INDEX CNT FLAGS
  *         ffffdd28220dc000 1883700000                0        0  1 50000000000000
  *
  *     After:
  *         crash> kmem 1883700e28
  *             PID: 847
  *         COMMAND: "khungtaskd"
  *            TASK: ffff94f8038f4000  [THREAD_INFO: ffff94f8038f4000]
  *             CPU: 72
  *           STATE: TASK_RUNNING (PANIC)
  *
  *            VMAP_AREA         VM_STRUCT                 ADDRESS RANGE                SIZE
  *         ffff94eb9102c640  ffff94eb9102b140  ffffb7efce9b8000 - ffffb7efce9bd000    20480
  *
  *               PAGE         PHYSICAL      MAPPING       INDEX CNT FLAGS
  *         ffffdd28220dc000 1883700000                0        0  1 50000000000000
  *
  *     [1]: https://listman.redhat.com/archives/crash-utility/2022-September/010115.html
  *
  *     [ kh: squashed the 4/4 patch into 3/4 ]
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 60cb8650a0126abda661c44d198ebde514eca3e2
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Mon Sep 19 17:49:22 2022 +0800
  *
  *     Fix page offset issue when converting physical to virtual address
  *
  *     When trying to convert a physical address to its virtual
  *     address in dump_vmap_area() and dump_vmlist(), the vi->retval
  *     is added by 2 values: the page aligned address "pcheck"
  *     and page offset address "PAGEOFFSET(paddr)".
  *
  *     However "paddr" is given by "pcheck", is also page aligned,
  *     so "PAGEOFFSET(paddr)" is always 0.
  *
  *     In this patch, we will use PAGEOFFSET(vi->spec_addr) to give the
  *     page offset, vi->spec_addr is the physical address we'd like
  *     to convert, which contains the correct page offset.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit ad1397a73594d65aaad9d0b9a94a1dd75d8c61dd
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Mon Sep 19 17:49:21 2022 +0800
  *
  *     Fix "kmem" failing to print task context when address is vmalloced stack
  *
  *     When kernel enabled CONFIG_VMAP_STACK, stack can be allocated to
  *     vmalloced area. Currently crash didn't handle the case, as a result,
  *     "kmem" will not print the task context as expected. This patch fix the
  *     bug by checking if the address is a vmalloced stack first.
  *
  *     Before:
  *         crash> kmem ffffb7efce9bbe28
  *            VMAP_AREA         VM_STRUCT                 ADDRESS RANGE                SIZE
  *         ffff94eb9102c640  ffff94eb9102b140  ffffb7efce9b8000 - ffffb7efce9bd000    20480
  *
  *               PAGE         PHYSICAL      MAPPING       INDEX CNT FLAGS
  *         ffffdd28220dc000 1883700000                0        0  1 50000000000000
  *
  *     After:
  *         crash> kmem ffffb7efce9bbe28
  *             PID: 847
  *         COMMAND: "khungtaskd"
  *            TASK: ffff94f8038f4000  [THREAD_INFO: ffff94f8038f4000]
  *             CPU: 72
  *           STATE: TASK_RUNNING (PANIC)
  *
  *            VMAP_AREA         VM_STRUCT                 ADDRESS RANGE                SIZE
  *         ffff94eb9102c640  ffff94eb9102b140  ffffb7efce9b8000 - ffffb7efce9bd000    20480
  *
  *               PAGE         PHYSICAL      MAPPING       INDEX CNT FLAGS
  *         ffffdd28220dc000 1883700000                0        0  1 50000000000000
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 4ea3a806d11f000f2eb1ddc72c2b7a543e319f64
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Fri Sep 16 14:00:01 2022 +0800
  *
  *     Fix for the invalid linux_banner pointer issue
  *
  *     Currently, crash may fail with the following error:
  *
  *       # ./crash -s vmlinux vmcore
  *       WARNING: invalid linux_banner pointer: 65762078756e694c
  *       crash: vmlinux and vmcore do not match!
  *
  *     The reason is that the type of the symbol in the data segment may be
  *     defined as 'D' or 'd'. The crash only handled the type 'D', but it
  *     didn't deal with the type 'd'. For example:
  *
  *       # nm vmlinux | grep linux_banner
  *       ffffffff827cfa80 d linux_banner
  *
  *     It has been observed that a vmlinux compiled by clang has this type.
  *     Let's add the type 'd' recognition to solve such issue.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit bdbf5887d6259ea3108d4fa674f3794adad54d52
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Thu Sep 1 13:42:28 2022 +0900
  *
  *     Fix gcc-11 compiler warnings on gdb-10.2/gdb/symtab.c
  *
  *     Without the patch, the following gcc-11 compiler warnings are emitted
  *     for gdb-10.2/gdb/symtab.c:
  *
  *     symtab.c: In function 'void gdb_get_datatype(gnu_request*)':
  *     symtab.c:7131:31: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
  *       7131 |         register struct type *type;
  *            |                               ^~~~
  *     symtab.c:7132:31: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
  *       7132 |         register struct type *typedef_type;
  *            |                               ^~~~~~~~~~~~
  *     ...
  *
  *     Usually we don't fix compiler warnings for gdb, but these are emitted
  *     even by "make clean ; make warn", which doesn't recompile the whole
  *     gdb, so it would be better to fix.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 51acac75cdb20caab30a85ebfec5906efe034477
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Thu Sep 1 14:03:09 2022 +0900
  *
  *     Fix gcc-12 compiler warnings on lkcd_*.c
  *
  *     Without the patch, the following gcc-12 compiler warnings are emitted
  *     for lkcd_*.c:
  *
  *     lkcd_v1.c: In function 'dump_lkcd_environment_v1':
  *     lkcd_v1.c:252:20: warning: the comparison will always evaluate as 'true' for the address of 'dh_panic_string' will never be NULL [-Waddress]
  *       252 |                 dh && dh->dh_panic_string &&
  *           |                    ^~
  *     In file included from lkcd_v1.c:21:
  *     lkcd_vmdump_v1.h:108:30: note: 'dh_panic_string' declared here
  *       108 |         char                 dh_panic_string[DUMP_PANIC_LEN];
  *           |                              ^~~~~~~~~~~~~~~
  *     ...
  *
  *     Reported-by: Lianbo Jiang <lijiang@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 5b9d3e98cda9d99f3277aabec30d076e62cc5e71
  * Author: Chunguang.Xu <chunguang.xu@shopee.com>
  * Date:   Thu Aug 25 12:07:20 2022 +0800
  *
  *     Add debian/ubuntu vmlinux location to default search dirs
  *
  *     Now crash cannot find debian/ubuntu kernel vmlinux, we need to
  *     explicitly specify the path to vmlinux. Try to add the debian
  *     vmlinux location to default search directories.
  *
  *     Signed-off-by: Chunguang Xu <chunguang.xu@shopee.com>
  *
  * commit 3ed9ec5c8d09cffac9772abbf54214125ade9127
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Wed Aug 31 11:54:15 2022 +0800
  *
  *     x86_64: Correct the identifier when locating the call instruction
  *
  *     The previous implementation to locate the call instruction is
  *     to strstr "call", then check whether the previous char is ' '
  *     or '\t'. The implementation is problematic. For example it
  *     cannot resolve the following disassembly string:
  *
  *     "0xffffffffc0995378 <nfs41_callback_svc+344>:\tcall   0xffffffff8ecfa4c0 <schedule>\n"
  *
  *     strstr will locate the "_call" and char check fails,
  *     as a result, extract_hex fails to get the calling address.
  *
  *     NOTE: the issue is more likely to be reproduced when patch[1] applied.
  *     Because without patch[1], the disassembly string will be as follows,
  *     so the issue is no longer reproducible.
  *
  *     "0xffffffffc0995378:\tcall   0xffffffff8ecfa4c0 <schedule>\n"
  *
  *     Before the patch:
  *         crash> bt 1472
  *         PID: 1472     TASK: ffff8c121fa72f70  CPU: 18   COMMAND: "nfsv4.1-svc"
  *          #0 [ffff8c16231a3db8] __schedule at ffffffff8ecf9ef3
  *          #1 [ffff8c16231a3e40] schedule at ffffffff8ecfa4e9
  *
  *     After the patch:
  *         crash> bt 1472
  *         PID: 1472     TASK: ffff8c121fa72f70  CPU: 18   COMMAND: "nfsv4.1-svc"
  *          #0 [ffff8c16231a3db8] __schedule at ffffffff8ecf9ef3
  *          #1 [ffff8c16231a3e40] schedule at ffffffff8ecfa4e9
  *          #2 [ffff8c16231a3e50] nfs41_callback_svc at ffffffffc099537d [nfsv4]
  *          #3 [ffff8c16231a3ec8] kthread at ffffffff8e6b966f
  *          #4 [ffff8c16231a3f50] ret_from_fork at ffffffff8ed07898
  *
  *     This patch fix the issue by strstr "\tcall" and " call", to
  *     locate the correct call instruction.
  *
  *     [1]: https://listman.redhat.com/archives/crash-utility/2022-August/010085.html
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 2145b2bb79c59aa25c5155a8f9851554d1813fb9
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Wed Aug 31 11:54:13 2022 +0800
  *
  *     Let gdb get kernel module symbols info from crash
  *
  *     Gdb will try to resolve an address to its corresponding symbol name
  *     such as when printing a structure. It works fine for kernel symbols,
  *     because gdb can find them through vmlinux. However as for kernel
  *     modules symbols, crash resolves them by dig into "struct module",
  *     which gdb don't know. As a result, gdb fails to translate a kernel
  *     module address to its symbol name without "mod -s|-S" options. For
  *     example we can reproduce the issue as follows.
  *
  *         crash> timer
  *         ....
  *         4331308176       336  ffff94ea24240860  ffffffffc03762c0  <estimation_timer>
  *         ....
  *         crash> sym 0xffffffffc03762c0
  *         ffffffffc03762c0 (t) estimation_timer [ip_vs]
  *
  *     Before patch:
  *         crash> timer_list ffff94ea24240860
  *         struct timer_list {
  *           ....
  *           function = 0xffffffffc03762c0,
  *           ....
  *         }
  *
  *     After patch:
  *         crash> timer_list ffff94ea24240860
  *         struct timer_list {
  *           ....
  *           function = 0xffffffffc03762c0 <estimation_timer>,
  *           ....
  *         }
  *
  *     In this patch, we add an interface for gdb, when gdb trying to build
  *     kernel module's address symbolic, the info can be get from crash.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 9cbfea67eb4f094d47cd841b73ddbbdbe6b58696
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Thu Aug 25 14:39:44 2022 +0800
  *
  *     Fix "task -R" by adding end identifier for union in task_struct
  *
  *     Previously, the start and end identifiers for union are "  {\n" and
  *     "  }, \n".  However the end identifier is not always as expected.
  *     "  },\n" can also be the end identifier with gdb-10.2.  As a result,
  *     variable "randomized" is in incorrect state after union, and fails to
  *     identify the later struct members.  For example, we can reproduce the
  *     issue as follows:
  *
  *         crash> task
  *         PID: 847      TASK: ffff94f8038f4000  CPU: 72   COMMAND: "khungtaskd"
  *         struct task_struct {
  *           thread_info = {
  *             flags = 2148024320,
  *             status = 0,
  *             preempt_lazy_count = 0
  *           },
  *           {
  *             <the union>
  *           },
  *           ...
  *           wake_entry = {
  *             next = 0x0
  *           },
  *           ...
  *
  *     Before patch:
  *
  *         crash> task -R wake_entry
  *         PID: 847      TASK: ffff94f8038f4000  CPU: 72   COMMAND: "khungtaskd"
  *
  *     After patch:
  *
  *         crash> task -R wake_entry
  *         PID: 847      TASK: ffff94f8038f4000  CPU: 72   COMMAND: "khungtaskd"
  *           wake_entry = {
  *             next = 0x0
  *           },
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit f02c8e87fccb1a92fbc025883bc69b6467a4e6c8
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Mon Aug 22 09:29:32 2022 +0000
  *
  *     arm64: use TCR_EL1_T1SZ to get the correct info if vabits_actual is
  *     missing
  *
  *     After kernel commit 0d9b1ffefabe ("arm64: mm: make vabits_actual a build
  *     time constant if possible"), the vabits_actual is not compiled to kernel
  *     symbols when "VA_BITS > 48" is false.
  *
  *     So the crash will not find the vabits_actual symbol, and it will fail
  *     in the end like this:
  *
  *       # ./crash
  *       ...
  *       WARNING: VA_BITS: calculated: 46  vmcoreinfo: 48
  *       crash: invalid kernel virtual address: ffff88177ffff000  type: "pud page"
  *
  *     This patch introduces the arm64_set_va_bits_by_tcr(), and if crash
  *     cannot find vabits_actual symbol, it will use the TCR_EL1_T1SZ
  *     register to get the correct VA_BITS_ACTUAL/VA_BITS/VA_START.
  *
  *     Tested this patch with:
  *       1.) the live mode with /proc/kcore
  *       2.) the kdump file with /proc/vmcore.
  *
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit 4c85e982d25a259f81b5e8c230a67d40d4527ddf
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Wed Aug 24 10:19:20 2022 +0800
  *
  *     gdb: fix for assigning NULL to std::string
  *
  *     When trying to load a module with "mod -s" without its separated debug
  *     info file installed, the crash utility will abort as below:
  *
  *       crash> mod -s kpatch_test kpatch_test.ko
  *       ...
  *       terminate called after throwing an instance of 'std::logic_error'
  *         what():  basic_string::_M_construct null not valid
  *       Aborted (core dumped)
  *
  *     Let's return the std::string() instead of std::string(NULL) when a
  *     string is null, because the check_specified_kernel_debug_file() may
  *     return NULL.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit c2743ad474529951ace2b8ec712bf373f3a07d4c
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Mon Aug 22 11:59:46 2022 +0900
  *
  *     Makefile: Fix unnecessary re-patching with coreutils-9.0
  *
  *     "sum" command in coreutils-9.0 (e.g. Fedora 36) started to output a file
  *     name.  As a result, "make" always detects a change of gdb-10.2.patch
  *     wrongly and re-applies it unnecessarily.
  *
  *     Use standard input to fix it and "md5sum" to improve detection.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 763e221388219b07bd949a9ba48768856908ec6d
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Thu Jul 28 15:11:20 2022 +0800
  *
  *     x86_64: Fix for AMD SME issue
  *
  *     Kernel commit changes(see [1]/[2]) may cause the failure of
  *     crash-utility with the following error:
  *
  *       #./crash /home/vmlinux /home/vmcore
  *       ...
  *       For help, type "help".
  *       Type "apropos word" to search for commands related to "word"...
  *
  *       crash: seek error: physical address: 8000760a14000  type: "p4d page"
  *
  *     Let's get the "NUMBER(sme_mask)" from vmcoreinfo, and try to remove
  *     the C-bit from the page table entries, the intention is to get the
  *     true physical address.
  *
  *     Related kernel commits:
  *     [1] aad983913d77 ("x86/mm/encrypt: Simplify sme_populate_pgd() and sme_populate_pgd_large()")
  *     [2] e7d445ab26db ("x86/sme: Use #define USE_EARLY_PGTABLE_L5 in mem_encrypt_identity.c")
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit f37df7df8a50519d80f04fb48499287892021575
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jul 22 13:44:50 2022 +0900
  *
  *     Fix gcc-11 compiler warning on kvmdump.c
  *
  *     Without the patch, the following gcc-11 compiler warning is emitted for
  *     kvmdump.c:
  *
  *     In function 'write_mapfile_registers',
  *         inlined from 'write_mapfile_trailer' at kvmdump.c:947:3,
  *         inlined from 'kvmdump_init' at kvmdump.c:145:4:
  *     kvmdump.c:972:13: warning: 'write' reading 8 bytes from a region of size 4 [-Wstringop-overread]
  *       972 |         if (write(kvm->mapfd, &kvm->cpu_devices, sizeof(uint64_t)) != sizeof(uint64_t))
  *           |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  *     In file included from kvmdump.c:19:
  *     kvmdump.c: In function 'kvmdump_init':
  *     kvmdump.h:67:18: note: source object 'cpu_devices' of size 4
  *        67 |         uint32_t cpu_devices;
  *           |                  ^~~~~~~~~~~
  *     In file included from defs.h:26,
  *                      from kvmdump.c:18:
  *     /usr/include/unistd.h:378:16: note: in a call to function 'write' declared with attribute 'access (read_only, 2, 3)'
  *       378 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur
  *           |                ^~~~~
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 7591e3c07cef4900f6b0ca797270cb7527fb4e29
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jul 22 13:44:50 2022 +0900
  *
  *     Fix gcc-11 compiler warning on makedumpfile.c
  *
  *     Without the patch, the following gcc-11 compiler warning is emitted for
  *     makedumpfile.c:
  *
  *     In function 'flattened_format_get_osrelease',
  *         inlined from 'check_flattened_format' at makedumpfile.c:236:3:
  *     makedumpfile.c:392:9: warning: 'fclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
  *       392 |         fclose(pipe);
  *           |         ^~~~~~~~~~~~
  *     makedumpfile.c: In function 'check_flattened_format':
  *     makedumpfile.c:380:21: note: returned from 'popen'
  *       380 |         if ((pipe = popen(buf, "r")) == NULL)
  *           |                     ^~~~~~~~~~~~~~~
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit b9c0ed124e422b7e0b1526afa3a691ad0579607b
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jul 22 13:44:50 2022 +0900
  *
  *     Fix gcc-11 compiler warning on symbols.c
  *
  *     Without the patch, the following gcc-11 compiler warning is emitted for
  *     symbols.c:
  *
  *     symbols.c: In function 'cmd_p':
  *     symbols.c:7412:38: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  *      7412 |                         *(cpuspec-1) = ':';
  *           |                         ~~~~~~~~~~~~~^~~~~
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit f374aca364b7e8809f122678aefed1010e3c94bd
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jul 22 13:44:50 2022 +0900
  *
  *     Fix gcc-11 compiler warnings on filesys.c
  *
  *     Without the patch, the following gcc-11 compiler warnings are emitted
  *     for filesys.c:
  *
  *     filesys.c: In function 'mount_point':
  *     filesys.c:718:17: warning: 'pclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
  *       718 |                 pclose(mp);
  *           |                 ^~~~~~~~~~
  *     filesys.c:709:27: note: returned from 'fopen'
  *       709 |                 if ((mp = fopen(mntfile, "r")) == NULL)
  *           |                           ^~~~~~~~~~~~~~~~~~~
  *     filesys.c:738:17: warning: 'pclose' called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
  *       738 |                 pclose(mp);
  *           |                 ^~~~~~~~~~
  *     filesys.c:723:27: note: returned from 'fopen'
  *       723 |                 if ((mp = fopen(mntfile, "r")) == NULL)
  *           |                           ^~~~~~~~~~~~~~~~~~~
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 6722ea102264b54529afc19d347a3a7473670fdd
  * Author: Qianli Zhao <qianli.zhao@horizon.ai>
  * Date:   Mon Jul 4 16:40:01 2022 +0800
  *
  *     arm64: Fix for st->_stext_vmlinux not initialized when set VA_BITS_ACTUAL
  *
  *     Setting st->_stext_vmlinux to UNINITIALIZED to search for "_stext"
  *     from the vmlinux.  In the scenario where kaslr is disabled and
  *     without vmcoreinfo, crash will get the wrong MODULES/VMALLOC ranges
  *     and cause a failure in parsing a raw RAM dumpfile.
  *
  *     Signed-off-by: Qianli Zhao <qianli.zhao@horizon.ai>
  *
  * commit 93b880217de239268315be942c10dfce5649db8b
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Mon Jul 4 10:55:46 2022 +0530
  *
  *     ppc64: use a variable for machdep->machspec
  *
  *     machdpep->machspec is referred to multiple times. The compiler would
  *     likely optimize this but nonetheless, use a variable to optimize in
  *     coding and also improve readability. No functional change.
  *
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit 4dc2f1c32d1c99586e67032c9cd62c5c4334049c
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Mon Jul 4 10:55:45 2022 +0530
  *
  *     ppc64: print emergency stacks info with 'mach' command
  *
  *     Print top address of emergency stacks with 'mach' command.
  *
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit cdd57e8b16aba2f5714673368d6dbc7565d59841
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Mon Jul 4 10:55:44 2022 +0530
  *
  *     ppc64: handle backtrace when CPU is in an emergency stack
  *
  *     A CPU could be in an emergency stack when it is running in real mode
  *     or any special scenario like TM bad thing. Also, there are dedicated
  *     emergency stacks for machine check and system reset interrupt. Right
  *     now, no backtrace is provided if a CPU is in any of these stacks.
  *     This change ensures backtrace is processed appropriately even when
  *     a CPU is in any one of these emergency stacks. Also, if stack info
  *     cannot be found, print that message always instead of only when
  *     verbose logs are enabled.
  *
  *     Related kernel commits:
  *     729b0f715371 ("powerpc/book3s: Introduce exclusive emergency stack for machine check exception.")
  *     b1ee8a3de579 ("powerpc/64s: Dedicated system reset interrupt stack")
  *
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit 4d1b968abb286ea39ea080ae073b0e2b5bfe6c4e
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Mon Jul 4 10:55:43 2022 +0530
  *
  *     ppc64: rename ppc64_paca_init to ppc64_paca_percpu_offset_init
  *
  *     ppc64_paca_init() function is specifically used to initialize percpu
  *     data_offset for kernels older than v2.6.36. So, the name is slightly
  *     misleading. Rename it to ppc64_paca_percpu_offset_init to reflect its
  *     purpose.
  *
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit 3ee5956721d9a67fe8d4c6d5022aa022c5f9a11c
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Mon Jul 4 10:55:42 2022 +0530
  *
  *     ppc64: dynamically allocate h/w interrupt stack
  *
  *     Only older kernel (v2.4) used h/w interrupt stack to store frames when
  *     CPU received IPI. Memory used for this in 'struct machine_specific' is
  *     useless for later kernels. For the sake of backward compatibility keep
  *     h/w interrupt stack but dynamically allocate memory for it and save
  *     some bytes from being wasted.
  *
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit c67ce5bbb8e37d28f1c26b239b203a6561f574c1
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Mon Jul 4 10:55:41 2022 +0530
  *
  *     ppc64: fix bt for '-S' case
  *
  *     Passing '-S' option to 'bt' command was intended to specify the stack
  *     pointer manually. But get_stack_frame() handling on ppc64 is ignoring
  *     this option altogether. Fix it.
  *
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit d8869b08548362345fc34e4cf17a1eac9bddec6b
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Jun 22 08:32:59 2022 +0900
  *
  *     Extend field length of task attributes
  *
  *     Nowadays, some machines have many CPU cores and memory, and some
  *     distributions have a larger kernel.pid_max parameter, e.g. 7 digits.
  *     This impairs the readability of a few commands, especially "ps" and
  *     "ps -l|-m" options.
  *
  *     Let's extend the field length of the task attributes, PID, CPU, VSZ,
  *     and RSS to improve the readability.
  *
  *     Without the patch:
  *       crash> ps
  *          PID    PPID  CPU       TASK        ST  %MEM     VSZ    RSS  COMM
  *       ...
  *         2802197  2699997   2  ffff916f63c40000  IN   0.0  307212  10688  timer
  *         2802277      1   0  ffff9161a25bb080  IN   0.0  169040   2744  gpg-agent
  *         2806711  3167854  10  ffff9167fc498000  IN   0.0  127208   6508  su
  *         2806719  2806711   1  ffff91633c3a48c0  IN   0.0   29452   6416  bash
  *         2988346      1   5  ffff916f7c629840  IN   2.8 9342476 1917384  qemu-kvm
  *
  *     With the patch:
  *       crash> ps
  *             PID    PPID  CPU       TASK        ST  %MEM      VSZ      RSS  COMM
  *       ...
  *         2802197 2699997   2  ffff916f63c40000  IN   0.0   307212    10688  timer
  *         2802277       1   0  ffff9161a25bb080  IN   0.0   169040     2744  gpg-agent
  *         2806711 3167854  10  ffff9167fc498000  IN   0.0   127208     6508  su
  *         2806719 2806711   1  ffff91633c3a48c0  IN   0.0    29452     6416  bash
  *         2988346       1   5  ffff916f7c629840  IN   2.8  9342476  1917384  qemu-kvm
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 85f39061390f095e73d9037f015cec077441eb13
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Jun 15 10:50:13 2022 +0900
  *
  *     Fix for "dev" command on Linux 5.11 and later
  *
  *     The following kernel commits eventually removed the bdev_map array in
  *     Linux v5.11 kernel:
  *
  *       e418de3abcda ("block: switch gendisk lookup to a simple xarray")
  *       22ae8ce8b892 ("block: simplify bdev/disk lookup in blkdev_get")
  *
  *     Without the patch, the "dev" command fails to dump block device data
  *     with the following error:
  *
  *       crash> dev
  *       ...
  *       dev: blkdevs or all_bdevs: symbols do not exist
  *
  *     To get block device's gendisk, search blockdev_superblock.s_inodes
  *     instead of bdev_map.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit b8f2ae6b494d706b1e4855b439c4930a6a6a2f5c
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jun 10 16:00:14 2022 +0900
  *
  *     sbitmapq: Limit kernels without sbitmap again
  *
  *     commit 364b2e413c69 ("sbitmapq: remove struct and member validation
  *     in sbitmapq_init()") allowed the use of the "sbitmapq" command
  *     unconditionally.  Without the patch, the command fails with the
  *     following error on kernels without sbitmap:
  *
  *       crash> sbitmapq ffff88015796e550
  *
  *       sbitmapq: invalid structure member offset: sbitmap_queue_sb
  *                 FILE: sbitmap.c  LINE: 385  FUNCTION: sbitmap_queue_context_load()
  *
  *     Now the command supports Linux 4.9 and later kernels since it was
  *     abstracted out, so it can be limited by the non-existence of the
  *     sbitmap structure.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 6bc3b74c6e2b0aaebe1bc164594e53b010efef56
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jun 10 15:52:34 2022 +0900
  *
  *     sbitmapq: Fix for kernels without struct wait_queue_head
  *
  *     The current struct wait_queue_head was renamed by kernel commit
  *     9d9d676f595b ("sched/wait: Standardize internal naming of wait-queue heads")
  *     at Linux 4.13.  Without the patch, on earlier kernels the "sbitmapq"
  *     command fails with the following error:
  *
  *       crash> sbitmapq ffff8801790b3b50
  *       depth = 128
  *       busy = 0
  *       bits_per_word = 32
  *       ...
  *       sbitmapq: invalid structure member offset: wait_queue_head_head
  *                 FILE: sbitmap.c  LINE: 344  FUNCTION: sbitmap_queue_show()
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit c07068266b41450ca6821ee0a1a3adf34206015f
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jun 10 15:21:53 2022 +0900
  *
  *     Make "dev -d|-D" options parse sbitmap on Linux 4.18 and later
  *
  *     There have been a few reports that the "dev -d|-D" options displayed
  *     incorrect I/O stats due to racy blk_mq_ctx.rq_* counters.  To fix it,
  *     make the options parse sbitmap to count I/O stats on Linux 4.18 and
  *     later kernels, which include RHEL8 ones.
  *
  *     To do this, adjust to the blk_mq_tags structure of Linux 5.10 through
  *     5.15 kernels, which contain kernel commit 222a5ae03cdd ("blk-mq: Use
  *     pointers for blk_mq_tags bitmap tags") and do not contain ae0f1a732f4a
  *     ("blk-mq: Stop using pointers for blk_mq_tags bitmap tags").
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 12fe6c7cdd768f87ce6e903a2bbfb0c0591585c5
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jun 10 11:49:47 2022 +0900
  *
  *     sbitmapq: Fix for sbitmap_queue without min_shallow_depth member
  *
  *     The sbitmap_queue.min_shallow_depth member was added by kernel commit
  *     a327553965de ("sbitmap: fix missed wakeups caused by sbitmap_queue_get_shallow()")
  *     at Linux 4.18.  Without the patch, on earlier kernels the "sbitmapq"
  *     command fails with the following error:
  *
  *       crash> sbitmapq ffff89bb7638ee50
  *
  *       sbitmapq: invalid structure member offset: sbitmap_queue_min_shallow_depth
  *                 FILE: sbitmap.c  LINE: 398  FUNCTION: sbitmap_queue_context_load()
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 0d3e86fee5eead93b521a0e20a0e099ede4ab72b
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jun 10 11:49:47 2022 +0900
  *
  *     sbitmapq: Fix for sbitmap_word without cleared member
  *
  *     The sbitmap_word.cleared member was added by kernel commit ea86ea2cdced
  *     ("sbitmap: ammortize cost of clearing bits") at Linux 5.0.  Without the
  *     patch, on earlier kernels the "sbitmapq" command fails with the
  *     following error:
  *
  *       crash> sbitmapq ffff8f1a3611cf10
  *
  *       sbitmapq: invalid structure member offset: sbitmap_word_cleared
  *                 FILE: sbitmap.c  LINE: 92  FUNCTION: __sbitmap_weight()
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 9ce31a14d1083cbb2beb4a8e6eb7b88234b79a99
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Fri Jun 10 11:49:47 2022 +0900
  *
  *     sbitmapq: Fix for sbitmap_queue without ws_active member
  *
  *     The sbitmap_queue.ws_active member was added by kernel commit 5d2ee7122c73
  *     ("sbitmap: optimize wakeup check") at Linux 5.0.  Without the patch, on
  *     earlier kernels the "sbitmapq" command fails with the following error:
  *
  *       crash> sbitmapq ffff8f1a3611cf10
  *
  *       sbitmapq: invalid structure member offset: sbitmap_queue_ws_active
  *                 FILE: sbitmap.c  LINE: 393  FUNCTION: sbitmap_queue_context_load()
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit c672d7a4c290712b32c54329cbdc1e74d122e813
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon Jun 6 19:09:16 2022 +0800
  *
  *     Doc: update man page for the "bpf" and "sbitmapq" commands
  *
  *     The information of the "bpf" and "sbitmapq" commands is missing in the man
  *     page of the crash utility.  Let's add it to the man page.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 68ce0b9a35d77d767872dd1a729c50e4695a30a8
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Thu Jun 2 20:12:56 2022 +0800
  *
  *     Fix for "dev -d|-D" options to support blk-mq change on Linux v5.18-rc1
  *
  *     Kernel commit 4e5cc99e1e48 ("blk-mq: manage hctx map via xarray") removed
  *     the "queue_hw_ctx" member from struct request_queue at Linux v5.18-rc1,
  *     and replaced it with a struct xarray "hctx_table". Without the patch, the
  *     "dev -d|-D" options will print an error:
  *
  *       crash> dev -d
  *       MAJOR GENDISK            NAME       REQUEST_QUEUE      TOTAL  READ WRITE
  *
  *       dev: invalid structure member offset: request_queue_queue_hw_ctx
  *
  *     With the patch:
  *       crash> dev -d
  *       MAJOR GENDISK            NAME       REQUEST_QUEUE      TOTAL  READ WRITE
  *           8 ffff8e99d0a1ae00   sda        ffff8e9c14c59980      10     6     4
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 7095c8fd029e3a33117e3b67de73f504686ebfe2
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Thu Jun 2 20:12:55 2022 +0800
  *
  *     Enhance "dev -d|-D" options to support blk-mq sbitmap
  *
  *     Since Linux 5.16-rc1, which kernel commit 9a14d6ce4135 ("block: remove
  *     debugfs blk_mq_ctx dispatched/merged/completed attributes") removed the
  *     members from struct blk_mq_ctx, crash has not displayed disk I/O statistics
  *     for multiqueue (blk-mq) devices.
  *
  *     Let's parse the sbitmap in blk-mq layer to support it.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit dda5b2d02b8d8de1264f84b6267582aa7a1e5a57
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Tue May 31 17:12:16 2022 +0900
  *
  *     gdb: print details of unnamed struct and union
  *
  *     Currently gdb's "ptype" command does not print the details of unnamed
  *     structure and union deeper than second level in a structure, it prints
  *     only "{...}" instead.  And crash's "struct" and similar commands also
  *     inherit this behavior, so we cannot get the full information of them.
  *
  *     To print the details of them, change the show variable when it is an
  *     unnamed one like crash-7.x.
  *
  *     Without the patch:
  *        crash> struct -o page
  *        struct page {
  *           [0] unsigned long flags;
  *               union {
  *                   struct {...};
  *                   struct {...};
  *        ...
  *
  *     With the patch:
  *        crash> struct -o page
  *        struct page {
  *           [0] unsigned long flags;
  *               union {
  *                   struct {
  *           [8]         struct list_head lru;
  *          [24]         struct address_space *mapping;
  *          [32]         unsigned long index;
  *          [40]         unsigned long private;
  *                   };
  *                   struct {
  *           [8]         dma_addr_t dma_addr;
  *                   };
  *        ...
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 0f162febebc4d11a165dd40cee00f3b0ba691a52
  * Author: Qi Zheng <zhengqi.arch@bytedance.com>
  * Date:   Tue May 24 20:25:54 2022 +0800
  *
  *     bt: arm64: add support for 'bt -n idle'
  *
  *     The '-n idle' option of bt command can help us filter the
  *     stack of the idle process when debugging the dumpfiles
  *     captured by kdump.
  *
  *     This patch supports this feature on ARM64.
  *
  *     Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
  *
  * commit 6833262bf87177d8affe4f91b2e7d2c76ecdf636
  * Author: Qi Zheng <zhengqi.arch@bytedance.com>
  * Date:   Tue May 24 20:25:53 2022 +0800
  *
  *     bt: x86_64: filter out idle task stack
  *
  *     When we use crash to troubleshoot softlockup and other problems,
  *     we often use the 'bt -a' command to print the stacks of running
  *     processes on all CPUs. But now some servers have hundreds of CPUs
  *     (such as AMD machines), which causes the 'bt -a' command to output
  *     a lot of process stacks. And many of these stacks are the stacks
  *     of the idle process, which are not needed by us.
  *
  *     Therefore, in order to reduce this part of the interference information,
  *     this patch adds the -n option to the bt command. When we specify
  *     '-n idle' (meaning no idle), the stack of the idle process will be
  *     filtered out, thus speeding up our troubleshooting.
  *
  *     And the option works only for crash dumps captured by kdump.
  *
  *     The command output is as follows:
  *     crash> bt -a -n idle
  *     [...]
  *     PID: 0      TASK: ffff889ff8c34380  CPU: 8   COMMAND: "swapper/8"
  *
  *     PID: 0      TASK: ffff889ff8c32d00  CPU: 9   COMMAND: "swapper/9"
  *
  *     PID: 0      TASK: ffff889ff8c31680  CPU: 10  COMMAND: "swapper/10"
  *
  *     PID: 0      TASK: ffff889ff8c35a00  CPU: 11  COMMAND: "swapper/11"
  *
  *     PID: 0      TASK: ffff889ff8c3c380  CPU: 12  COMMAND: "swapper/12"
  *
  *     PID: 150773  TASK: ffff889fe85a1680  CPU: 13  COMMAND: "bash"
  *      #0 [ffffc9000d35bcd0] machine_kexec at ffffffff8105a407
  *      #1 [ffffc9000d35bd28] __crash_kexec at ffffffff8113033d
  *      #2 [ffffc9000d35bdf0] panic at ffffffff81081930
  *      #3 [ffffc9000d35be70] sysrq_handle_crash at ffffffff814e38d1
  *      #4 [ffffc9000d35be78] __handle_sysrq.cold.12 at ffffffff814e4175
  *      #5 [ffffc9000d35bea8] write_sysrq_trigger at ffffffff814e404b
  *      #6 [ffffc9000d35beb8] proc_reg_write at ffffffff81330d86
  *      #7 [ffffc9000d35bed0] vfs_write at ffffffff812a72d5
  *      #8 [ffffc9000d35bf00] ksys_write at ffffffff812a7579
  *      #9 [ffffc9000d35bf38] do_syscall_64 at ffffffff81004259
  *         RIP: 00007fa7abcdc274  RSP: 00007fffa731f678  RFLAGS: 00000246
  *         RAX: ffffffffffffffda  RBX: 0000000000000002  RCX: 00007fa7abcdc274
  *         RDX: 0000000000000002  RSI: 0000563ca51ee6d0  RDI: 0000000000000001
  *         RBP: 0000563ca51ee6d0   R8: 000000000000000a   R9: 00007fa7abd6be80
  *         R10: 000000000000000a  R11: 0000000000000246  R12: 00007fa7abdad760
  *         R13: 0000000000000002  R14: 00007fa7abda8760  R15: 0000000000000002
  *         ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
  *     [...]
  *
  *     Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
  *     Acked-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *     Acked-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 9705669a49c341402efd8528e8fe809379dd798d
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Mon May 23 14:48:50 2022 +0900
  *
  *     Makefile: add missing crash_target.o to be cleaned
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 3750803f6ae5f5ad071f86ca916dbbb17b7a83a5
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon May 23 18:04:16 2022 +0800
  *
  *     sbitmapq: fix invalid offset for "sbitmap_word_depth" on Linux v5.18-rc1
  *
  *     Kernel commit 3301bc53358a ("lib/sbitmap: kill 'depth' from
  *     sbitmap_word") removed the depth member from struct sbitmap_word.
  *     Without the patch, the sbitmapq will fail:
  *
  *       crash> sbitmapq 0xffff8e99d0dc8010
  *
  *       sbitmapq: invalid structure member offset: sbitmap_word_depth
  *               FILE: sbitmap.c  LINE: 84  FUNCTION: __sbitmap_weight()
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 530fe6ad7e4d7ff6254596c1219d25ed929e3867
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon May 23 18:04:15 2022 +0800
  *
  *     sbitmapq: fix invalid offset for "sbitmap_queue_round_robin" on Linux
  *     v5.13-rc1
  *
  *     Kernel commit efe1f3a1d583 ("scsi: sbitmap: Maintain allocation
  *     round_robin in sbitmap") moved the round_robin member from struct
  *     sbitmap_queue to struct sbitmap.  Without the patch, the sbitmapq
  *     will fail:
  *
  *       crash> sbitmapq 0xffff8e99d0dc8010
  *
  *       sbitmapq: invalid structure member offset: sbitmap_queue_round_robin
  *               FILE: sbitmap.c  LINE: 378  FUNCTION:
  *               sbitmap_queue_context_load()
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit a295cb40cd5d24fb5995cc78d29c5def3843d285
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon May 23 18:04:14 2022 +0800
  *
  *     sbitmapq: fix invalid offset for "sbitmap_queue_alloc_hint" on Linux v5.13-rc1
  *
  *     Kernel commit c548e62bcf6a ("scsi: sbitmap: Move allocation hint
  *     into sbitmap") moved the alloc_hint member from struct sbitmap_queue
  *     to struct sbitmap.  Without the patch, the sbitmapq will fail:
  *
  *       crash> sbitmapq 0xffff8e99d0dc8010
  *
  *       sbitmapq: invalid structure member offset: sbitmap_queue_alloc_hint
  *               FILE: sbitmap.c  LINE: 365  FUNCTION: sbitmap_queue_context_load()
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 364b2e413c69daf189d2bc0238e3ba9b0dcbd937
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon May 23 18:04:13 2022 +0800
  *
  *     sbitmapq: remove struct and member validation in sbitmapq_init()
  *
  *     Let's remove the struct and member validation from sbitmapq_init(), which
  *     will help the crash to display the actual error when the sbitmapq fails.
  *
  *     Without the patch:
  *       crash> sbitmapq ffff8e99d0dc8010
  *       sbitmapq: command not supported or applicable on this architecture or kernel
  *
  *     With the patch:
  *       crash> sbitmapq ffff8e99d0dc8010
  *
  *       sbitmapq: invalid structure member offset: sbitmap_queue_alloc_hint
  *               FILE: sbitmap.c  LINE: 365  FUNCTION: sbitmap_queue_context_load()
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit ae52398a13fa9a238279114ed671c7c514c154ee
  * Author: Sourabh Jain <sourabhjain@linux.ibm.com>
  * Date:   Mon May 9 12:49:56 2022 +0530
  *
  *     ppc64: update the NR_CPUS to 8192
  *
  *     Since the kernel commit 2d8ae638bb86 ("powerpc: Make the NR_CPUS max 8192")
  *     the NR_CPUS on Linux kernel ranges from 1-8192. So let's match NR_CPUS with
  *     the max NR_CPUS count on the Linux kernel.
  *
  *     Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
  *
  * commit 0ca55e460757172879ebc06c1a18c97163711dab
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Tue May 10 10:27:44 2022 +0900
  *
  *     Mark start of 8.0.2 development phase with version 8.0.1++
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
 -- Troy Heber <troyh@debian.org>  Thu, 17 Nov 2022 11:27:25 -0700

crash (8.0.1-1) UNRELEASED; urgency=medium
  * commit 2d193468e5fe7ee1c6be4c73083cc5ef8d922b74
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Tue Apr 26 10:56:43 2022 +0900
  *
  *     crash-8.0.0 -> crash-8.0.1
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit b811a045ec994ead31b0535db221d6e89596fc99
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Wed Mar 30 19:03:23 2022 +0000
  *
  *     diskdump: Optimize the boot time
  *
  *     1.) The vmcore file maybe very big.
  *
  *         For example, I have a vmcore file which is over 23G,
  *         and the panic kernel had 767.6G memory,
  *         its max_sect_len is 4468736.
  *
  *         Current code costs too much time to do the following loop:
  *         ..............................................
  *             for (i = 1; i < max_sect_len + 1; i++) {
  *                     dd->valid_pages[i] = dd->valid_pages[i - 1];
  *                     for (j = 0; j < BITMAP_SECT_LEN; j++, pfn++)
  *                             if (page_is_dumpable(pfn))
  *                                     dd->valid_pages[i]++;
  *         ..............................................
  *
  *         For my case, it costs about 56 seconds to finish the
  *         big loop.
  *
  *         This patch moves the hweightXX macros to defs.h,
  *         and uses hweight64 to optimize the loop.
  *
  *         For my vmcore, the loop only costs about one second now.
  *
  *     2.) Tests result:
  *       # cat ./commands.txt
  *           quit
  *
  *      Before:
  *
  *       #echo  3 > /proc/sys/vm/drop_caches;
  *       #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
  *        ............................
  *             real    1m54.259s
  *             user    1m12.494s
  *             sys     0m3.857s
  *        ............................
  *
  *      After this patch:
  *
  *       #echo  3 > /proc/sys/vm/drop_caches;
  *       #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
  *        ............................
  *             real    0m55.217s
  *             user    0m15.114s
  *             sys     0m3.560s
  *        ............................
  *
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit a3344239743bdf1c72aae0fd05903e2654dee268
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Mon Apr 4 17:47:53 2022 +0000
  *
  *     diskdump: use mmap/madvise to improve the start-up
  *
  *     Sometimes, the size of bitmap in vmcore can be very large, such as over
  *     256M. This patch uses mmap/madvise to improve the performance of reading
  *     bitmap in the non-FLAT_FORMAT code path.
  *
  *     Without the patch:
  *         #echo  3 > /proc/sys/vm/drop_caches;
  *         #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
  *         ............................
  *             real    0m55.217s
  *             user    0m15.114s
  *             sys     0m3.560s
  *         ............................
  *
  *     With the patch:
  *         #echo  3 > /proc/sys/vm/drop_caches;
  *         #time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
  *         ............................
  *             real    0m44.097s
  *             user    0m19.031s
  *             sys     0m1.620s
  *         ............................
  *
  *     Note:
  *         Test files:
  *             vmlinux: 272M
  *             vmcore : 23G (bitmap_len: 4575985664)
  *         #cat ./commands.txt
  *             quit
  *
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit 87369080a480202c430ca823f83aa89c217fdc8f
  * Author: Rongwei Wang <rongwei.wang@linux.alibaba.com>
  * Date:   Wed Apr 6 22:38:40 2022 +0800
  *
  *     arm64: handle 1GB block for VM_L4_4K
  *
  *     When arm64 is configured with PAGE_SIZE=4k and 4 level
  *     translation, the pagetable of all pages may be created with
  *     block mapping or contiguous mapping as much as possible, likes
  *     disable CONFIG_RODATA_FULL_DEFAULT_ENABLED. But now, vtop
  *     command can not handle 1GB block (PUD mapping) well, and just
  *     shows a seek error:
  *
  *     crash> vtop ffff00184a800000
  *     VIRTUAL           PHYSICAL
  *     ffff00184a800000  188a800000
  *
  *     PAGE DIRECTORY: ffff8000110aa000
  *        PGD: ffff8000110aa000 => 203fff9003
  *        PUD: ffff001fffff9308 => 68001880000705
  *        PMD: ffff0018400002a0 => ffff8000103b4fd0
  *     vtop: seek error: kernel virtual address: ffff7fffd03b4000  type: "page table"
  *
  *     This patch fixes it, and shows as following:
  *
  *     crash> vtop ffff00184a800000
  *     VIRTUAL           PHYSICAL
  *     ffff00184a800000  188a800000
  *
  *     PAGE DIRECTORY: ffff8000110aa000
  *        PGD: ffff8000110aa000 => 203fff9003
  *        PUD: ffff001fffff9308 => 68001880000705
  *       PAGE: 1880000000  (1GB)
  *
  *          PTE         PHYSICAL   FLAGS
  *     68001880000705  1880000000  (VALID|SHARED|AF|PXN|UXN)
  *
  *           PAGE         PHYSICAL      MAPPING       INDEX CNT FLAGS
  *     fffffe00610a0000 188a800000                0        0  0 77fffe0000000000
  *
  *     Acked-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *     Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
  *
  * commit b89f9ccf511a6e3db17f44a815e415664937d7e6
  * Author: xiaer1921 <xiaer1921@gmail.com>
  * Date:   Thu Apr 7 15:05:17 2022 +0800
  *
  *     Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
  *
  *     Since the following kernel commits split slab info from struct page
  *     into struct slab, crash cannot get several slab related offsets from
  *     struct page.
  *
  *       d122019bf061 ("mm: Split slab into its own type")
  *       401fb12c68c2 ("mm: Differentiate struct slab fields by sl*b implementations")
  *       07f910f9b729 ("mm: Remove slab from struct page")
  *
  *     Without the patch, "kmem -s|-S" options cannot work correctly on kernels
  *     configured with CONFIG_SLAB with the following error:
  *
  *       crash> kmem -s
  *       kmem: invalid structure member offset: page_active
  *             FILE: memory.c  LINE: 12225  FUNCTION: verify_slab_overload_page()
  *
  *     Resolves: https://github.com/crash-utility/crash/issues/115
  *     Signed-off-by: xiaer1921 <xiaer1921@gmail.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 8d49ad66625081dfdaf82374b5201c3a0da30e70
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon Mar 28 18:54:29 2022 +0800
  *
  *     Fix the failure of resolving ".rodata" on s390x
  *
  *     The commit <cd8954023bd4> broke crash-utility on s390x and got the
  *     following error:
  *
  *       crash: cannot resolve ".rodata"
  *
  *     The reason is that all symbols containing a "." may be filtered out
  *     on s390x. To prevent the current failure, do not filter out the
  *     symbol ".rodata" on s390x.
  *
  *     In addition, a simple way is to check whether the symbol ".rodata"
  *     exists before calculating the value of a symbol, just to be on the
  *     safe side.
  *
  *     Fixes: cd8954023bd4 ("kernel: fix start-up time degradation caused by
  *     strings command")
  *     Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com>
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit cd8954023bd474521a9d45e2b09a7bce4174f52f
  * Author: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
  * Date:   Wed Mar 23 08:09:49 2022 +0000
  *
  *     kernel: fix start-up time degradation caused by strings command
  *
  *     verify_namelist() uses strings command and scans full part of vmlinux
  *     file to find linux_banner string. However, vmlinux file is quite large
  *     these days, reaching over 500MB. As a result, this degradates start-up
  *     time of crash command 10 or more seconds. (Of course, this depends on
  *     machines you use for investigation, but I guess typically we cannot
  *     use such powerful machines to investigate crash dump...)
  *
  *     To resolve this issue, let's use bfd library and read linux_banner
  *     string in vmlinux file directly.
  *
  *     A simple benchmark shows the following result:
  *
  *     Without the fix:
  *
  *         # cat ./commands.txt
  *         quit
  *         # time ./crash -i ./commands.txt \
  *             /usr/lib/debug/lib/modules/5.16.15-201.fc35.x86_64/vmlinux \
  *             /var/crash/*/vmcore >/dev/null 2>&1
  *
  *         real        0m20.251s
  *         user        0m19.022s
  *         sys 0m1.054s
  *
  *     With the fix:
  *
  *         # time ./crash -i ./commands.txt \
  *             /usr/lib/debug/lib/modules/5.16.15-201.fc35.x86_64/vmlinux \
  *             /var/crash/*/vmcore >/dev/null 2>&1
  *
  *         real        0m6.528s
  *         user        0m6.143s
  *         sys 0m0.431s
  *
  *     Note that this commit keeps the original logic that uses strings
  *     command for backward compatibility for in case.
  *
  *     Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
  *
  * commit 8827424f2b05587b8aaaeb7aae0ce8bcc017999f
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Wed Mar 23 18:25:48 2022 +0000
  *
  *     arm64: fix the seek error of "pud page" for live debugging
  *
  *     Crash reported an error on kernel v5.7 when live debugging with the
  *     command "crash vmlinux /proc/kcore":
  *
  *       "crash: seek error: kernel virtual address: ffff75e9fffff000  type: "pud page""
  *
  *     The reason is that the PTOV() and arm64_vtop_4level_4k() do not work
  *     as expected due to incorrect physvirt_offset.
  *
  *     To fix the above issue, need to read out the virtual address of
  *     "physvirt_offset" from the "/proc/kallsyms", and update the
  *     ms->phys_offset which is initialized with a wrong value in kernel
  *     version [5.4, 5.10).
  *
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit 49df472da92be8056200c28f5b7ce82eeb7ab103
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Sat Mar 19 08:44:08 2022 +0000
  *
  *     arm64: fix the wrong vmemmap_end
  *
  *     The VMEMMAP_END did not exist before the kernel v5.7, but for now, the
  *     value of vmemmap_end may be set to -1(0xffffffffffffffffUL).
  *
  *     According to the arch/arm64/mm/dump.c (before kernel v5.7):
  *         ..................................................
  *           { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" }
  *         ..................................................
  *
  *     The vmemmap_end should always be:
  *     vmemmap_end = vmemmap_vaddr + vmemmap_size;
  *
  *     This patch fixes the above issue.
  *
  *     Fixes: e397e1bef22a ("arm64: update the modules/vmalloc/vmemmap ranges")
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit 01689f3ee22b7006e68afd0a45437846a45f79b1
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Mon Mar 14 15:13:38 2022 +0000
  *
  *     arm64: use the vmcore info to get module/vmalloc/vmemmap ranges
  *
  *     Since the kernel commit <2369f171d5c5> ("arm64: crash_core: Export
  *     MODULES, VMALLOC, and VMEMMAP ranges"), crash can obtain the range
  *     of module/vmalloc/vmemmap from the vmcore info, and no need to
  *     calculate them manually.
  *
  *     This patch adds a new hook arm64_get_range_v5_18 which could parse
  *     out all the module/vmalloc/vmemmap ranges from the vmcore info.
  *
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit e397e1bef22afb2ed6108cf9405cefa40975f6ef
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Fri Mar 11 13:00:59 2022 +0000
  *
  *     arm64: update the modules/vmalloc/vmemmap ranges
  *
  *     Currently, the crash is implemented for arm64 based on kernel v4.20(and
  *     earlier), and so far the kernel has evolved to v5.17-rc4. But the ranges
  *     of MODULE/VMALLOC/VMEMMAP have not been updated since kernel v4.20.
  *
  *     Without the patch:
  *       crash> help -m
  *       ...
  *           vmalloc_start_addr: ffff800048000000
  *                  vmalloc_end: fffffdffbffeffff
  *                modules_vaddr: ffff800040000000
  *                  modules_end: ffff800047ffffff
  *                vmemmap_vaddr: fffffdffffe00000
  *                  vmemmap_end: ffffffffffffffff
  *       ...
  *
  *     With the patch:
  *       crash> help -m
  *       ...
  *           vmalloc_start_addr: ffff800010000000
  *                  vmalloc_end: fffffdffbffeffff
  *                modules_vaddr: ffff800008000000
  *                  modules_end: ffff80000fffffff
  *                vmemmap_vaddr: fffffdffffe00000
  *                  vmemmap_end: ffffffffffffffff
  *       ...
  *
  *     Link: https://listman.redhat.com/archives/crash-utility/2022-March/009625.html
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit 4cf262e2374bcc181dc696180e33c61962f29f24
  * Author: Sergey Samoylenko <s.samoylenko@yadro.com>
  * Date:   Tue Mar 8 23:27:10 2022 +0300
  *
  *     sbitmap.c: use readmem more carefully
  *
  *     Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
  *
  * commit 7c7a4eddb4d7570dd70467b43ef3eef469ab048f
  * Author: Sergey Samoylenko <s.samoylenko@yadro.com>
  * Date:   Tue Mar 8 23:27:09 2022 +0300
  *
  *     Fix memory leak in __sbitmap_for_each_set function
  *
  *     Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
  *
  * commit a92ff262d43d3be046db90a482d8d835278c8a8f
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Tue Mar 1 17:18:24 2022 +0900
  *
  *     help.c: Fix a missing new line in "sbitmapq" help page
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit e3bdc32aab5d8fe09b679cf394da8ba8826e207f
  * Author: Pingfan Liu <piliu@redhat.com>
  * Date:   Thu Feb 24 11:52:12 2022 +0800
  *
  *     arm64: deduce the start address of kernel code, based on kernel version
  *
  *     After kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
  *     permanent kernel mapping"), the range [_text, _stext] is reclaimed. But
  *     the current crash code still assumes kernel starting from "_text".
  *
  *     This change only affects the vmalloced area on arm64 and may result a
  *     false in arm64_IS_VMALLOC_ADDR().
  *
  *     Since vmcore has no extra information about this trival change, it can
  *     only be deduced from kernel version, which means ms->kimage_text can not
  *     be correctly initialized until kernel_init() finishes. Here on arm64, it
  *     can be done at the point machdep_init(POST_GDB). This is fine
  *     since there is no access to vmalloced area at this stage.
  *
  *     Signed-off-by: Pingfan Liu <piliu@redhat.com>
  *
  * commit 8f19ddea508632e1241120b1807ad6f41f114e0d
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Thu Feb 24 10:23:56 2022 +0000
  *
  *     Makefile: Change the behavior of target "cscope"
  *
  *     Make the "make cscope" only generate cscope index, not call the cscope.
  *
  *     Also fix a typo:
  *             cscope_out --> cscope.out
  *
  *     Acked-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit c1f45f89dcc2f0e5d0d2128f646807125794f833
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Wed Feb 23 16:00:12 2022 +0800
  *
  *     Fix sys command to display its help information correctly
  *
  *     Sometimes, the sys command may be misused, but it doesn't display
  *     the expected help information, for example:
  *
  *     Without the patch:
  *       crash> sys kmem
  *       NAME
  *         kmem - kernel memory
  *       SYNOPSIS
  *         kmem [-f|-F|-c|-C|-i|-v|-V|-n|-z|-o|-h] [-p | -m member[,member]]
  *              [[-s|-S|-S=cpu[s]|-r] [slab] [-I slab[,slab]]] [-g [flags]] [[-P] address]]
  *       ...
  *       crash> sys abc
  *       crash>
  *
  *     With the patch:
  *       crash> sys kmem
  *       Usage:
  *         sys [-c [name|number]] [-t] [-i] config
  *       Enter "help sys" for details.
  *       crash> sys abc
  *       Usage:
  *         sys [-c [name|number]] [-t] [-i] config
  *       Enter "help sys" for details.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 0260367da785667818d84d6cbf3aefe86a518dbb
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Tue Feb 22 10:32:15 2022 +0800
  *
  *     Makefile: crash multi-target and multithread compile support
  *
  *     This patch will support making crash as follows:
  *     $ make -j8 warn lzo
  *
  *     Without this patch, the "make -j jobs warn lzo" will output the
  *     following error during crash build:
  *     ...
  *     mv: cannot stat 'Makefile.new': No such file or directory
  *     Makefile: cannot create new Makefile
  *     please copy Makefile.new to Makefile
  *     make: *** [Makefile:321: lzo] Error 1
  *     make: *** Waiting for unfinished jobs....
  *     TARGET: X86_64
  *      CRASH: 8.0.0++
  *        GDB: 10.2
  *     ...
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit b1fb3cdd87fc23f23d6811fdeb9915523e530b33
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Wed Feb 16 17:51:53 2022 +0800
  *
  *     x86_64_init: Refresh vmalloc region addresses in POST_RELOC instead of POST_GDB phase
  *
  *     Previously for x86_64, when memory is randomized, the region addresses
  *     such as vmalloc_start_addr/vmemmap_vaddr/modules_vaddr are firstly set
  *     to a default value before POST_RELOC phase, then get refreshed with the
  *     actual value in POST_GDB phase.
  *
  *     However for crash mininal mode, POST_GDB phase is not called, which
  *     leaving the region addresses unrefreshed and incorrect. As a consequence,
  *     the x86_64_IS_VMALLOC_ADDR check will give a faulty result when
  *     value_search tries to search a symbol by address.
  *
  *     For example, in crash minimal mode we can observe the following issue:
  *
  *         crash> dis -f panic
  *         dis: cannot resolve address: ffffffffb20e0d30
  *
  *         crash> sym panic
  *         ffffffffb20e0d30 (T) panic /usr/src/debug/kernel-4.18.0-290/linux-4.18.0-290/kernel/panic.c: 168
  *         crash> sym ffffffffb20e0d30
  *         symbol not found: ffffffffb20e0d30
  *
  *     In this patch, we will move the code which update the region addresses into
  *     POST_RELOC phase, so in mininal mode the regions can get the correct
  *     addresses.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit fb64fdd11d15d2049a3facaddaaf32ff3b29e41c
  * Author: Sergey Samoylenko <s.samoylenko@yadro.com>
  * Date:   Mon Feb 14 12:18:49 2022 +0300
  *
  *     sbitmapq: add '-p' option
  *
  *     The -p option says, an associated with sbitmap_queue array contains
  *     the pointers on a structure. This allows the sbitmapq command works
  *     correctly with the array of pointers attached to the sbitmap_queue.
  *
  *     Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
  *
  * commit ac86cc3558f8128dc0a32aad9d26db66cfc949b8
  * Author: Sergey Samoylenko <s.samoylenko@yadro.com>
  * Date:   Mon Feb 14 12:18:48 2022 +0300
  *
  *     Introduce sbitmapq command
  *
  *     Patch adds new 'sbitmapq' command. This command dumps
  *     the contents of the sbitmap_queue structure and the used
  *     bits in the bitmap. Also, it shows the dump of a structure
  *     array associated with the sbitmap_queue.
  *
  *     Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
  *
  * commit 6ecb8a23ca294de5ef92726c782f4c92fcb39d92
  * Author: Huang Shijie <shijie@os.amperecomputing.com>
  * Date:   Fri Feb 11 09:46:42 2022 +0000
  *
  *     arm64: Use CONFIG_ARM64_VA_BITS to initialize VA_BITS_ACTUAL
  *
  *     We can get VA_BITS_ACTUAL from CONFIG_ARM64_VA_BITS by guess.
  *
  *     Without this patch, we may need to use "--machdep vabits_actual=48" to
  *     set the VA_BITS_ACTUAL.
  *
  *     Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
  *
  * commit 3ed30b51284b6ef6b116262d19a3dca205563061
  * Author: Shogo Matsumoto <shogo.matsumoto@fujitsu.com>
  * Date:   Fri Jan 28 04:22:07 2022 +0000
  *
  *     log: support "log -t|-m" option for output of printk safe buffers
  *
  *     Suppress the output of safe buffer name with the "log -t" option and
  *     display the message log level with "log -m" option.
  *
  *     Signed-off-by: Shogo Matsumoto <shogo.matsumoto@fujitsu.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit b0d447d78b5a24d248359f6285e275ef776f0a34
  * Author: Shogo Matsumoto <shogo.matsumoto@fujitsu.com>
  * Date:   Fri Jan 28 04:17:41 2022 +0000
  *
  *     log: introduce "log -s" option to display printk safe buffers
  *
  *     Introduce a new "log -s" option, which outputs unflushed logs in the
  *     printk safe buffers (safe_print_seq and nmi_print_seq) as follows:
  *
  *       crash> log -s
  *       PRINTK_SAFE_SEQ_BUF: nmi_print_seq
  *       CPU: 0  ADDR: ffff8ca4fbc19ce0 LEN: 150  MESSAGE_LOST: 0
  *         Uhhuh. NMI received for unknown reason 20 on CPU 0.
  *         Do you have a strange power saving mode enabled?
  *         Dazed and confused, but trying to continue
  *       ...
  *
  *     The buffers are displayed for each CPU.  For an empty buffer,
  *     '(empty)' will be printed.
  *
  *     Also append those to the bottom of "log" command output so as not to
  *     overlook them like this:
  *
  *       crash> log
  *       ...
  *       [nmi_print_seq] Uhhuh. NMI received for unknown reason 30 on CPU 0.",
  *       [nmi_print_seq] Do you have a strange power saving mode enabled?",
  *       [nmi_print_seq] Dazed and confused, but trying to continue",
  *
  *     Note that the safe buffer (struct printk_safe_seq_buf) was introduced
  *     at kernel-4.11 (Merge commit 7d91de74436a69c2b78a7a72f1e7f97f8b4396fa)
  *     and removed at kernel-5.15 (93d102f094be9beab28e5afb656c188b16a3793b).
  *
  *     Link: https://listman.redhat.com/archives/crash-utility/2022-January/msg00052.html
  *     Signed-off-by: Shogo Matsumoto <shogo.matsumoto@fujitsu.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit def34f57e81a2efa865de5eb218818ebff142614
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Feb 16 11:33:15 2022 +0900
  *
  *     Makefile: Fix build failure with "make -j jobs" option
  *
  *     The "make -j jobs" option sometimes fails with an error like this:
  *
  *       $ make clean ; make -j $(nproc) warn
  *       ...
  *       ar: creating crashlib.a
  *         CXXLD  gdb
  *       /usr/bin/ld: ../../crashlib.a(main.o): in function `dump_build_data':
  *       /home/crash/main.c:1829: undefined reference to `build_command'
  *       /usr/bin/ld: /home/crash/main.c:1830: undefined reference to `build_data'
  *       collect2: error: ld returned 1 exit status
  *       make[4]: *** [Makefile:1872: gdb] Error 1
  *       make[3]: *** [Makefile:10072: all-gdb] Error 2
  *       make[2]: *** [Makefile:860: all] Error 2
  *       crash build failed
  *
  *     This is because build_data.c is compiled by two jobs and they write to
  *     build_data.o simultaneously and break it. Remove one of them.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 74ac929712416705a758f14a3506991bbfdc869c
  * Author: Sven Schnelle <svens@linux.ibm.com>
  * Date:   Mon Dec 20 14:16:50 2021 +0100
  *
  *     Support for multiple jobs to build crash
  *
  *     This patch saves compilation time for crash build, which did the
  *     following things:
  *
  *     [1] add --no-print-directory to MAKEFLAGS right in the beginning
  *         to avoid repeating it in all make calls.
  *     [2] use "make -C" instead of "cd x; make"
  *     [3] replace make by $(MAKE)
  *
  *     Link: https://listman.redhat.com/archives/crash-utility/2021-December/msg00049.html
  *     Link: https://listman.redhat.com/archives/crash-utility/2021-December/msg00048.html
  *     Link: https://listman.redhat.com/archives/crash-utility/2021-December/msg00047.html
  *     Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 0a4434f4cb0760d77900af9603e847da4e7afd0f
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon Feb 14 17:07:38 2022 +0800
  *
  *     Doc: update man page for the option "--src directory"
  *
  *     The "--src directory" option information is missing from the man page of
  *     crash utility.  Originally it was added by commit 9254c7f206d5 ("Added a
  *     new "--src <directory>"...), let's sync this option information to the
  *     man page.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 1ecb3513093ef4e40fdd27da479bc8ef844df3eb
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon Feb 14 16:59:10 2022 +0800
  *
  *     Fix for "bpf -m|-M" options to appropriately display MEMLOCK and UID
  *
  *     Kernel commit 80ee81e0403c ("bpf: Eliminate rlimit-based memory
  *     accounting infra for bpf maps") removed the struct bpf_map_memory
  *     member from struct bpf_map at Linux 5.11.  Without the patch, the
  *     "bpf -m|-M" options will print "(unknown)" for MEMLOCK and UID:
  *
  *     crash> bpf -m 1
  *      ID      BPF_MAP          BPF_MAP_TYPE     MAP_FLAGS
  *      1   ffff96ba41804400        ARRAY          00000000
  *          KEY_SIZE: 4  VALUE_SIZE: 8  MAX_ENTRIES: 64  MEMLOCK: (unknown)
  *          NAME: "dist"  UID: (unknown)
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 5f390ed811b00753ce7d5ceec5717280df16fd28
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Feb 2 02:14:56 2022 +0000
  *
  *     Fix for "kmem -s|-S" and "bt -F[F]" on Linux 5.17-rc1
  *
  *     Since the following kernel commits split slab info from struct page
  *     into struct slab, crash cannot get several slab related offsets from
  *     struct page.
  *
  *       d122019bf061 ("mm: Split slab into its own type")
  *       07f910f9b729 ("mm: Remove slab from struct page")
  *
  *     Without the patch, "kmem -s|-S" and "bt -F[F]" options cannot work
  *     correctly with the following errors:
  *
  *       crash> kmem -s kmem_cache
  *       CACHE             OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE  NAME
  *       kmem: page_to_nid: invalid page: ffff9454afc35020
  *       kmem: kmem_cache: cannot gather relevant slab data
  *       ffff945140042000      216          ?         ?      ?     8k  kmem_cache
  *
  *       crash> bt -F
  *       ...
  *       bt: invalid structure member offset: page_slab
  *           FILE: memory.c  LINE: 9477  FUNCTION: vaddr_to_kmem_cache()
  *
  *     Signed-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit dd35cf6fc5463ff31206fbb27238b4c3802c063d
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Jan 26 06:07:00 2022 +0000
  *
  *     arm64: Fix segfault by "bt" command with offline cpus
  *
  *     Currently on arm64, NT_PRSTATUS notes in dumpfile are not mapped to
  *     online cpus and machine_specific->panic_task_regs correctly.  As a
  *     result, the "bt" command can cause a segmentation fault.
  *
  *       crash> bt -c 0
  *       PID: 0      TASK: ffff8000117fa240  CPU: 0   COMMAND: "swapper/0"
  *       Segmentation fault (core dumped)
  *
  *     To fix this,
  *     1) make map_cpus_to_prstatus_kdump_cmprs() map the notes to
  *        dd->nt_prstatus_percpu also on arm64, and
  *     2) move arm64_get_crash_notes() to machdep_init(POST_INIT) in order
  *        to apply the mapping to machine_specific->panic_task_regs.
  *
  *     Resolves: https://github.com/crash-utility/crash/issues/105
  *     Reported-by: xuchunmei000 <xuchunmei@linux.alibaba.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *     Tested-by: David Wysochanski <dwysocha@redhat.com>
  *
  * commit e389667cf62ef5db82f9796cdbc0134ec38612dc
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Fri Jan 21 13:43:09 2022 +0800
  *
  *     Improve the ps performance for vmcores with large number of threads
  *
  *     Previously, the ps command will iterate over all threads which
  *     have the same tgid, to accumulate their rss value, in order to
  *     get a thread/process's final rss value as part of the final output.
  *
  *     For non-live systems, the rss accumulation values are identical for
  *     threads which have the same tgid, so there is no need to do the
  *     iteration and accumulation repeatly, thus a lot of readmem calls are
  *     skipped. Otherwise it will be the performance bottleneck if the
  *     vmcores have a large number of threads.
  *
  *     In this patch, the rss accumulation value will be stored in a cache,
  *     next time a thread with the same tgid will take it directly without
  *     the iteration.
  *
  *     For example, we can monitor the performance issue when a vmcore has
  *     ~65k processes, most of which are threads for several specific
  *     processes. Without the patch, it will take ~7h for ps command
  *     to finish. With the patch, ps command will finish in 1min.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit ce92e458506aec5bc5516a771e26b0f907ce0db4
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Wed Jan 26 20:32:35 2022 +0800
  *
  *     GDB: fix completion related libstdc++ assert
  *
  *     Currently crash built with some specific flags (-D_GLIBCXX_ASSERTIONS
  *     and etc.) may abort and print the following error when running the gdb
  *     list command or tab-completion of symbols.  For example:
  *
  *       crash> l panic
  *       /usr/include/c++/11/string_view:234: ...
  *       Aborted (core dumped)
  *
  *       crash> p "TAB completion"
  *       crash> p /usr/include/c++/11/string_view:234: ...
  *       Aborted (core dumped)
  *
  *     When the name string is null (the length of name is zero), there are
  *     multiple places where array access is out of bounds in the gdb/ada-lang.c
  *     (see ada_fold_name() and ada_lookup_name_info()).
  *
  *     The patch backports these gdb patches:
  *     6a780b676637 ("Fix completion related libstdc++ assert when using -D_GLIBCXX_DEBUG")
  *     2ccee230f830 ("Fix off-by-one error in ada_fold_name")
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 2ebd8c5ecf1f077975b82325a38dd777b594d0a9
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Jan 19 16:24:49 2022 +0900
  *
  *     Remove ptype command from "ps -t" option to reduce memory and time
  *
  *     With some vmlinux e.g. RHEL9 ones, the first execution of the gdb ptype
  *     command heavily consumes memory and time.  The "ps -t" option uses it in
  *     start_time_timespec(), and it can be replaced with the crash macros.
  *
  *     This can reduce about 1.4 GB memory and 6 seconds time comsumption in
  *     the following test:
  *
  *       $ echo "ps -t" | time crash vmlinux vmcore
  *
  *       Without the patch:
  *       11.60user 0.43system 0:11.94elapsed 100%CPU (0avgtext+0avgdata 1837964maxresident)k
  *       0inputs+400outputs (0major+413636minor)pagefaults 0swaps
  *
  *       With the patch:
  *       5.40user 0.16system 0:05.46elapsed 101%CPU (0avgtext+0avgdata 417896maxresident)k
  *       0inputs+384outputs (0major+41528minor)pagefaults 0swaps
  *
  *     Although the ptype command and similar ones cannot be fully removed,
  *     but removing some of them will make the use of crash safer, especially
  *     for an automatic crash reporter.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit d16dc6fff0260ec26002046fae4aeb546d6b9a0e
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon Jan 17 15:14:00 2022 +0800
  *
  *     Move the initialization of "boot_date" to task_init()
  *
  *     The "boot_date" is initialized conditionally in the cmd_log(), which may
  *     display incorrect "boot_date" value with the following command before
  *     running the "log -T" command:
  *
  *     crash> help -k | grep date
  *               date: Wed Dec 22 13:39:29 IST 2021
  *          boot_date: Thu Jan  1 05:30:00 IST 1970
  *                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  *     The calculation of "boot_date" depends on the HZ value, and the HZ will
  *     be calculated in task_init() at the latest, so let's move it here.
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 14f8c460473c8613553b5defd174ca2af812ddcb
  * Author: Alexander Egorenkov <egorenar@linux.ibm.com>
  * Date:   Mon Dec 6 16:04:19 2021 +0100
  *
  *     memory: Handle struct slab changes on Linux 5.17-rc1 and later
  *
  *     Since kernel commit d122019bf061 ("mm: Split slab into its own type"),
  *     the struct slab is used for both SLAB and SLUB. Therefore, don't depend
  *     on the non-presence of the struct slab to decide whether SLAB implementation
  *     should be chosen and use the member variable "cpu_slab" of the struct
  *     kmem_cache instead, it should be present only in SLUB.
  *
  *     Without the patch, crash fails to start with the error message:
  *
  *       crash: invalid structure member offset: kmem_cache_s_num
  *                  FILE: memory.c  LINE: 9619  FUNCTION: kmem_cache_init()
  *
  *     Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
  *
  * commit b9dc76e232e0226a14ae3089e3be5c915f2bb981
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Mon Jan 10 17:25:06 2022 +0800
  *
  *     Fix for HZ calculation on Linux 5.14 and later
  *
  *     Kernel commit 3e9a99eba058 ("block/mq-deadline: Rename dd_init_queue()
  *     and dd_exit_queue()") renamed dd_init_queue to dd_init_sched. Without
  *     the patch, the 'help -m' may print incorrect hz value as follows:
  *
  *     crash> help -m | grep hz
  *            hz: 1000    <---The correct hz value on ppc64le machine is 100.
  *                ^^^^
  *
  *     Fixes: b93027ce5c75 ("Add alternate HZ calculation using write_expire")
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 0d3d80b47d69c5d303b48c0463a026e60633cae2
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Thu Jan 6 12:01:17 2022 +0800
  *
  *     Fix for "bt -v" option to display the stack-end address correctly
  *
  *     The "bt -v" command prints incorrect stack-end address when the
  *     "CONFIG_THREAD_INFO_IN_TASK=y" is enabled in kernel, the "bt -v"
  *     command output shows that the value stored at 0xffff8dee0312c198
  *     is 0xffffffffc076400a, however, the value stored actually at
  *     0xffff8dee0312c198 is NULL(0x0000000000000000), the stack-end
  *     address is incorrect.
  *
  *     Without the patch:
  *     crash> bt -v
  *     PID: 28642  TASK: ffff8dee0312c180  CPU: 0   COMMAND: "insmod"
  *       possible stack overflow: ffff8dee0312c198: ffffffffc076400a != STACK_END_MAGIC
  *                                                  ^^^^^^^^^^^^^^^^
  *
  *     crash> rd 0xffff8dee0312c198
  *     ffff8dee0312c198:  0000000000000000                    ........
  *                        ^^^^^^^^^^^^^^^^
  *
  *     With the patch:
  *     crash> bt -v
  *     PID: 28642  TASK: ffff8dee0312c180  CPU: 0   COMMAND: "insmod"
  *       possible stack overflow: ffff991340bc0000: ffffffffc076400a != STACK_END_MAGIC
  *
  *     crash> rd 0xffff991340bc0000
  *     ffff991340bc0000:  ffffffffc076400a                    .@v.....
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 70a27ae9f2b45d6dba56ee4240b6adf79c544ee1
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Thu Jan 6 22:34:26 2022 +0800
  *
  *     Fix for "timer -r" option to display all the per-CPU clocks
  *
  *     Currently, the hrtimer_max_clock_bases is hard-coded to 3, which
  *     makes that crash only prints three clocks, and the rest of clocks
  *     are not displayed.
  *
  *     Without the patch:
  *     crash> timer -r -C 11
  *     CPU: 11  HRTIMER_CPU_BASE: ffff9a775f95ee00
  *       CLOCK: 0  HRTIMER_CLOCK_BASE: ffff9a775f95ee80  [ktime_get]
  *       (empty)
  *
  *       CLOCK: 1  HRTIMER_CLOCK_BASE: ffff9a775f95ef00  [ktime_get_real]
  *       (empty)
  *
  *       CLOCK: 2  HRTIMER_CLOCK_BASE: ffff9a775f95ef80  [ktime_get_boottime]
  *       (empty)
  *
  *     With the patch:
  *     crash> timer -r -C 11
  *     CPU: 11  HRTIMER_CPU_BASE: ffff9a775f95ee00
  *       CLOCK: 0  HRTIMER_CLOCK_BASE: ffff9a775f95ee80  [ktime_get]
  *       (empty)
  *
  *       CLOCK: 1  HRTIMER_CLOCK_BASE: ffff9a775f95ef00  [ktime_get_real]
  *       (empty)
  *
  *       CLOCK: 2  HRTIMER_CLOCK_BASE: ffff9a775f95ef80  [ktime_get_boottime]
  *       (empty)
  *     ...
  *       CLOCK: 7  HRTIMER_CLOCK_BASE: ffff9a775f95f200  [ktime_get_clocktai]
  *       (empty)
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 98b417fc63467339b919ef6d322c1893d6d55f86
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Fri Dec 24 18:56:35 2021 +0800
  *
  *     Handle blk_mq_ctx member changes for kernels 5.16-rc1 and later
  *
  *     Kernel commit 9a14d6ce4135 ("block: remove debugfs blk_mq_ctx
  *     dispatched/merged/completed attributes") removed the member
  *     rq_dispatched and rq_completed from struct blk_mq_ctx.  Without
  *     the patch, "dev -d|-D" options will fail with the following error:
  *
  *     crash> dev -d
  *     MAJOR GENDISK            NAME       REQUEST_QUEUE      TOTAL ASYNC  SYNC
  *
  *     dev: invalid structure member offset: blk_mq_ctx_rq_dispatched
  *          FILE: dev.c  LINE: 4229  FUNCTION: get_one_mctx_diskio()
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 7eba220e1a7d443cad6716dd83d4953ffd62d566
  * Author: Qi Zheng <zhengqi.arch@bytedance.com>
  * Date:   Tue Dec 21 15:40:31 2021 +0800
  *
  *     Fix pvops Xen detection for arm machine
  *
  *     Since the xen_start_info on the arm/arm64 platform points to a static
  *     variable '_xen_start_info'(see its definition as below), which makes
  *     that the address of xen_start_info will never be null.
  *
  *     arch/arm/xen/enlighten.c:40:static struct start_info _xen_start_info;
  *     arch/arm/xen/enlighten.c:41:struct start_info *xen_start_info = &_xen_start_info;
  *     arch/arm/xen/enlighten.c:42:EXPORT_SYMBOL(xen_start_info);
  *
  *     As a result, the is_pvops_xen() in commit 4badc6229c69 ("Fix pvops
  *     Xen detection for kernels >= v4.20") always returns TRUE because it
  *     can always read out the non-null address of xen_start_info, finally
  *     the following error will be reported on arm/arm64 platform(non-Xen
  *     environment) because p2m_mid_missing and xen_p2m_addr are not defined:
  *
  *             crash: cannot resolve "p2m_top"
  *
  *     For the arm/arm64 platform, fix it by using xen_vcpu_info instead of
  *     xen_start_info to detect Xen dumps.
  *
  *     In addition, also explicitly narrow the scope of the xen_start_info
  *     check to x86 with the machine_type(), there is no need to check it on
  *     other architectures.
  *
  *     Fixes: 4badc6229c69 ("Fix pvops Xen detection for kernels >= v4.20")
  *     Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
  *     Acked-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 6968345893178d2750b8872055498d2a6010a861
  * Author: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
  * Date:   Wed Dec 8 12:07:34 2021 +0000
  *
  *     defs.h: fix breakage of compatibility of struct symbol_table_data for extension modules
  *
  *     Commit <2fab8fbc0c4f> ("symbols: Implement install and remove operations
  *     for mod_symname_hash") added new member variable mod_symname_hash in the
  *     middle of struct symbol_table_date, which breaks compatibility of struct
  *     symbol_table_data for extension modules. As the result, crash trace command
  *     results in segmentation fault.
  *
  *     Fixes: 2fab8fbc0c4f ("symbols: Implement install and remove operations for mod_symname_hash")
  *     Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
  *
  * commit c477b04aee34d4f4784c326ed715e91b2c43eb3e
  * Author: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
  * Date:   Thu Dec 9 01:05:07 2021 +0000
  *
  *     defs.h: fix breakage of compatibility of struct machdep_table for extension modules
  *
  *     Commit <2f967fb5ebd7> ("crash_taget: fetch_registers support") added new
  *     member get_cpu_reg in the middle of struct machdep_table, which breaks
  *     compatibility of struct machdep_table for extension modules. As the result,
  *     crash gcore command results in unexpected behavior, furthermore may cause
  *     segmentation fault.
  *
  *     Fixes: 2f967fb5ebd7 ("crash_taget: fetch_registers support")
  *     Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
  *
  * commit 995db8ab88916b6397676b67be98c0a4f82cca49
  * Author: Hong YANG <hong.yang3@nio.com>
  * Date:   Mon Nov 15 15:41:01 2021 +0800
  *
  *     arm64: Support overflow stack panic
  *
  *     Kernel commit <872d8327ce89> ("arm64: add VMAP_STACK overflow detection")
  *     has supported the overflow stack exception handling. Without the patch, the
  *     "bt" command will make crash generate a core dump because of segmentation
  *     fault. With the patch, the "bt" command can display the overflow stack.
  *
  *     Before:
  *     crash> bt
  *     PID: 3607   TASK: ffffffcbf9a4da00  CPU: 2   COMMAND: "sh"
  *     Segmentation fault (core dumped)
  *
  *     After:
  *     crash> bt
  *     PID: 3607   TASK: ffffffcbf9a4da00  CPU: 2   COMMAND: "sh"
  *      #0 [ffffffccbfd85f50] __delay at ffffff8008ceded8
  *     ...
  *      #5 [ffffffccbfd85fd0] emergency_restart at ffffff80080d49fc
  *      #6 [ffffffccbfd86140] panic at ffffff80080af4c0
  *      #7 [ffffffccbfd86150] nmi_panic at ffffff80080af150
  *      #8 [ffffffccbfd86190] handle_bad_stack at ffffff800808b0b8
  *      #9 [ffffffccbfd862d0] __bad_stack at ffffff800808285c
  *          PC: ffffff8008082e80  [el1_sync]
  *          LR: ffffff8000d6c214  [stack_overflow_demo+84]
  *          SP: ffffff1a79930070  PSTATE: 204003c5
  *         X29: ffffff8011b03d00  X28: ffffffcbf9a4da00  X27: ffffff8008e02000
  *         X26: 0000000000000040  X25: 0000000000000124  X24: ffffffcbf9a4da00
  *         X23: 0000007daec2e288  X22: ffffffcbfe03b800  X21: 0000007daec2e288
  *         X20: 0000000000000002  X19: 0000000000000002  X18: 0000000000000002
  *         X17: 00000000000003e7  X16: 0000000000000000  X15: 0000000000000000
  *         X14: ffffffcc17facb00  X13: ffffffccb4c25c00  X12: 0000000000000000
  *         X11: ffffffcc17fad660  X10: 0000000000000af0   X9: 0000000000000000
  *          X8: ffffff1a799334f0   X7: 0000000000000000   X6: 000000000000003f
  *          X5: 0000000000000040   X4: 0000000000000010   X3: 00000065981d07f0
  *          X2: 00000065981d07f0   X1: 0000000000000000   X0: ffffff1a799334f0
  *
  *     Signed-off-by: Hong YANG <hong.yang3@nio.com>
  *
  * commit d9b11ddd19e98424b54bef4260b9d780f869b504
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Wed Dec 1 17:36:20 2021 +0800
  *
  *     Mark start of 8.0.1 development phase with version 8.0.0++
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>

 -- Troy Heber <troyh@debian.org>  Thu, 17 Nov 2022 10:27:25 -0700

crash (8.0.0-1ubuntu1) jammy; urgency=medium

  * Merge with Debian; remaining changes:
    - Build without lto. Fails to build gdb on ppc64el. That should be fixed,
      once gdb is updated to a more recent version (e.g. 10.x).
    - Add linux-libc-dev dependency for the autopkg test. This package
      gets usually broken with kernel upgrades, so let it already show
      in the autopkg test.
  * Run autopkg test with allow-stderr.

 -- Matthias Klose <doko@ubuntu.com>  Wed, 23 Mar 2022 15:07:01 +0100

crash (8.0.0-1) unstable; urgency=medium
  * New upstream (Closes: #950544)
  * Add lintian override for zlib in embedded gdb
  *
  * commit ec568e2ea515b66343d3488d5d4b9a625d55b7ae
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed Nov 24 13:32:49 2021 +0900
  *
  *     crash-7.3.0 -> crash-8.0.0
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 6bc104059b124ecac5c8244f84aae6d7cfdfe97c
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Tue Nov 16 02:42:23 2021 +0000
  *
  *     log: add warning to help text to inform the inaccuracy of -T option
  *
  *     The timestamps of the "log -T" option are inaccurate because they are
  *     from local_clock(), which returns the raw counter in the local CPU and
  *     it's different from the elapsed wall time.
  *
  *     The dmesg command, which the "log -T" option imitates, has a similar
  *     behavior in nature and a warning in its help text.  Let's add a warning
  *     also to the crash's help text to inform the inaccuracy for now.
  *
  *     Reported-by: Martin Moore <martin.moore@hpe.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit b0dd73d2368275e101688b2aca0bc297fd1ba300
  * Author: Aaron Tomlin <atomlin@redhat.com>
  * Date:   Mon Nov 1 11:39:34 2021 +0000
  *
  *     kernel: show that the kernel is tainted at init-time
  *
  *     Explicitly indicate to the user that the Linux kernel is tainted
  *     at init-time or when the 'sys' command is used.
  *
  *     Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
  *
  * commit 64f48ee6719632895cd8a0922e84a4626e3790d8
  * Author: Aaron Tomlin <atomlin@redhat.com>
  * Date:   Mon Nov 1 11:39:33 2021 +0000
  *
  *     kernel: Introduce is_kernel_tainted()
  *
  *     Provide a quick way to test if the given Linux kernel is "tainted".
  *     Support for Linux-2.6.12 and above, to date.
  *
  *     Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
  *
  * commit bfa596f40650e5a061b15d41b0a5b108610b11e9
  * Author: Aaron Tomlin <atomlin@redhat.com>
  * Date:   Mon Nov 1 11:39:32 2021 +0000
  *
  *     kernel: consolidate show_kernel_taints()
  *
  *     No functional change.
  *
  *     Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
  *
  * commit 8246dce99dd23457e8c7a3fe9609c706694d1959
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Thu Nov 11 15:20:52 2021 +0900
  *
  *     arm64: Update SECTION_SIZE_BITS for kernels >= 5.12
  *
  *     Update the default SECTION_SIZE_BITS value for arm64 Linux 5.12
  *     and later kernels that contain kernel commit f0b13ee23241
  *     ("arm64/sparsemem: reduce SECTION_SIZE_BITS").
  *
  *     Reported-by: Ankur Bansal <er.ankurbansal@gmail.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 01d20ca1861ffaf449c1c60aa0536e9f42200ad3
  * Author: Philipp Rudo <prudo@redhat.com>
  * Date:   Tue Nov 9 14:52:22 2021 +0100
  *
  *     Fix live debugging with lockdown=integrity
  *
  *     With kernel lockdown the access to kernel interfaces that allow one to
  *     extract confidential information (lockdown=confidentiality) or modify a
  *     running kernel (lockdown=integrity) can be restricted. Two of the
  *     interfaces that can be restricted are /dev/mem (integrity &
  *     confidentiality) and /proc/kcore (confidentiality). With
  *     lockdown=integrity this leads to a situation where /dev/mem exists but
  *     is not readable while /proc/kcore exists and is readable. This breaks
  *     crash's live debugging when it is invoked without argument, i.e.
  *
  *     $ crash
  *     [...]
  *     crash: /dev/mem: Operation not permitted
  *
  *     while passing /proc/kcore as image succeeds. The reason for this is
  *     that crash always picks /dev/mem as source when it exits but doesn't
  *     check if it is readable. Fix this by only selecting /dev/mem when it
  *     is readable.
  *
  *     Signed-off-by: Philipp Rudo <prudo@redhat.com>
  *
  * commit 68870c83d299603c07785e3530e33c13045c87ef
  * Author: Alexander Egorenkov <egorenar@linux.ibm.com>
  * Date:   Wed Oct 13 10:56:39 2021 +0200
  *
  *   Handle task_struct cpu member changes for kernels >= 5.16-rc1
  *
  *   Kernel commit bcf9033e5449bdcaa9bed46467a7141a8049dadb
  *   ("sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y")
  *   moved the member cpu of task_struct back into thread_info.
  *   Without the patch, crash fails with the following error message
  *   during session initialization:
  *
  *     crash: invalid structure member offset: task_struct_cpu
  *            FILE: task.c  LINE: 2904  FUNCTION: add_context()
  *
  *   Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
  *    Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit c180a63f2cb370da6097ad97eb07333c07aa988b
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Mon Oct 25 16:53:26 2021 +0900
  *
  *     arm64: Use VA_BITS for page_offset calculation
  *
  *     Commit 167d37e347fe ("arm64: assign page_offset with VA_BITS kernel
  *     configuration value") changed the page_offset calculation from
  *     using VA_BITS_ACTUAL to CONFIG_ARM64_VA_BITS.  This caused an error
  *     for ramdumps without vmcoreinfo like this:
  *
  *       crash: vmlinux and /var/tmp/ramdump_elf_XUtCMT do not match!
  *
  *     Set the vmcoreinfo value to VA_BITS if available, and use VA_BITS
  *     for page_offset calculation instead.
  *
  *     Also remove ARM64_FLIP_PAGE_OFFSET_ACTUAL because it's not used
  *     actually.
  *
  *     Reported-by: Ankur Bansal <er.ankurbansal@gmail.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 5c04a6f3f923af7c50f0d853477044802b3fa6ec
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:17 2021 +0800
  *
  *     symbols: Add mod_symname_hash table dump to help -s
  *
  *     Previously, help -s only print out the dump status of symname_hash
  *     table. Since we have mod_symname_hash table introduced, let's print
  *     out mod_symname_hash in help -s as well.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit df0049d12b2ced1b6ff7350ee3c0ca28c3f7cd52
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:16 2021 +0800
  *
  *     symbols: Refactor SYMNAME_HASH_INDEX macro to be a function
  *
  *     SYMNAME_HASH_INDEX is used as the index of symname hash table. It will
  *     be out of range if SYMNAME_HASH_INDEX is negative. This patch avoids
  *     the risk by changing the marco into a function, and casting and
  *     calculating the numbers as unsigned.
  *
  *     Suggested-by: Lianbo Jiang <lijiang@redhat.com>
  *     Suggested-by: Philipp Rudo <prudo@redhat.com>
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 1e23335dab6bf9f6219a23bf0be4ad9f433f4f43
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:15 2021 +0800
  *
  *     symbols: Sync module symbols into mod_symtable whenever module symbols
  *     change
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *     Reviewed-by: Philipp Rudo <prudo@redhat.com>
  *
  * commit f3bee9375ed32b85e7f81a5e46a0040620553ae0
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:14 2021 +0800
  *
  *     symbols: Intergrate symbol_exists() with mod_symname_hash search
  *
  *     This patch introduces mod_symname_hash search to symbol_exists()
  *     to improve its performance. And code refactoring for
  *     kernel_symbol_exists().
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *     Reviewed-by: Philipp Rudo <prudo@redhat.com>
  *
  * commit 340c6ad1a0a7ce76eb5d9397833bfc6a049e2b3b
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:13 2021 +0800
  *
  *     symbols: Extend symname_hash_search() with hash table select
  *
  *     Previously symname_hash_search() can only search symbols from kernel's
  *     symname_hash. This patch add hash table pointer as parameter for
  *     symname_hash_search(). Thus symname_hash_search() can be used both for
  *     symname_hash and mod_symname_hash searching.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 214f9bf3727c3350401b3f4b4389258c24486e06
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:12 2021 +0800
  *
  *     symbols: Integrate symbol_search() with mod_symname_hash search
  *
  *     This patch introduces mod_symname_hash search to symbol_search(),
  *     to get a better searching performance.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *     Reviewed-by: Philipp Rudo <prudo@redhat.com>
  *
  * commit 2fab8fbc0c4f1c4cbe889de4cead5f7457a19f77
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sat Oct 16 13:21:11 2021 +0800
  *
  *     symbols: Implement install and remove operations for mod_symname_hash
  *
  *     Currently the sequence for symbol_search to search a symbol is: 1)
  *     kernel symname hash table, 2) iterate all kernel symbols, 3) iterate
  *     all kernel modules and their symbols. In the worst case, if a
  *     non-exist symbol been searched, all 3 stages will be went through. The
  *     time consuming status for each stage is like:
  *
  *         stage 1         stage 2         stage 3
  *         0.007000(ms)    0.593000(ms)    2.421000(ms)
  *
  *     stage 3 takes too much time when comparing to stage 1. This patch
  *     series introduces a symname hash table for kernel modules, to improve
  *     the performance of symbol searching.
  *
  *     Functions symbol_search() and symbol_exists() are fundamental and
  *     widely used by other crash functions, thus the benefit of performance
  *     improvement can get accumulated. For example, "ps -m" and "irq"
  *     commands, which call the functions many times, will become faster with
  *     the patch series.
  *
  *     This patch indroduces mod_symname_hash, and its install/remove
  *     operations. Since symbol_search() has to return the lowest address
  *     symbol and symbol_search_next() returns the next lowest symbol, thus
  *     the installation should be sorted ascendingly.
  *
  *     In mod_symname_hash_install_range() scenario, spn are already arranged
  *     ascendingly, so for mod_symname_hash_install():
  *
  *     Install spn previous to sp:
  *
  *       If sp is the start of bucket, or
  *       1) spn->value is smaller than sp->value.
  *
  *     Install spn next to sp:
  *
  *       1) sp->name_hash_next is NULL, or
  *       2) sp->name_hash_next->value is larger than spn->value
  *
  *     spn->value is the kernel address of the symbol and will not change.
  *     So we use it mainly to determine the sequence. When spn->value equals
  *     sp->value, they must be symbols within a kernel module.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit f7e3b2d9b753793e230a5242974a111cdf139e49
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Thu Sep 30 11:04:31 2021 +0900
  *
  *     .gitignore: add gdb-10.2 directory
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 05a3a328fcd8920e49926b6d1c9c81ce0b6acbca
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Thu Sep 9 15:23:27 2021 +0900
  *
  *     Remove text value cache code
  *
  *     The text value cache was implemented for analysis of remote dumpfiles
  *     using the deprecated "crash daemon" running on the remote host.  On
  *     updating GDB to 10.2, a regression occurred when we tried to fix a
  *     "help -x" command problem, and there was no performance degradation
  *     even without the text cache, so let's drop this functionality.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit c1e256249426dd59ceea99038451a39e98a26790
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Thu Aug 19 10:52:58 2021 +0900
  *
  *     Fix tab completion issues
  *
  *     1. The maximum number of tab completion candidates is limited to 200
  *     by default.  Set it unlimited.
  *
  *     2. The output of tab completion is not wrapped with the screen width.
  *     Get and use it when tab completion is invoked.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 5c2d8d2d9da6423eec076fd51049d7b4677b61c6
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Tue Aug 17 16:21:43 2021 +0800
  *
  *     Set gdb max-value-size to be unlimited
  *
  *     gdb-10.2 uses max-value-size as the maximum size in bytes that the
  *     contents of a object may allocate. The default value of max-value-size
  *     is 64K. However, it could be not enough for allocating an object which
  *     requires larger space, and failed at the startup of crash.
  *
  *     In gdb-7.6, there is no max-value-size check and works fine. So in
  *     this patch, let's just set max-value-size to be unlimited.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit b8e1f2735b8dd1303aeb2affa309a2a409a82d38
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Mon Jul 26 09:58:54 2021 +0800
  *
  *     Add kernel version dependent check for getting length of log_end
  *
  *     For kernels(>=2.4.9.11 [1] && <3.5 [2]), log_end was involved in the
  *     kernel sources.
  *     For kernels(>=2.6.25 [3]), log_end was defined as:
  *         static unsigned log_end;
  *     For kernels(<2.6.25), log_end was defined as:
  *         static unsigned long log_end;
  *
  *     Previously, the length of log_end is determined by get_symbol_length,
  *     but it can be a regression when the returned length is 0 for some
  *     cases and value unchecked:
  *
  *         crash> help -t
  *         ...
  *         help: invalid size request: 0  type: "log_end"
  *
  *     To solve the above issue, let's add a kernel version dependent check
  *     to get its value appropriately when the length of the 'log_end'
  *     returns a value of zero.
  *
  *  [1]: https://elixir.bootlin.com/linux/2.4.9.11/source/kernel/printk.c#L74
  *  [2]: https://elixir.bootlin.com/linux/v3.5/source/kernel/printk.c
  *  [3]: https://elixir.bootlin.com/linux/v2.6.25/source/kernel/printk.c#L104
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 51f21b0d1c91a4ae02ebf0d8c81460ec8b6c1283
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Thu Jul 15 17:34:29 2021 +0800
  *
  *     x86_64_irq_eframe_link_init: Fix wrong instruction searching range
  *     calculation
  *
  *     In function x86_64_irq_eframe_link_init, instruction "push xxx" is
  *     searched in addresses range from "common_interrupt" to the next nearby
  *     symbol, in order to calculate the value of irq_eframe_link. The
  *     searching distance is given by max_instructions, which is calculated
  *     by end ranging address minus start ranging address. Then crash asks
  *     gdb to disassemble max_instructions quantity of instructions.
  *
  *     Taking max_instructions as the quantity of disassemble instructions is
  *     inappropriate, because most x86_64 instructions have a length longer
  *     than 1, as a consequence, much more than the actual needed
  *     instructions get disassembled.
  *
  *     In gdb-7.6 crash, the extra instructions are skipped by
  *     "if (!strstr(buf, sp->name))", which breaks if one instruction doesn't
  *     belongs to a symbol:
  *
  *        0xffffffff8005d5b4 <common_interrupt+0>:     cld
  *        0xffffffff8005d5b5 <common_interrupt+1>:     sub    $0x48,%rsp
  *        ...
  *        0xffffffff8005d61e <common_interrupt+106>:   leaveq
  *        0xffffffff8005d61f <exit_intr>:      mov    %gs:0x10,%rcx
  *    <--- searching stops here
  *        ...
  *
  *     In gdb-10.2 crash, "exit_intr" doesn't show, however it really exist.
  *     As a result, searching for "push xxx" will go to a wrong place.
  *
  *        0xffffffff8005d5b4 <common_interrupt+0>:     cld
  *        0xffffffff8005d5b5 <common_interrupt+1>:     sub    $0x48,%rsp
  *        ...
  *        0xffffffff8005d61e <common_interrupt+106>:   leave
  *        0xffffffff8005d61f <common_interrupt+107>:   mov    %gs:0x10,%rcx
  *   <--- searching continues
  *        ...
  *
  *        (gdb) p exit_intr
  *        $1 = {<text variable, no debug info>} 0xffffffff8005d61f
  *             <common_interrupt+107>
  *        (gdb) info symbol exit_intr
  *        common_interrupt + 107 in section .text
  *
  *     The previous way to determine start and end searching range is not
  *     stable, otherwise we may encounter regression that cmd "bt" prints
  *     wrong IRQ stack. This patch fix the bug by removing max_instructions
  *     calculation, and directly ask gdb to disassemble addresses range from
  *     "common_interrupt" to the next nearby symbol.
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit fce91bec5bef534e52f3261cc289a21a2cdb5fe3
  * Author: Tao Liu <ltao@redhat.com>
  * Date:   Sun Jul 11 22:30:22 2021 +0800
  *
  *     Fix the failure of reporting vmcore and vmlinux do not match for
  *     kernels(<2.6.11)
  *
  *     There is a regression issue for kernels(<2.6.11) as below:
  *
  *     $ crash 2.6.9-68.9/vmcore 2.6.9-68.9/vmlinux.gz
  *     ...
  *     GNU gdb (GDB) 10.2
  *     ...
  *     crash: /var/tmp/vmlinux.gz_GLsAvX and 2.6.9-68.9/vmcore do not match!
  *
  *     The reason is that it needs to read out the address of linux banner
  *     with readmem() first, and then the read_string() will be able to read
  *     the data from linux banner. So, for the kernels(<2.6.11) case, lets
  *     still invoke get_symbol_data() to accomplish this. See the changes:
  *     [1] https://elixir.bootlin.com/linux/v2.6.10/source/init/version.c#L38
  *     [2] https://elixir.bootlin.com/linux/v2.6.11/source/init/version.c#L38
  *
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 8d6f677e54a2474b3da19402e29278b62603d71d
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Thu Jul 8 16:14:02 2021 -0700
  *
  *     Do not adjust addr by relocate offset(KASLR)
  *
  *     GBD symbol resolution already considers relocation (KASLR) offset.
  *     So, there is no needs to adjust the function address before calling
  *     GDB.
  *
  *     It fixes file name and line number output for 'dis -l' and 'sys -c'
  *     commands.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *     Signed-off-by: Tao Liu <ltao@redhat.com>
  *
  * commit 6c5f0c6ff5d158f2ef4fa997a052b0643d0c25ee
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:36 2021 -0700
  *
  *     vmware_guestdump: add debugging of the init function
  *
  *     Dump memory and registers state after parsing.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *
  * commit 96716862765f73676bfdb2d19fc5872364d21b73
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:35 2021 -0700
  *
  *     vmware backend: honor silence flag
  *
  *     Do not print any boot messages in silence (-s) mode.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *
  * commit e832e0eb5bd8d97dfa9f4bd0e22fbfad849c11df
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:34 2021 -0700
  *
  *     Allow 'gdb disassemble' command for relocated kernel
  *
  *     As new gdb is able to handle it properly.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *
  * commit 2f967fb5ebd737ce5eadba462df35935122e8865
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:33 2021 -0700
  *
  *     crash_taget: fetch_registers support
  *
  *     Provides API for crash_target to fetch registers of given
  *     CPU. It will allow gdb to perform such commands as "bt",
  *     "frame", "info locals".
  *
  *     Highlevel API is crash_get_cpu_reg (). It calls machine
  *     (architecture) specific function: machdep->get_cpu_reg().
  *     Input arguments such as register number and register size
  *     come from gdb arch information. So, get_cpu_regs()
  *     implementations in crash must understand it.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *
  * commit 0b85218983ffcf939a638f1133871079c5615a46
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:30 2021 -0700
  *
  *     Fix reduced output of `bt` command
  *
  *     gdb-10 produces reduced output of `bt` command.
  *
  *     Changed disassembler output is the reason of missing frames
  *     in backtrace. Call instruction mnemonic for x86_64 was changed
  *     from "callq" to "call" in gdb-10.
  *
  *     Fixing the issue by adding a search for "call" word in disassembler
  *     parser.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *     Reported-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 36e9d8673e9205f4ea4daad61c199597920c93df
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:27 2021 -0700
  *
  *     "whatis -m": fix duplications in the output
  *
  *     "whatis -m" output started to generate duplicated results after GDB
  *     update:
  *
  *     crash> whatis -m mm_struct
  *     SIZE  TYPE
  *        16  tlb_state
  *     ...
  *       256  linux_binprm
  *       2752  rq
  *       2752  rq  <<-- duplicated
  *       2752  rq
  *       2752  rq
  *       2752  rq
  *       4048  task_struct
  *
  *     It was caused by incorrect string comparisons.
  *     Use strcmp for full string comparison instead of just string pointers
  *     comparison.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *     Reported-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 163abcbbabdf8207c11ee93b1c909d85ecbcbf1f
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Fri Mar 19 21:07:26 2021 -0700
  *
  *     crash_get_nr_cpus: get nr_cpus from the dumps
  *
  *     Most of the dumps have information about real number of CPUS.
  *     Use that to instantiate GDB's target inferior threads.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *
  * commit 9fab193edb34ddf30282b5ac137f7d8078198938
  * Author: Alexey Makhalov <amakhalov@vmware.com>
  * Date:   Tue Aug 17 17:14:59 2021 +0800
  *
  *     Update to gdb-10.2
  *
  *     Main changes:
  *     [1] update gdb-7.6.patch to gdb-10.2.patch, and keep all functionality
  *         and good compatibility
  *     [2] remove unneeded patches(gdb-7.6-proc_service.h.patch and
  *         gdb-7.6-ppc64le-support.patch)
  *     [3] to make the c++ compiler happy, add the extern "C" to eliminate
  *         compilation issues, also add CXXFLAGS=-m32 to generate proper
  *         32bit object files
  *     [4] the parameter types of some functions are changed, eg, the set of
  *         prettyprint variables
  *     [5] eliminate error_hook() and SJLJ while running in C++ code (after
  *         gdb_command_funnel()) use try-catch mechanism instead
  *     [6] request_types() is redone to do not call GNU_GET_NEXT_DATATYPE
  *     multiple times but single usage of GNU_ITERATE_DATATYPES with proper
  *     callback instead. Complete iteration happens on C++ side now.
  *     [7] remove "struct global_iterator" from request structure, but add
  *         several fields (including callback pointer) to be able to perform
  *         iteration on C++ side
  *     [8] type of "linux_banner" symbol is reported as 'D' by new gdb as its
  *         section ".rodata" marked as writable in vmlinux
  *     [9] BFD API has changed.
  *     [10] the deprecated_command_loop_hook got deprecated. So, call crash
  *          main_loop() directly from gdb captured_main()
  *     [11] remove previously used hooks for that in target.c. Add
  *     crash_target for gdb to provide target operations such as xfer_partial
  *     to read and write crash dump memory.
  *
  *     Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit 7f38d1baf794823355ee100b3a1914155d4190f2
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Mon Sep 27 09:45:42 2021 +0900
  *
  *     diskdump: Add support for reading dumpfiles compressed by Zstandard
  *
  *     Add support for reading dumpfiles compressed by Zstandard (zstd)
  *     using makedumpfile.
  *
  *     To build crash with zstd support, type "make zstd".
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit cf0c8d10e1870d89b39f40382634db51aa8fcf2c
  * Author: Hari Bathini <hbathini@linux.ibm.com>
  * Date:   Fri Sep 3 17:33:42 2021 +0530
  *
  *     mod: fix module object file lookup
  *
  *     On systems where vmlinux file is not under /usr/lib/debug/lib/modules
  *     directory, 'mod -s|-S' command may fail to find the module's object
  *     file with the below error:
  *
  *         mod: cannot find or load object file for sd_mod module
  *
  *     Fix it by trying all possible module object file extensions while
  *     searching for the object file under /usr/lib/debug/lib/modules
  *     directory.
  *
  *     Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
  *     Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
  *
  * commit 15765867c0f1d937db5ec06f51adb6bfd13354ea
  * Author: Ritesh Harjani <riteshh@linux.ibm.com>
  * Date:   Thu Aug 26 02:31:10 2021 +0530
  *
  *     ppc64: Add MMU type info in machdep command
  *
  *     This adds MMU type info in "machdep" command.
  *
  *     Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
  *
  * commit 3db5fff2e9d7b8762d1bd46d8d2c47ba4c7e374f
  * Author: Ritesh Harjani <riteshh@linux.ibm.com>
  * Date:   Thu Aug 26 02:31:08 2021 +0530
  *
  *     .gitignore: Add cscope, ctags & compile_commands.json
  *
  *     Add cscope, ctags & compile_commands.json in .gitignore file.
  *
  *     Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
  *
  * commit 4b34197508578bb43639e6d169fb91fb0489fa2b
  * Author: James Hsu <james.hsu@mediatek.com>
  * Date:   Wed Aug 18 15:45:47 2021 +0800
  *
  *  arm64: Get CPU registers from ELF notes even without crash_notes symbol
  *
  *  Currently arm64 crash retrieves the CPU registers from crash_notes symbol
  *  or ELF notes only when the symbol exists, but there are dumpfiles which
  *  have the registers in ELF notes without the symbol.
  *
  *  With the patch, crash can retrieve the registers from ELF notes without
  *  the crash_notes symbol.
  *
  *  Signed-off-by: James Hsu <james.hsu@mediatek.com>
  *  Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 44e5801d9016987b6b4ebd571bfde8ae3e75da7b
  * Author: Philipp Rudo <prudo@redhat.com>
  * Date:   Thu Aug 5 15:19:37 2021 +0200
  *
  *     x86_64: Fix check for __per_cpu_offset initialization
  *
  *     Since at least kernel v2.6.30 the __per_cpu_offset gets initialized to
  *     __per_cpu_load.  So first check if the __per_cpu_offset was set to a
  *     proper value before reading any per cpu variable to prevent potential
  *     bugs.
  *
  *     [ kh: added check for the existence of __per_cpu_load ]
  *
  *     Signed-off-by: Philipp Rudo <prudo@redhat.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 881f33d97cee9895796829d0cc969b51dd34d831
  * Author: Roman Bolshakov <r.bolshakov@yadro.com>
  * Date:   Thu Jun 17 02:27:35 2021 +0300
  *
  *     diskdump: Introduce read_pd()
  *
  *     Standalone function for reading of page descriptors is needed later for
  *     of expected core size and detection of incomplete dumps.
  *
  *     Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
  *
  * commit 1425b0504b1e79d88a2d188d7e4c0e7fceba4501
  * Author: Roman Bolshakov <r.bolshakov@yadro.com>
  * Date:   Thu Jun 17 02:27:34 2021 +0300
  *
  *  diskdump: Print total number of dumpable pages
  *
  *  It's not clear how broken an incomplete dump from the existing debugging
  *  prints. Aggregate number of valid pages helps to figure out approximate
  *  size of the dump. Size of a complete dump is roughly:
  *
  *    EXPECTED_CORE_SIZE = a few pages (kdump headers + bitmaps + descriptors)
  *                         (total_valid_pages * block_size) * compression rate
  *
  *  An incomplete core would be significantly smaller than:
  *
  *          total_valid_pages * block_size
  *
  *  Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
  *
  * commit 41cda195c6421fbde72ed67b32b8c1ab3eb0c56f
  * Author: Roman Bolshakov <r.bolshakov@yadro.com>
  * Date:   Thu Jun 17 02:27:33 2021 +0300
  *
  *  netdump: Permit --zero_excluded for incomplete ELF dumps
  *
  *  DUMP_ELF_INCOMPLETE is set very late after ENOSPC error is hit by
  *  makedumpfile. Any following error that prevents modification of ELF
  *  header would result in effectively incomplete core that doesn't have the
  *  flag. zero_excluded flag doesn't work for such kind of incomplete core.
  *
  *  Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
  *
  * commit 4631320e96f8a63c897fbbce4e87e3c47af40bc9
  * Author: Roman Bolshakov <r.bolshakov@yadro.com>
  * Date:   Thu Jun 17 02:27:32 2021 +0300
  *
  *     diskdump: Fail readmem() early if dump is incomplete
  *
  *     kdump format description [1] says:
  *
  *      [...] zero page has its own offset not equal 0. So when reading page
  *      from incomplete core, only the page lost by ENOSPACE errors has 0 in
  *      its corresponding page descriptor's member offset.
  *
  *     crash has special treatment for page descriptors with zero offset only
  *     if DUMP_DH_COMPRESSED_INCOMPLETE is set in dump header. However,
  *       makedumpfile places the flag after ENOSPC is hit and only if dump
  *       header modification went without errors.
  *
  *     In case if crashkernel environment was terminated early (e.g. by BMC)
  *     or some other reason, DUMP_DH_COMPRESSED_INCOMPLETE won't be set on
  *     the dump header. Then cache_page() would be performed on pages with
  *     pd.offset == 0 and due to pd.size == 0 it'll skip read into
  *     compressed_page and then non related pre-existing contents of
  *     compressed_page will copied into page cache for the non-present page.
  *
  *     Ultimately, it'll lead to a cryptic failure, like:
  *
  *       crash: invalid kernel virtual address: 72288cacacf427f8 [...]
  *
  *     The failure would be a bit cleaner if crash explicitly fails on the
  *     page that is an outcome of incomplete dump:
  *
  *       crash: page incomplete: kernel virtual address: c000003fff9d17e8 [...]
  *
  *     Debugging level 8 would also produce exact offset from data_offset to
  *     print descriptor value with ease:
  *
  *       read_diskdump/cache_page: descriptor with zero offset found at
  *       paddr/pfn/pos: 3fff9d0000/3fff9d/743dd
  *
  *     That helps in inspecting broken descriptor with hexdump or similar
  *     tools:
  *
  *       hexdump -s (data_offset + pos * 0x18) -n 0x18
  *
  *     [1] https://github.com/makedumpfile/makedumpfile/
  *     blob/master/IMPLEMENTATION
  *
  *     Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
  *
  * commit 80334ed25820cc08d147de5da361f427885cdd9e
  * Author: Aaron Tomlin <atomlin@redhat.com>
  * Date:   Tue Jul 13 14:24:49 2021 +0100
  *
  *     kmem: Add support to -S option to specify a range of CPU-specific slab
  *     data
  *
  *     With this patch, it is now possible for one to explicitly specify a
  *     range of CPU-specific slab data to list. For example:
  *
  *     Note: This is only applicable to a Linux kernel with Kconfig
  *           CONFIG_SLUB enabled. The optional argument GNU extension
  *           for getopt(3) is utilized; and, the CPU range must be
  *           specified as expected
  *
  *  crash> kmem -S=1,4 kmalloc-512
  *  CACHE             OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE  NAME
  *  ffff8d3f07c06c00      512       1916      3680    115    16k  kmalloc-512
  *  CPU 1 KMEM_CACHE_CPU:
  *    ffff8d461fa6f140
  *  CPU 1 SLAB:
  *    SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
  *    fffff540df7c4000  ffff8d45df100000     0     32          8    24
  *    FREE / [ALLOCATED]
  *     ffff8d45df100000  (cpu 1 cache)
  *    [ffff8d45df100200]
  *     ffff8d45df101000  (cpu 1 cache)
  *   ...skipped ...
  *  CPU 4 KMEM_CACHE_CPU:
  *    ffff8d461fb2f140
  *  CPU 4 SLAB:
  *    SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
  *    fffff540dfde3800  ffff8d45f78e0000     0     32          8    24
  *    FREE / [ALLOCATED]
  *    [ffff8d45f78e0000]
  *     ffff8d45f78e0200  (cpu 4 cache)
  *     ffff8d45f78e0400  (cpu 4 cache)
  *   ...skipped ...
  *
  * Signed-off-by: Aaron Tomlin <atomlin@redhat.com>
  * Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit f53b73e8380bca054cebd2b61ff118c46609429b
  * Author: Pingfan Liu <piliu@redhat.com>
  * Date:   Fri Jul 2 10:14:24 2021 +0800
  *
  *     arm64: implement switchable PTOV()/VTOP() for kernels >= 5.10
  *
  *     Crash encounters a bug like the following:
  *         ...
  *         SECTION_SIZE_BITS: 30
  *         CONFIG_ARM64_VA_BITS: 52
  *               VA_BITS_ACTUAL: 48
  *         (calculated) VA_BITS: 48
  *          PAGE_OFFSET: ffff000000000000
  *             VA_START: ffff800000000000
  *              modules: ffff800008000000 - ffff80000fffffff
  *              vmalloc: ffff800010000000 - ffffffdfdffeffff
  *         kernel image: ffff800010000000 - ffff800012750000
  *              vmemmap: ffffffdfffe00000 - ffffffffffffffff
  *
  *         <readmem: ffff800011c53bc8, KVADDR, "nr_irqs", 4, (FOE), b47bdc>
  *         <read_kdump: addr: ffff800011c53bc8 paddr: eb453bc8 cnt: 4>
  *         read_netdump: addr: ffff800011c53bc8 paddr: eb453bc8 cnt: 4
  *         offset: 1c73bc8
  *         irq_stack_ptr:
  *           type: 1, TYPE_CODE_PTR
  *           target_typecode: 8, TYPE_CODE_INT
  *           target_length: 8
  *           length: 8
  *         GNU_GET_DATATYPE[thread_union]: returned via gdb_error_hook
  *         <readmem: ffff000b779c0050, KVADDR, "IRQ stack pointer", 8, (ROE),
  *         3a37bea0>
  *         <read_kdump: addr: ffff000b779c0050 paddr: fff1000bf79c0050 cnt: 8>
  *         read_netdump: READ_ERROR: offset not found for paddr:
  *         fff1000bf79c0050
  *         crash: read error: kernel virtual address: ffff000b779c0050  type:
  *         "IRQ stack pointer"
  *         ...
  *
  *     Apparently, for a normal system, the 'paddr: fff1000bf79c0050' is
  *     unreasonable.
  *
  *     This bug connects with kernel commit 7bc1a0f9e176 ("arm64: mm: use
  *     single quantity to represent the PA to VA translation"), which removed
  *     physvirt_offset kernel variable and changed the PTOV()/VTOP() formulas.
  *
  *     Implement switchable PTOV()/VTOP() to cope with different kernel
  *     version.
  *
  *     Signed-off-by: Pingfan Liu <piliu@redhat.com>
  *
  * commit bf1379a8b6ff8d6a8fa12978f7194f15f85c4380
  * Author: Pingfan Liu <piliu@redhat.com>
  * Date:   Fri Jul 2 10:14:23 2021 +0800
  *
  *     arm64: use dedicated bits to record the VA space layout changes
  *
  *     arm64 memory layout experiences big changes due to the following kernel
  *     commits in date descending order:
  *       5. 7bc1a0f9e176 arm64: mm: use single quantity to represent the PA
  *          to VA translation
  *       4. b6d00d47e81a arm64: mm: Introduce 52-bit Kernel VAs
  *       3. 5383cc6efed1 arm64: mm: Introduce vabits_actual
  *       2. 14c127c957c1 arm64: mm: Flip kernel VA space
  *       1. f80fb3a3d508 arm64: add support for kernel ASLR
  *
  *     For 1, crash has already used NEW_VMEMMAP to trace it.
  *     For 2, crash lacks a flag to tag it and handle it differently.
  *     For 3, two important kernel variables vabits_actual and physvirt_offset
  *     are introduced.
  *     For 4, since it comes immediately after 3, crash-utility does not need
  *     to distinguish it.
  *     For 5, kernel variable phyvirt_offset is removed
  *
  *     These changes have effects on PTOV()/VTOP() formula. So introducing
  *     two bits HAS_PHYSVIRT_OFFSET and FLIPPED_VM as hint to apply different
  *     formula.
  *
  *     Signed-off-by: Pingfan Liu <piliu@redhat.com>
  *
  * commit 167d37e347fe35c6f7db826e8539e192c4375564
  * Author: Pingfan Liu <piliu@redhat.com>
  * Date:   Fri Jul 2 10:14:22 2021 +0800
  *
  *     arm64: assign page_offset with VA_BITS kernel configuration value
  *
  *     On RHEL9, crash hits a bug when executing "crash /proc/kcore":
  *     seek error: kernel virtual address: ffff6a0f3fff0000 type: "pmd page"
  *
  *     The kernel virtual address does not vary with vabits_actual, instead,
  *     is determined by configuration value. But crash does not observe this
  *     fact.
  *
  *     Since vabits_actual related kernel commit is introduced after arm64
  *     mm layout flip commit, so changes are safe under the condition if
  *     (ms->VA_BITS_ACTUAL), and keep the else branch untouched.
  *
  *     Signed-off-by: Pingfan Liu <piliu@redhat.com>
  *
  * commit 5719afc7a40868418405a87a2711088556e68a3b
  * Author: Pingfan Liu <piliu@redhat.com>
  * Date:   Fri Jul 2 10:14:21 2021 +0800
  *
  *     arm64: rename ARM64_PAGE_OFFSET_ACTUAL to ARM64_FLIP_PAGE_OFFSET_ACTUAL
  *
  *     Reflect the flipped layout of kernel VA, which is introduced by
  *     kernel commit 14c127c957c1 ("arm64: mm: Flip kernel VA space").
  *
  *     Signed-off-by: Pingfan Liu <piliu@redhat.com>
  *
  * commit d6b4f36d6b22b70fb14e692f36d20910ef5563c1
  * Author: Alexander Egorenkov <egorenar@linux.ibm.com>
  * Date:   Tue Jun 29 08:39:00 2021 +0200
  *
  *     Handle task_struct state member changes for kernels >= 5.14-rc1
  *
  *     Kernel commit 2f064a59a11ff9bc22e52e9678bc601404c7cb34 ("sched: Change
  *     task_struct::state") renamed the member state of task_struct to __state
  *     and its type changed from long to unsigned int.  Without the patch,
  *     crash fails to start up with the following error:
  *
  *       crash: invalid structure member offset: task_struct_state
  *              FILE: task.c  LINE: 5929  FUNCTION: task_state()
  *
  *     Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
  *
  * commit 4badc6229c69f5cd9da7eb7bdf400a53ec6db01a
  * Author: Petr Tesařík <ptesarik@suse.cz>
  * Date:   Fri Jun 25 17:21:18 2021 +0200
  *
  *  Fix pvops Xen detection for kernels >= v4.20
  *
  *  Kernel commit 5c83511bdb9832c86be20fb86b783356e2f58062 removed
  *  pv_init_ops, and later commit 054ac8ad5ebe4a69e1f0e842483821ddbe560121
  *  removed the Xen-specific paravirt patch function. As a result, pvops Xen
  *  dumps are no longer recognized as Xen dumps, and virtual-to-physical
  *  translation fails.
  *
  *  Use the value of xen_start_info to determine whether the kernel is
  *  running in Xen PV mode. This pointer is set during the initialization of
  *  a PV domain. Kudos to Juergen Gross, who suggested this check.
  *
  *  Signed-off-by: Petr Tesarik <ptesarik@suse.com>
  *
  * commit eaf14f852ae79f7745934e213661f1c6abac711e
  * Author: Greg Edwards <gedwards@ddn.com>
  * Date:   Wed Jun 23 13:50:47 2021 -0600
  *
  *  Fix 'waitq' command for Linux 4.13 and later kernels
  *
  *  The wait queue structs and members were renamed in 4.13 in commits:
  *
  *    ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
  *    9d9d676f595b ("sched/wait: Standardize internal naming of wait-queue
  *    heads")
  *    2055da97389a ("sched/wait: Disambiguate wq_entry->task_list and
  *    wq_head->task_list naming")
  *
  *  Add support to the 'waitq' command for these more recent kernels.
  *
  *  [ kh: suppressed compilation warnings ]
  *
  *  Signed-off-by: Greg Edwards <gedwards@ddn.com>
  *  Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit f091b5e76d2d6e81b12cd40df7b5863c9e2efed1
  * Author: Firo Yang <firo.yang@suse.com>
  * Date:   Tue May 25 18:17:37 2021 +0800
  *
  *     list: add -O option for specifying head node offset
  *
  *     The -O option is very useful to specify the embedded head node's
  *     offset which is different to the offset of other nodes embedded,
  *     e.g. dentry.d_subdirs (the head node) and dentry.d_child.
  *
  *     [ kh: did some cosmetic adjustments ]
  *
  *     Signed-off-by: Firo Yang <firo.yang@suse.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit e61841a8b86ac551c314f74f4b82daae84f99700
  * Author: Luc Chouinard <lucchouina@gmail.com>
  * Date:   Wed Jun 9 07:59:40 2021 -0400
  *
  *     extensions/eppic.mk: Enable use of alternate eppic branch
  *
  *     Made significant changes and fixes to eppic.
  *     Using options in the clone command break due to args parsing.
  *     Use separate variable for clone options.
  *
  *     Closes: https://github.com/crash-utility/crash/pull/86
  *
  * commit c15a1e025e62134094ba0ac600263d75673d5a22
  * Author: Youling Tang <tangyouling@loongson.cn>
  * Date:   Fri Apr 23 15:42:11 2021 +0800
  *
  *     MIPS64: three fixes for MIPS64 kernels
  *
  *     Three fixes for MIPS64 kernels:
  *      (1) To support ramdumps, add the machine_type() check for MIPS64 in
  *          ramdump_to_elf().
  *      (2) To fix a stuck issue when invoking crash with "-d1" or larger
  *          debug value, add the machine_type() check to get the correct
  *          dump NOTE offsets.
  *      (3) Fix the reference file path to the definition of the pt_regs
  *          structure, to which mips64_regster refers.
  *
  *     [ kh: merged three patches into one ]
  *
  *     Signed-off-by: Youling Tang <tangyouling@loongson.cn>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 859d1c0e8a6618634cbc1fe7ee2b082a6a3c99a1
  * Author: Youling Tang <tangyouling@loongson.cn>
  * Date:   Fri Apr 23 15:40:41 2021 +0800
  *
  *     MIPS32/64: Add 'irq' command support
  *
  *     Add support for the 'irq' series of commands in the MIPS32/64
  *     architecture, except for the 'irq -d' command, others can be
  *     used.  Without the patch, the 'irq' command fails as follows:
  *
  *       irq: cannot determine number of IRQs
  *
  *     Signed-off-by: Youling Tang <tangyouling@loongson.cn>
  *
  * commit 704623dfde43da98ffb354b3d7f450cd012a8215
  * Author: Youling Tang <tangyouling@loongson.cn>
  * Date:   Thu Jun 3 16:07:41 2021 +0800
  *
  *     defs.h: Fix the value of TIF_SIGPENDING macro
  *
  *     Correct the change of the value of TIF_SIGPENDING macro between
  *     different kernel versions.
  *
  *     TIF_SIGPENDING changes with the kernel version as follows:
  *       ARM     2 -> 0 at v2.6.23
  *       MIPS    2 -> 1 at v2.6.23
  *       MIPS64  2 -> 1 at v2.6.23
  *       PPC     2 -> 1 at v2.6.23
  *       IA64    1 -> 0 at v2.6.23
  *       PPC64   2 -> 1 at v2.6.23
  *       S390    2 -> 1 at v3.16
  *       S390X   2 -> 1 at v3.16
  *
  *     Signed-off-by: Youling Tang <tangyouling@loongson.cn>
  *
  * commit ec44b902d3467e7b86ee39e2d7d472b9cb202148
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Mon May 31 14:08:28 2021 +0900
  *
  *     memory: Fix for "kmem -n" option to display NID correctly
  *
  *     The nid member of struct memory_block is a 4-byte integer, but read
  *     and printed as a 8-byte integer on 64-bit machines.  Without the
  *     patch, the option displays wrong NIDs.
  *
  *       crash> kmem -n
  *       ...
  *   MEM_BLOCK        ... NODE  STATE   START_SECTION_NO
  * ffff9edeff2b9400   ... 14195095130662240256  ONLINE  0
  * ffff9edeff2bb400   ... 14195094718345379840  ONLINE  32
  *
  *     The issue seems to appear on Linux 5.12 and later kernels that contain
  *     commit e9a2e48e8704c ("drivers/base/memory: don't store phys_device
  *     in memory blocks"), which changed the arrangement of the members of
  *     struct memory_block.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 0b5435e10161345cf713ed447a155a611a1b408b
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Wed May 26 17:33:13 2021 +0900
  *
  *     memory: Add support for SECTION_TAINT_ZONE_DEVICE flag
  *
  *     Fix for "kmem -n|-p" options on Linux 5.12-rc1 and later kernels
  *     that contain commit 1f90a3477df3f ("mm: teach pfn_to_online_page()
  *     about ZONE_DEVICE section collisions").  Without the patch, the
  *     "kmem -n" option incorrectly shows mem_map addresses containing the
  *     flag in bit 5 as part of the virtual address, and also the "kmem -p"
  *     option shows page structures at wrong position.  With the patch,
  *     the "kmem -n" option displays the new "D" state flag.
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 647a5c33e1c94054d7b63168cd6c12901591cb77
  * Author: Lianbo Jiang <lijiang@redhat.com>
  * Date:   Thu May 27 18:02:11 2021 +0800
  *
  *     Fix for "kmem -s|-S" option on Linux 5.7 and later kernels
  *
  *     Linux 5.7 and later kernels that contain kernel commit 1ad53d9fa3f6
  *     ("slub: improve bit diffusion for freelist ptr obfuscation") changed
  *     the calculation formula in the freelist_ptr(), which added a swab()
  *     call to mix bits a little more.  When kernel is configured with the
  *     "CONFIG_SLAB_FREELIST_HARDENED=y", without the patch, the "kmem -s|-S"
  *     options display wrong statistics and state whether slab objects are
  *     in use or free and can print the following errors:
  *
  *       ...
  *
  *     Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
  *
  * commit a7ecf2467f953b632713f38ab8104596755bca8c
  * Author: John Donnelly <john.p.donnelly@oracle.com>
  * Date:   Wed May 12 14:48:03 2021 -0700
  *
  *     arm64: Add lowercase tcr_el1_t1sz
  *
  *     Commit 1c45cea "arm64: Change tcr_el1_t1sz variable name to
  *     TCR_EL1_T1SZ", renamed the variable to upper case, but there are
  *     kernels in existence that still have the lower case name, which
  *     breaks crash backwards compatibility.
  *
  *     Resolves: https://github.com/crash-utility/crash/pull/82
  *     Signed-off-by: John Donnelly <john.p.donnelly@oracle.com>
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *
  * commit 1ee4c407d7874b8eef17e863671edc8ccfdd7c71
  * Author: Kazuhito Hagio <k-hagio-ab@nec.com>
  * Date:   Tue May 18 10:18:10 2021 +0900
  *
  *     Mark start of 7.3.1 development phase with version 7.3.0++
  *
  *     Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
  *

 -- Troy Heber <troyh@debian.org>  Wed, 02 Feb 2022 09:19:00 -0700

crash (7.3.0-1ubuntu1) impish; urgency=medium

  * Merge with Debian; remaining changes:
    - Build without lto. Fails to build gdb on ppc64el. That should be fixed,
      once gdb is updated to a more recent version (e.g. 10.x).
    - Add linux-libc-dev dependency for the autopkg test. This package
      gets usually broken with kernel upgrades, so let it already show
      in the autopkg test.

 -- dann frazier <dann.frazier@canonical.com>  Thu, 08 Jul 2021 09:16:21 -0600

crash (7.3.0-1) experimental; urgency=medium

  * Add support for new lockless righbuffer that Linux 5.10 introduced.
    Without the two patches, crash fails during session initialization or
    "log" command fails with the error message:

    crash: cannot determine length of symbol: log_end

  * Add support for VC exception stack on x86_64 Linux 5.10 and later kernels
    that contain commit 02772fb9b68e ("x86/sev-es: Allocate and map an IST
    stack for #VC handler").

  * Fix regression for raw RAM dumpfiles.  Commit f42db6a33f0e ("Support core
    files with "unusual" layout") increased the minimal file size from
    MIN_NETDUMP_ELF_HEADER_SIZE to SAFE_NETDUMP_ELF_HEADER_SIZE which can lead
    to crash rejecting raw RAM dumpfiles.  Without the patch, the crash fails
    to start a session with the error message:

    /var/tmp/ramdump_elf_XXXXXX: ELF header read: No such file or directory
    crash: malformed ELF file: /var/tmp/ramdump_elf_XXXXXX


  * Update mapping symbol filter in arm64_verify_symbol() to support the long
    form of mapping symbols, e.g. "$x.<any...>".  Without the patch, the "dis"
    command cannot completely parse out the disassembly of a function that has
    mapping symbols in the long form and misses the tail part of the function.

  * Move extensins/Makefile's ping check to recipe script.  Without this
    patch, in an environment where ping to github.com does not work, "make
    clean" at the top-level crash directory always takes about 10 seconds
    unnecessarily.

  * Fix for a segmentation fault when analyzing arm64 kernels that are
    configured with CONFIG_IKCONFIG and have a strange entry that does not
    contain the delimiter "=", such as "CONFIG_SECU+[some hex data]".  Without
    the patch, in the add_ikconfig_entry() function, strtok_r() interprets it
    as consisting of a single token and the val variable is set to NULL, and
    then strdup() crashes.

  * Fix a couple of issues that were detected by valgrind.

  * Add ability to un-set scope.  The ability can come in very useful when
    running automated pykdump scripts and needing scope to be cleared between
    script runs.

  * Fix "sys [-t]|mod -S" after "mod -t" when crash runs with -s option.
    Without the patch, the "sys [-t]" and "mod -S" options after "mod -t"
    option fail with the error message:

    sys: invalid structure member offset: tnt_false FILE: kernel.c  LINE:
    11203  FUNCTION: show_kernel_taints_v4_10()

  * Fix for "dev -d" option on Linux 5.11-rc1 and later kernels that contains
    commit 0d02129e76edf91cf04fabf1efbc3a9a1f1d729a ("block: merge struct
    block_device and struct hd_struct").  Without the patch, the option fails
    with the error message:

    dev: invalid structure member offset: hd_struct_dev

  * Fix for "kmem -v" option on Linux 5.11-rc1 and later kernels that contain
    commit 96e2db456135db0cf2476b6890f1e8b2fdcf21eb ("mm/vmalloc: rework the
    drain logic").  Without the patch, the option will display nothing or fail
    with the error message:

    kmem: invalid kernel virtual address: <address>  type: "vmlist addr"

  * Add the base address of module to "mod" command output.  Currently the
    command shows the address of the module struct, but it is inconvenient to
    know the address range of the module, so extend to show the base address.

  * Increase the value of __PHYSICAL_MASK_SHIFT_XEN to 52.  The former value
    of __PHYSICAL_MASK_SHIFT_XEN in crash (40) is smaller than the kernel (52)
    since kernel commit 6f0e8bf167 (xen: support 52 bit physical addresses in
    pv guests).  This can cause x86_64_pud_offset() to lose the most
    significant bits of pgd_pte, leading to a failed xen_m2p() translation,
    resulting in crash failing with an error message like this:

    crash: read error: physical address: ffffffffffffffff  type: "pud page"

  * Change log level print in older kernels.  In older kernels that have the
    variable-length-record log_buf, the log level and the log flags/facility
    are not separated.  Since the log level is only the last three bits, and
    the flags/facility and level are separated in
    5.10 and later kernels, only print those last three bits when using 'log
    -m'.

  * Reduce crash build log.  The verbose output of tar command when extracting
    the GDB source files occupies more than the half of crash build log.  It
    is not so helpful and makes the build log longer needlessly especially on
    CI build test without the patch.

  * Fix for "bt" command on Linux 5.12-rc1 and later x86_64 kernels that
    contain commit 951c2a51ae75 ("x86/irq/64: Adjust the per CPU irq stack
    pointer by 8").  Without the patch, the "bt" command and some of its
    options that read irq stack fail with the error message:

    bt: read of stack at <address> failed".

  * Add valgrind support for the crash's custom memory allocator.  This helps
    detecting various memory errors on the crash's custom memory allocator.

  * Fix for a couple of invalid read/write issues detected by valgrind.

  * Fix "struct" command to print member array of list_heads correctly.
    Without the patch, due to the way that an array of list_head entries are
    printed, parsing of them fails and the command does not print anything:

    crash> struct blk_mq_ctx.rq_completed ffffc447ffc0f740 crash>

  * Do not pass through 'sy' command to GDB.  The GDB 'symbol-file' command is
    prohibited in the crash utility, but an abbreviation of it, the 'sy' is
    not prohibited.  This can discard symbol table from the current symbol
    file, and eventually caused the failure of crash utility after executing
    the 'sys' command as below:

    crash> sy Discard symbol table from `/path/to/vmlinux'? (y or n) Please
    answer y or n.  Discard symbol table from `/path/to/vmlinux'? (y or n) No
    symbol file now.  crash> sys double free or corruption (!prev) Aborted
    (core dumped)

  * Refine zram related code for crash gcore command to support it.

  * Fix for the failure of 'set scope' command.  Without the patch, some
    commands such as 'sys' may cause subsequent 'set scope' commands to fail.

  * Fix for offset print for function pointers that return pointers.  In the
    show_member_offset() function, when trying to handle function pointers,
    the case for "(*" is handled.  However, if the function pointer returns a
    pointer or a pointer to a pointer, then the condition is unhandled.  This
    results in the offset not being printed without the patch, for example:

    crash> struct -o offload_callbacks struct offload_callbacks { struct
    sk_buff *(*gso_segment)(struct sk_buff *, netdev_features_t); struct
    sk_buff **(*gro_receive)(struct sk_buff **, struct sk_buff *); [16] int
    (*gro_complete)(struct sk_buff *, int); }

  * Change functions within extensions/echo.c to be static and document the
    issue in code comments, for extensions developers who takes echo.c as
    reference, to avoid the issue that symbols in extension modules are
    overwritten by former loaded one if it's the same name.

  * Fix for 'bt' command and options on Linux 5.8-rc1 and later x86_64 kernels
    that contain merge commit 076f14be7fc9.  The merged patches changed the
    name of exception functions that have been used by the crash utility to
    check the exception frame.  Without the patch, the command and options
    cannot display it.

  * Fix for xen kernels that contain commit edcb5cf84f05 ("x86/paravirt/xen:
    Remove xen_patch()"). Without the patch, crash fails with an error
    message like this:

    crash: seek error: physical address: 83640e000 type: "pud page"

  * Remove extensions/trace.c file, as the extension module moved to the
    separate repository from the crash repository.

  * Fix for uvtop conversion on ARM with LPAE.  Without the patch, arm_uvtop()
    calls arm_lpae_vtop() with the LPAE and it can use LPAE_VTOP() also for a
    user virtual address.  As a result, commands that use uvtop conversion
    such as "ps -a", "gcore" fail as readmem() for a uvaddr returns a seek
    error:

    ps: cannot access user stack address: <address>

  * Handle 1GB block for VM_L3_4K on arm64 architecture.  Without the patch,
    "vtop" command cannot display the block as a 1GB hugepage.

  * Implement initial support for the MIP64 architecture.

  * Fix for HZ calculation using cfq_slice_async on Linux 4.8 and later
    kernels that contain commit 9a7f38c42c2b ("cfq-iosched: Convert from
    jiffies to nanoseconds").  Without the patch, the HZ calculation results
    in a wrong and big value for machde->hz and crash can shows a wrong uptime
    and timestamps in "log -T".

  * Fix for HZ calculation on Linux 4.8 and later kernels that contain commit
    9a7f38c42c2b ("cfq-iosched: Convert from jiffies to nanoseconds").
    Without the patch, the HZ value can be set to a hardcorded wrong value.

 -- Troy Heber <troyh@debian.org>  Wed, 07 Jul 2021 15:31:12 -0600

crash (7.2.9-2ubuntu3) impish; urgency=medium

  * Add linux-libc-dev dependency for the autopkg test. This package
    gets usually broken with kernel upgrades, so let it already show
    in the autopkg test.

 -- Matthias Klose <doko@ubuntu.com>  Mon, 21 Jun 2021 09:54:43 +0200

crash (7.2.9-2ubuntu2) hirsute; urgency=medium

  * Build without lto. Fails to build gdb on ppc64el. That should be fixed,
    once gdb is updated to a more recent version (e.g. 10.x).

 -- Matthias Klose <doko@ubuntu.com>  Thu, 25 Mar 2021 10:04:06 +0100

crash (7.2.9-2ubuntu1) hirsute; urgency=medium

  * Merge with Debian; remaining changes:

 -- Matthias Klose <doko@ubuntu.com>  Thu, 25 Mar 2021 09:08:04 +0100

crash (7.2.9-2) unstable; urgency=medium

  * Backporting future patches to support printk in kernel 5.10+ based on:
    https://github.com/crash-utility/crash/compare/bf57c44...71e159c
  * Update to current debhelper 13.

 -- Troy Heber <troyh@debian.org>  Tue, 08 Dec 2020 12:58:57 -0700

crash (7.2.9-1) unstable; urgency=medium

  * Patch from Sebastian Andrzej Siewior <sebastian@breakpoint.cc>: The crash
    project moved recently to github. The attached patch updates the
    information within the package. It also adds a watch file which points to
    the latest release (closes: #976195)

  * Fix for an ARM64 gcc-10 compilation error.  Without the patch, the build
    of the embedded gdb module fails with an error message that indicates
    "multiple definition of 'tdesc_aarch64'".

  * Fix for the "log" command.  Without the patch, the command's output may be
    truncated, ending with the error message "log: invalid log_buf entry
    encountered".

  * Fix to allow the translation of ARM64 FIXMAP addresses located in the
    virtual memory region between the end of the vmalloc region and the
    beginning of the vmemmap region.  Without the patch, reads of virtual
    addresses within that region are not recognized properly and will fail.

  * Introduction of a new "extend -s" option, which shows all available shared
    object extension modules that are located in the directories that are part
    of the normal search path that is used when a shared object is loaded
    without a fully-qualified pathname.

  * Fix for the "bpf -m|-M" options on Linux 5.3 and later kernels that
    contain commit 3539b96e041c06e4317082816d90ec09160aeb11, titled "bpf:
    group memory related fields in struct bpf_map_memory".  Without the patch,
    the options prints "(unknown)" for MEMLOCK and UID.

  * Enhancement to the "bpf -p|-P" options to display the eBPF program name
    string.

  * Fix for reading compressed kdump dumpfiles from systems with physical
    memory located at extraordinarily high addresses.  In a system with a
    physical address range from 0x602770ecf000 to 0x6027ffffffff, the crash
    utility fails during session initialization due to an integer overflow,
    ending with the error message "crash: vmlinux and vmcore do not match!".

  * Enhancement of the "struct -r" option to support the raw memory display of
    a single data structure member.  Without the patch, the option only
    supported the raw display of a complete data structure.

  * Modify the display behavior of the "struct -r" option so as to scale the
    minimum display size from the size of a per-architecture long (32-bits or
    64-bits) down to 8-bits, 16-bits or 32-bits when the requested size is
    equal to one of the smaller sizes.

  * Introduce a new ARM64 "--machdep vabits_actual=<value>" command line
    option for Linux 5.4 and later dumpfiles, which require the kernel's
    dynamically-determined "vabits_actual" value for virtual address
    translation.  Without the patch, the crash session fails during
    initialization with the error message "crash: cannot determine
    VA_BITS_ACTUAL".  This option will become unnecessary when the proposed
    TCR_EL1.T1SZ vmcoreinfo entry is incorporated into the kernel.

  * Fix for "kmem -[sS]" options on Linux 4.14 and later kernels built with
    CONFIG_SLAB_FREELIST_HARDENED enabled. Without the patch, there will error
    messages of the type "kmem: <cache name> slab: <address> invalid
    freepointer: <obfuscated address>" for caches created during SLUB
    bootstrap, as they are likely to have s->random == 0.

  * If readmem() receives a user-space address in a page that has been swapped
    to the zswap compressed swap cache, an attempt will be made to find and
    decompress the page.

  * Fix for the "mount -n [pid|task]" option when running on a live system.
    Without the patch, if the [pid|task] has been created since the last
    internal task table refresh, the command fails with the error message
    "mount: invalid task or pid value: <value>".

  * Introduction of the "log -T" option, which translates the leading
    timestamp value of each message into human readable format.

  * When kernels are built with LLVM, the names of many symbols may be
    appended with an ".llvm.<number>" string.  As a result, commands such as
    "irq" fail with the error message irq: neither irq_desc, _irq_desc,
    irq_desc_ptrs or irq_desc_tree symbols exist".  This patch adds the
    LLVM-generated string to the other strings that are stripped from symbols
    before they are stored.

  * Prepare for the introduction of ARM64 8.3 Pointer Authentication as
    in-kernel feature.  The value of CONFIG_ARM64_KERNELPACMASK will be
    exported as a vmcoreinfo entry, and will be used with text return
    addresses on the kernel stack.

  * Several fixes for ARM64 kernels:
    (1) Linux kernel patch "arm64: mm: Introduce vabits_actual"
        introduced "physvirt_offset", which is not equal to
        (PHYS_OFFSET - PAGE_OFFSET) when KASLR is enabled.
        physvirt_offset is caculated in arch/arm64/mm/init.c
        before memstart_addr (PHYS_OFFSET) is randomized.  Let
        arm64_VTOP() and arm64_PTOV() use physvirt_offset instead,
        whose default value is set to (phys_offset - page_offset)
    (2) For ARM64 RAM dumps without any vmcoreinfo and KASLRpassed as
        argument, " _stext_vmlinux" is not set.  This causes incorrect
        calculation of vmalloc_start with VA_BITS_ACTUAL.
    (3) For ARM64 RAM dumps For ramdumps without vmcoreinfo, get
        CONFIG_ARM64_VA_BITS from in-kernel config. Without this,
        vmemmap size is calculated incorrectly.
    (4) Fix the vmemmap_start to match with what the kernel uses.

  * Replace people.redhat.com references with github equivalents.

  * Implement support for user-space zram reads on x86_64 for recent
   Fedora kernel version 5.6.7-200.fc31.  The patch adds the following:
    (1) Redefine _PFN_BITS() macro to use MAX_POSSIBLE_PHYSMEM_BITS.
    (2) Fix to determine whether address_space.i_pages is a radix tree
        or an xarray.
    (3) Fix to not mistakenly select the "lzo" compressor when the
        kernel has used the default "lzo-rle" compressor.
    (4) Since zram may be provided as a kernel module, it would be
        necessary to load its debuginfo during the crash session;
        therefore perform the zram structure-size/member-offset
        initializations when first required instead of during
        session initialization.
    (5) Handle the zram_table_entry structure member name change
        from "value" to "flags".

  * Add support for 1GB huge pages to "vtop" command on x86_64.  Without this
    patch, the command with a user virtual address corresponding to a 1GB huge
    page fails with the error message "vtop: seek error: physical address:
    <address>  type: "page table".

  * Fix six spelling typos in help.c.

  * Change tcr_el1_t1sz vmcoreinfo entry name to TCR_EL1_T1SZ according to
    kernel commit bbdbc11804ff ("arm64/crash_core: Export TCR_EL1.T1SZ in
    vmcoreinfo").

  * Fix for a failure of calculating kaslr_offset due to an sadump format
    restriction.  Without the patch set, calculating kaslr_offset fails
    because it is based on the assumption that unused part of register values
    in the sadump format are always zero cleared.

  * Support for huge holes in vmem of VMware VMSS dumpfiles.  Without the
    patch, if the hole is big enough, the multiplication by page size will
    truncate as it's operating on a uint32_t.

  * Beautify and extend debug log for VMware VMSS dumpfiles.  Without the
    patch, the parser's debug log is missing a few line breaks as well as some
    crucial information, like control register dumps.

  * Support core files with unusual layout that the ELF program headers do not
    directly follow the ELF header, such as vmcores generated with 'vmss2core'
    tool.

  * Fix for the "log -T" option when crash is started with "--minimal" option.
    Without the patch, crash will spin at 100% and continuously crash at a
    divide by zero.  Disallow the option in minimal mode.

  * Remove raw-view from s390bpf.  With kernel commit ecb1ff6833c4
    ("s390/debug: remove raw view"), the raw-view is no longer supported by
    s390 debug feature.  Since there has never been a single user of the
    raw-view, remove it from crash as well.

  * Support s390 debug feature version 3, which was introduced by kernel
    commit 0990d836cecb ("s390/debug: debug feature version 3").

  * Basic support for PaX's split module layout.  PaX and grsecurity kernels
    split module memory into dedicated r/x and r/w mappings using '*_rw' and
    '*_rx' named member variables in 'struct module'.  To add basic support
    for such kernels, detect the split layout by testing for the corresponding
      structure members and use these instead.

  * Fix for the "kmem -i" option on Linux 5.9-rc1 and later kernels that
    contain commit 1008fe6dc36d ("block: remove the all_bdevs list").  Without
    the patch, the option fails halfway with the error message 'kmem: cannot
    resolve: "all_bdevs"'.

  * Fix for the "irq -a" option on Linux 4.3 or later kernels that contain
    commit 9df872faa7e1 ("genirq: Move field 'affinity' from irq_data into
    irq_common_data").  Without the patch, the option cannot work with the
    message "irq: -a option not supported or applicable on this architecture
    or kernel".

  * Append time zone explicitly to each output of date and time like "DATE:
    Thu Nov 29 06:44:02 JST 2018".

  * Fixes for the "trace.so" extension module on Linux 5.6 and later kernels
    that contain commit: (1) 1c5eb4481e01 ("tracing: Rename trace_buffer to
    array_buffer") (2) 13292494379f ("tracing: Make struct ring_buffer less
    ambiguous") With the patch set, rename trace_buffer to array_buffer and
    ring_buffer to trace_buffer respectively.

  * Fix for the "help -D" option listing uninteresting register entries for
    SADUMP dumpfiles.

  * Fix for an initialization-time failure due to offset change of the name
    member of struct uts_namespace that might be introduced by linux-next
    commit 9a56493f6942 ("uts: Use generic ns_common::count").

  * Add support for VMware guestdump (debug.guest) and vmem (debug.vmem)
    files.  To use, the companion debug.vmem file must be present in the same
    directory as the debug.guest file.

  * Fix for the "extend" command on a PPC64 targeted x86_64 crash binary.
    Without the patch, the command on an x86_64 crash binary that can be used
    to analyze ppc64le dumpfiles fails with the error message "extend: <path
    to extension>: not an ELF format object".

  * Fix for a failure to match arm/aarch64 ELF format of xendump file.

  * Fix for the x86_64 "bt" command in cases where the pt_regs is not present
    in the stack.  Without the patch, the command can be incomplete with the
    error message 'bt: seek error: kernel virtual address: <address> type:
    "pt_regs"'.

  * Fix for the crash.ko memory driver build with Linux 5.8 and later kernels
    that contain commit fe557319aa06 ("maccess: rename
    probe_kernel_{read,write} to copy_{from,to}_kernel_nofault").
    Additionally, due to commit 0493cb086353 ("maccess: unexport
    probe_kernel_write()"), writing kernel memory is no longer possible from a
    module.  Without this patch, build with the kernels fails with the error
    message "error: implicit declaration of function 'probe_kernel_write'".

  * Fix for the memory_driver/Makefile for Linux 5.4 and later kernels that
    contain commit 7e35b42591c0 ("kbuild: remove SUBDIRS support").  Without
    the patch, the "make" command in the memory_driver directory doesn't build
    crash memory driver module as expected.

  * Improvements of KASLR offset detection for QEMU, VMware VMSS and SADUMP
    dumpfiles: (1) Try all CPUs to provide CR3 and IDTR, because these
    registers on CPU0 can be not initialized or clobbered.  (2) Support
    5-level page table by using LA57 bit in CR4.  (3) Get KASLR offset by
    walking page tree.

  * Fix for an initialization-time failure with QEMU dumpfiles with Linux
    5.8 and later x86_64 kernels that contain commit 9d06c4027f21 ("x86/entry:
    Convert Divide Error to IDTENTRY"), renamed divide_error handler to
    asm_exc_divide_error.

  * Fix for several compiler warnings on 32-bit architectures when building
    with "make warn".  Without the patch, gcc generates the message "warning:
    format '%ld' expects argument of type 'long int', but argument 4 has type
    'uint64_t' [-Wformat=]" and similar ones as a result of crash commit
    3fedbee9bfbb ("vmware_guestdump: new input format").

  * Speed up session initialization by avoiding unnecessary processing in the
    stkptr_to_task() function when sp is 0 on some architectures.  Without the
    patch, as it runs through each task's stack to find whether the given
    address is in its range, on a system with about
    1500 CPUs and 165k running tasks, it takes about a day to finish session
    initialization.  With the patch applied, it only takes about 5-10 minutes.

 -- Troy Heber <troyh@debian.org>  Thu, 03 Dec 2020 09:53:49 -0700

crash (7.2.8-1ubuntu1) focal; urgency=low

  * Merge from Debian unstable.  Remaining changes:
    - Update the maintainer field for Ubuntu.
    - If the "live" autopkgtest fails with a recommendation to try
      /proc/kcore instead of the default, attempt that before failing
      the test. LP: #1858958.
  * Fix test, as if will return 0 when no cases were true.

 -- Thadeu Lima de Souza Cascardo <cascardo@canonical.com>  Wed, 12 Feb 2020 22:12:51 +0000

crash (7.2.8-1) unstable; urgency=medium

  * New upstream (Closes: #950544)

  * Fix for Linux 5.4-rc1 and later kernels that contain commit
    688fcbfc06e4fdfbb7e1d5a942a1460fe6379d2d, titled "mm/vmalloc: modify
    struct vmap_area to reduce its size".  Without the patch "kmem -v" will
    display nothing; other architectures that utilize the vmap_area_list to
    determine the base of mapped/vmalloc address space will fail.

  * Fix for Linux 5.4-rc1 and later kernels that contain commit/merge
    e0703556644a531e50b5dc61b9f6ea83af5f6604, titled "Merge tag 'modules-
    for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux
    which introduces symbol namespaces.  Without the patch, and depending upon
    the architecture:
    (1) the kernel module symbol list will contain garbage entries
    (2) the session fails during session initialization with a dump of
       the internal buffer allocation stats followed by the message
       "crash: cannot allocate any more memory!"
    (3) the session fails during session initialization with a
       segmentation violation.

  * Fix for the "timer -r" option on Linux 5.4-rc1 and later kernels that
    contain commit 511885d7061eda3eb1faf3f57dcc936ff75863f1, titled
    "lib/timerqueue: Rely on rbtree semantics for next timer".  Without the
    patch, the option fails with the following error "timer: invalid structure
    member offset: timerqueue_head_next".

  * Fix for a "[-Wstringop-truncation]" compiler warning emitted when
    symbols.c is built in a Fedora Rawhide environment with gcc-9.0.1 or
    later.

  * Fix for the "kmem -n" option on Linux-5.4-rc1 and later kernels that
    contain commit b6c88d3b9d38f9448e0fcf44847a075ea81d5ca2, titled
    "drivers/base/memory.c: don't store end_section_nr in memory blocks".
    Without the patch, the command option fails with the error message "kmem:
    invalid structure member offset: memory_block_end_section_nr".

  * Fix for Linux 4.19.5 and later 4.19-based x86_64 kernels which are NOT
    configured with CONFIG_RANDOMIZE_BASE and have backported kernel commit
    d52888aa2753e3063a9d3a0c9f72f94aa9809c15, titled "x86/mm: Move LDT remap
    out of KASLR region on 5-level paging", which modified the 4-level and
    5-level paging PAGE_OFFSET values.  Without this patch, the crash session
    fails during initialization with the error message "crash: seek error:
    kernel virtual address: <address> type: "tss_struct ist array".

  * Additional fix for the "kmem -n" option on Linux-5.4-rc1 and later kernels
    that contain commit b6c88d3b9d38f9448e0fcf44847a075ea81d5ca2, titled
    "drivers/base/memory.c: don't store end_section_nr in memory blocks".  The
    initial fix only addressed the x86_64 architecture; this incremental patch
    addresses the other architectures.

  * In the unlikely event that the panic task in a dumpfile cannot be
    determined by the normal means, scan the kernel log buffer for panic
    keywords, and if found, generate the panic task from the CPU number that
    is specified following the panic message.

  * Adjust a crash-7.1.8 patch for support of /proc/kcore as the live memory
    source in Linux 4.8 and later x86_64 kernels configured with
    CONFIG_RANDOMIZE_BASE, which randomizes the unity-mapping PAGE_OFFSET
    value.  Since the problem only arises before the determination of the
    randomized PAGE_OFFSET value, restrict the patch such that it only takes
    effect during session initialization.

  * Add support for extended numbering support in ELF dumpfiles to handle more
    than PN_XNUM (0xffff) program headers.  If the real number of program
    header table entries is equal to or greater than PN_XNUM, the e_phnum
    field of the ELF header is set to PN_XNUM, and the actual number is set in
    the sh_info field of the section header at index 0.

  * Fix for a "warning: large integer implicitly truncated to unsigned type
    [-Woverflow]" compiler message generated on 32-bit architectures as a
    result of the "Additional fix for the kmem -n option" patch above.

  * Add support for handling openSUSE vmlinux files which will be shipped in
    .xz compressed format.  Without the patch, only gzip and bzip2 formats are
    supported.

  * Fix for the determination of the ARM64 page size on Linux 4.4 and earlier
    kernels that do not have vmcoreinfo data.  Without the patch, the crash
    session fails during initialization with the error message "crash: "cannot
    determine page size".

  * Determine the ARM64 kernel's "vabits_actual" value by reading the new
    TCR_EL1.T1SZ vmcoreinfo entry.

  * Fix to determine the ARM64 kernel's "vabits_actual" value from the ELF
    header of a dumpfile created with the "snap.so" extension module.

  * Fix two typos in the examples section of the "help bt" display, which
    mistakenly show "bf -f" and "bf -FF" instead of "bt -f" and "bt -FF".

  * Similar to ARM64, the X86_64, PPC64 and S390x architectures will use the
    exported value of MAX_PHYSMEM_BITS from the vmcoreinfo data as the
    preferred method if it is available.

  * If an S390X kernel crashes before vmcoreinfo initialization, there is no
    way to extract the KASLR offset for such early dumps.  In a new S390X
    kernel patch, the KASLR offset will be stored in the lowcore memory during
    early boot and then overwritten after vmcoreinfo is initialized.  This
    patch allows crash to identify the KASLR offset that is stored in the
    lowcore memory.

  * Fix for a crash-7.2.7 regression that determined the value of the ARM64
    kernel SECTION_SIZE_BITS by reading the in-kernel configuration data if
    there is no VMCOREINFO data available.  In that case, without the patch, a
    double-free exception may occur.

  * Fix for segmentation violation if the gdb_readmem_callback() function gets
    called from other than a crash command, such as from an epython command
    from the mypkdump.so extension module.

  * Fix for the "dis -s" option when running against kernels that have been
    configured with CONFIG_RANDOMIZE_BASE=y (KASLR).  Without the patch, the
    command option indicates that the FILE and LINE numbers are "(unknown)",
    and that "source code is not available".

  * Fix for newer Xen hypervisors, which fail during initialization with the
    error message "crash: cannot resolve init_tss".  This is caused by a
    change in the Xen hypervisor with commit 78884406256, from
    4.12.0-rc5-763-g7888440625.  In that patch the tss_struct structure was
    renamed to tss64 and the tss_page structure was introduced, which contains
    a single tss64.  Now tss information is accessible via the symbol
    "per_cpu__tss_page".

  * When accessing the ARM64 kernel's "crash_notes" array, continue to read
    the per-cpu NT_PRSTATUS note contents if an invalid note is encountered.
    Without the patch, if an invalid note is found, all other notes were
    ignored, and subsequent "bt" attempts on the active tasks would fail.

  * When accessing the 32-bit ARM kernel's "crash_notes" array, continue to
    read the per-cpu NT_PRSTATUS note contents if an invalid note is
    encountered.  Without the patch, if an invalid note is found, all other
    notes were ignored, and subsequent "bt" attempts on the active tasks would
    fail.

  * Fix for the "log -a" option.  The kernel's sk_buff.len field is a 32-bit
    unsigned int, but crash was reading its 32-bit value into a 64-bit
    unsigned long stack variable.  All extra bits that pre-existed in the
    upper 32-bits of the stack variable were passed along as part of a buffer
    size request; if the upper 32-bit bits were non-zero, then the command
    would fail with a dump of the internal buffer allocation stats followed by
    the message "log: cannot allocate any more memory!".

  * When determining the ARM64 kernel's "vabits_actual" value by reading the
    new TCR_EL1.T1SZ vmcoreinfo entry, display its value during session
    initialization only when invoking crash with "-d1" or larger -d debug
    value.

  * Update copyright to 2020 in crash version output.

  * Fix for ARM64 when running against Linux 5.5-rc1 and later kernels that
    contain commit b6e43c0e3129ffe87e65c85f20fcbdf0eb86fba0, titled "arm64:
    remove __exception annotations".  Without the patch, the ARM64 crash
    session fails during initialization with the error message "crash: cannot
    resolve __exception_text_start".

  * Fix for support of ELF format kdump vmcores from S390X KASLR kernels.
    Without the patch, the crash session fails during initialization with the
    error message "crash: vmlinux and vmcore do not match!".

  * Fix for support of S390X standalone dumpfiles and LKCD dumpfiles that were
    taken from S390X KASLR kernels.

  * Rework the previous patch for support of S390X standalone dumpfiles and
    LKCD dumpfiles that were taken from S390X KASLR kernels to avoid calling
    an s390x-specific function from generic code.

  * Fix for a gcc-10 compilation error.  Without the patch, the build of the
    crash library fails with a stream of error messages indicating "multiple
    definition of 'diskdump_flags'"

 -- Troy Heber <troyh@debian.org>  Tue, 11 Feb 2020 19:19:46 -0700

crash (7.2.7-1) UNRELEASED; urgency=medium

  * Document the "-N", "-g" and "-z" options in the "help" command's help
    page.

  * Fix for a crash-7.2.6 regression to the "p" command.  Without the patch, a
    gdb pass-through command construct such as: p ((struct zone
    *)0xffff901e3ffda000)->min_slab_pages gets parsed incorrectly, and the "-"
    is mistaken for an argument option, and each of the subsequent characters
    are marked as an "invalid option".

  * Export the get_mount_list() and get_dump_level() functions in defs.h for
    use by extension modules.

  * Change the gating of a debug message in the do_xarray_dump_cb() function
    from CRASHDEBUG(0) to CRASHDEBUG(1).  Without the patch, users of the
    XArray callback functionality may see messages of the sort "entry has
    XARRAY_TAG_MASK bits set: 239ab0024001" without setting a debug number.

  * Fix for Linux 5.2 and later x86_64 kernels that contain kernel commit
    e6401c13093173aad709a5c6de00cf8d692ee786, titled "x86/irq/64: Split the
    IRQ stack into its own".  Without the patch, the per-cpu IRQ stack
    addresses cannot be determined, and as a result backtraces that utilize an
    IRQ stack will fail.

  * Fix to allow live system analysis of s390x kernels that have been
    configured with CONFIG_RANDOMIZE_BASE=y (KASLR).  Without the patch, the
    "--kaslr=<offset>" command line option is required.

  * Fix for Linux 5.2 and later x86_64 kernels that contain kernel commit
    019b17b3ffe48100e52f609ca1c6ed6e5a40cba1, titled "x86/exceptions: Add
    structs for exception stacks".  Without the patch, the exception stack
    sizes cannot be determined, and as a result backtraces that initiate from
    an exception stack will fail with error messages indicating "bt: invalid
    kernel virtual address: <address> type: stack contents" and then "bt: read
    of stack at <address> failed".

  * Two fixes for the "sys -c" option, one that significantly shortens the
    time consumed by the option, and a second fix that addresses occasional
    situations where the file and line number data are not displayed.

  * Fix for a signed/unsigned comparison bug in vmcoreinfo_read_string() which
    could lead to a segmentation violation in the highly unlikely event of a
    zero length or severely truncated VMCOREINFO note.

  * Fix for the determination of the ARM64 "kimage_voffset" value in Linux 4.6
    and later kernels if an ELF format dumpfile: (1) does not contain its
    value in a VMCOREINFO note, and (2) if the kernel image was loaded at a
    higher address than the system's physical base address.  This may happen,
    for example, when analyzing a dynamically-created ramdump-to-ELF dumpfile.

  * Fix for Linux 4.16 and later ARM64 kernels that contain kernel commit
    fa2a8445b1d3810c52f2a6b3a006456bd1aacb7e, titled "arm64: allow ID map to
    be extended to 52 bits", and which have been configured with both
    CONFIG_DEVMEM=y and CONFIG_STRICT_DEVMEM=y.  Without the patch, an
    inconsequential error message indicating "crash: read error: kernel
    virtual address: <address> type: idmap_ptrs_per_pgd" is displayed during
    initialization.

  * Introduction of a new "bt -p" option that generates a backtrace of the
    panic task, regardless of the current context.  This option is only
    applicable when running against dumpfiles in which the panic task is
    known.

  * When the gdb-7.6.patch file is updated in an existing source tree, it gets
    re-applied during the next build using "patch -N --fuzz=0", which ignores
    patches that have already been applied.  However, if a gdb file has been
    modified multiple times, the secondary patching may fail to recognize that
    a given patch has been previously applied, and will attempt to re-apply
    it.  To prevent any uninintended consequences, the gdb-7.6.patch file will
    also act as a shell script invoked by the Makefile, which restores any
    selected gdb file to its original state prior to all secondary patch
    applications.

  * As an addendum to the previous patch for updating the gdb-7.6.patch in an
    existing pre-built source tree, when rebuilding for the ppc64
    architecture, do not restore the selected gdb files.  This is because the
    gdb-7.6-ppc64le-support.patch will have modified the selected files during
    the initial build.

  * Extend the "timer" command with a new "TTE" column that displays the
    remaining time in jiffies until the expiration of a timer entry, and where
    a negative value displays the number of jiffies that have elapsed since a
    timer has expired.

  * Fix for a "warning: cast to pointer from integer of different size
    [-Wint-to-pointer-cast]" compiler message generated by the previous
    "timer" patch when compiling kernel.c on 32-bit architectures.

  * Fix to the x86_64 "--machdep phys_base=<value>" command line option to
    allow the use of a negative decimal number as the value.  Without the
    patch, only the hexadecimal representation of the value would be accepted.

  * Introduction of a new "rd -R" option, which will display memory in reverse
    order.  Memory will be displayed up to and including the address argument,
    which requires that the count argument be greater than 1 in order to
    display memory before the specified address.

  * Add support for the "count" argument to be used in conjunction with the
    "dis -r" and "dis -f" reverse/forward modes of operation.  In reverse
    mode, the specified "count" number of instructions leading up to and
    including the target address will be displayed.  In forward mode, the
    display will be limited to "count" instructions.  Without the patch, using
    a count argument in either mode generates a "count argument ignored"
    message, and the command proceeds as if it had not been entered.

  * Fix a memory leak in the previous "dis" commit.

  * Implemented a new "error" environment variable that sets the destination
    of error messages.  It can be set to either: "default": error messages are
    always displayed on the console; if the output of a command is piped to an
    external command or redirected to a file, the error messages are also sent
    to the pipe or file.  "redirect": if the output of a command is piped to
    an external command or redirected to a file, error messages are only sent
    to the pipe or file; otherwise they are displayed on the console.
    "filename": error messages are only sent to the specified filename; they
    are not displayed on the console and are not sent to a pipe or file.

  * Fix for the "kmem -n" option on Linux 5.3-rc1 and later kernels that
    contain commit 326e1b8f83a4318b09033ef754f40c785aed5e68, titled
    "mm/sparsemem: introduce a SECTION_IS_EARLY flag".  Without the patch,
    mem_map addresses containing the flag in bit 3 incorrectly show it as part
    of the virtual address; with the patch, the option displays the new "E"
    state flag.

  * Fix for the "timer" command in RHEL7.6 and later RHEL7 kernels.  Without
    the patch, the command emits extra faulty timer entries because the
    tvec_root.vec[] and tvec.vec[] arrays are tracked using hlist_head
    structures where list_head structures should be used.

  * crash-7.2.4 commit 6596f1121b added a "list -B" option to allow more
    efficient enumeration of longer lists.  There is a small bug with this
    option where it may incorrectly flag a loop length of "0" on list of
    length 1, indicating "list: loop detected, loop length: 0".  Since it is
    impossible to have a loop of length 0, the erroneous message can be
    prevented by ensuring the list count is non-zero.

  * Create the specified installation directory if it does not exist.  Without
    the patch, the Makefile's "make install" target will fail if the
    INSTALLDIR and/or DESTDIR macros resolve to a non-existent directory.

  * Fix for the internal caching of the kernel's mem_map array of page
    structures.  Without the patch, in rare circumstances, commands such as
    "kmem -p" may erroneously receive zero-filled page structures.

  * Fix to prevent a potential segmentation violation when accessing the
    compressed configuration data contained in kernels that are configured
    with CONFIG_IKCONFIG.

  * Determine the ARM64 SECTION_SIZE_BITS value using the following order of
    precedence: (1) from the VMCOREINFO data if it exists (2) from the
    in-kernel configuration data if it exists (3) the default value

 -- Troy Heber <troyh@debian.org>  Tue, 11 Feb 2020 19:19:28 -0700

crash (7.2.6-1ubuntu4) focal; urgency=medium

  * No-change rebuild with fixed binutils on arm64.

 -- Matthias Klose <doko@ubuntu.com>  Sat, 08 Feb 2020 10:57:37 +0000

crash (7.2.6-1ubuntu3) focal; urgency=medium

  * Rebuild with updated binutils, fixing an "illegal insruction" crash
    on arm64. LP: #1859226.
  * Update the maintainer field for Ubuntu.

 -- dann frazier <dannf@ubuntu.com>  Sat, 11 Jan 2020 09:36:27 -0700

crash (7.2.6-1ubuntu2) focal; urgency=medium

  * Fix logic issue in "live" autopkgtest introduced in the last upload.

 -- dann frazier <dannf@ubuntu.com>  Thu, 09 Jan 2020 19:24:17 -0700

crash (7.2.6-1ubuntu1) focal; urgency=medium

  * If the "live" autopkgtest fails with a recommendation to try
    /proc/kcore instead of the default, attempt that before failing
    the test. LP: #1858958.

 -- dann frazier <dannf@ubuntu.com>  Thu, 09 Jan 2020 14:21:45 -0700

crash (7.2.6-1build1) eoan; urgency=medium

  * No-change upload with strops.h and sys/strops.h removed in glibc.

 -- Matthias Klose <doko@ubuntu.com>  Thu, 05 Sep 2019 10:47:07 +0000

crash (7.2.6-1) unstable; urgency=medium

  * Two fixes for the Xen hypervisor; the first fixes a bug seen with Xen
    4.11.0 during initialization, which fails with the error message "crash:
    invalid kernel virtual address: <address> type: fill_pcpu_struct",
    followed by "WARNING: cannot fill pcpu_struct" and "crash: cannot read
    cpu_info".  The second fix prevents a segmentation violation associated
    with a crash-7.1.1 commit that addressed the Xen 4.5.0 hypervisor symbol
    name change from "dom0" to "hardware_domain".

  * Fix for Linux 4.20 and later x86_64 kernels which are NOT configured with
    CONFIG_RANDOMIZE_BASE.  Linux 4.20 introduced kernel commit
    d52888aa2753e3063a9d3a0c9f72f94aa9809c15, titled "x86/mm: Move LDT remap
    out of KASLR region on 5-level paging", which modified the 4-level and
    5-level paging PAGE_OFFSET values.  Without this patch, the crash session
    fails during initialization with the error message "crash: read error:
    kernel virtual address: <address>  type: tss_struct ist array".  For
    kernels prior to Linux 4.20.0 which have backports of the kernel commit,
    the kernel's PAGE_OFFSET value must be manually specified via the command
    line option "--machdep page_offset=ffff888000000000" for kernels with
    4-level page tables, or "--machdep page_offset=ff11000000000000" for
    kernels with 5-level paging.  (or alternatively the shorter version "-m
    page_offset=<address>" may be used).  The command line option requirement

  * Fix for the "p" command if the expression contains more than one opening
    parenthesis character and a minus/dash sign.  Without the patch, the
    minus/dash sign will get dropped from the command prior to it being passed
    on to gdb for evaluation, and the command will fail with the message "p:
    gdb request failed: <expression>", where the <expression> string will not

  * Fix for the internal parse_line() utility function to account for embedded
    sets of parentheses, which may be used for expressions that are passed to
    gdb by the "p" command.  Without the patch, expressions containing
    embedded sets of parentheses are broken up into multiple argument tokens
    instead of just one.  The previous commit has been reverted by this one.

  * First phase of support for ARM64 kernels that are configured with
    CONFIG_ARM64_USER_VA_BITS_52, which causes the PTRS_PER_PGD count to
    increase from 64 to 1024.  Without the patch, "WARNING: cannot access
    vmalloc'd module memory" will be displayed during session initialization,
    and the translation of any mapped kernel virtual address that requires a
    page table walk will fail, leading to a myriad of other errors.

  * Support for configurable CONFIG_ARM64_PA_BITS values introduced in kernel
    commit 982aa7c5f0861bf56b2412ca341a13f44c238ba4, titled "arm64: add
    kconfig symbol to configure physical address size".  Without the patch, it
    is impossible to determine the value of CONFIG_ARM64_PA_BITS is, and will
    require a new MAX_PHYSMEM_BITS vmcoreinfo entry to be exported.  This

  * For live system analysis where there is no vmcoreinfo ELF note attached to
    /proc/kcore, or for dumpfile analysis where there is no vmcoreinfo ELF
    note attached to the dumpfile, this patch sets the internal
    pc->read_vmcoreinfo() function to a new plugin function that reads the
    data directly from the live kernel or dumpfile.  Because the function is
    set much later during initialization than if the ELF note is attached to
    /proc/kcore or the dumpfile, it may not be available during very early

  * Fix for Linux 4.14.84 and later 4.14-based x86_64 kernels which are NOT
    configured with CONFIG_RANDOMIZE_BASE and have backported kernel commit
    d52888aa2753e3063a9d3a0c9f72f94aa9809c15, titled "x86/mm: Move LDT remap
    out of KASLR region on 5-level paging", which modified the 4-level and
    5-level paging PAGE_OFFSET values.  Without this patch, the crash session
    fails during initialization with the error message "crash: read error:
    kernel virtual address: <address>  type: tss_struct ist array".

  * Fix for determining the x86_64 "phys_base" value in dumpfiles created by
    the KVM "virsh dump" facility if the kernel is KASLR-enabled and does not
    have the phys_base value stored in vmcoreinfo data.  Without the patch,
    the message "WARNING: cannot determine physical base address: defaulting
    to 0" is displayed, and the crash session fails to initialize.

  * 32-bit ARM kernels built with the Thumb-2 instruction set utilize the R7
    register instead of FP for unwinding stacks using the DWARF unwinder.  On
    those kernels, without the patch, the "bt" command only shows the task

  * Fix for the "kmem -z" option on Linux 5.0 and later kernels that contain
    commit a921444382b49cc7fdeca3fba3e278bc09484a27, titled "mm: move zone
    watermark accesses behind an accessor".  Without the patch, the command
    fails with the error message "kmem: invalid (optional) structure member
    offsets: zone_pages_min or zone_struct_pages_min".

  * Fix for the "kmem -i" option on Linux 5.0 and later kernels that contain
    commit ca79b0c211af63fa3276f0e3fd7dd9ada2439839 titled "mm: convert
    totalram_pages and totalhigh_pages variables to atomic".  Without the
    patch, the command prints some incorrect values, and besides does not
    print high/low memory information on kernels which are configured with

  * Fix for the display of kernel module symbol types by the "sym" command in
    Linux 5.0 and later kernels if the module debuginfo data has not been
    loaded into the crash session.  The st_info member of the Elf32_Sym or
    Elf64_Sym structures has changed so as to not contain ASCII symbol type
    characters, and as a result the "sym" command will show unprintable data
    as the symbol type.  With the patch, only text types ("t" or "T") will be

  * First phase of support of the upcoming ARM64 kernel memory map changes to
    support 52-bit kernel virtual addressing, which allows the configuration
    of CONFIG_ARM64_VA_BITS to be 52, but where the actual number of VA bits
    may be downgraded during boot depending upon the hardware capability.
    This phase is only applicable for live system analysis.

  * Fix for the "dis <function>" option with kernel module text symbols on
    Linux 5.0 and later kernels.  Without the patch, the disassembly may stop
    prematurely or extend into the next function because the st_size member of
    the Elf32_Sym or Elf64_Sym text symbol structures can no longer be used as

  * Commit dd12805ed1db7 in the linux-next kernel repository, titled "XArray:
    Remove radix tree compatibility", changes the definition of
    "radix_tree_root" back to be a struct.  However, the content of the new
    structure differs from the original structure, so without the patch,
    current linux-next kernels fail during initialization with the error
    message "radix trees do not exist or have changed their format".  Because
    the new "radix_tree_root" and "xarray" structures have nearly the same
    layout, the existing functionality for XArrays can be reused.

  * Fixes for the "trace.so" extension module: (1) The reader_page can be
    empty if it was never read, do not record it if it is empty. Better yet,
    do not record any page that is empty.  The struct buffer_page "real_end"
    is not available in older kernels, so it needs to be tested if it exists
    before we can use it.  (2) In newer kernels, the sp->type of kernel module
    symbols does not contain the symbol type character unless the module's
    debuginfo data has been loaded into the crash session.  Writing a garbage
    type to the kallsyms file for trace-cmd to read causes it to crash, so
    just always write an 'm'.  (3) Add the "trace dump -t <trace.dat>" option

  * Fix to find the kernel configuration data in Linux 5.1 kernels containing
    commit 13610aa908dcfce77135bb799c0a10d0172da6ba, titled "kernel/configs:
    use .incbin directive to embed config_data.gz".  Without the patch, new
    kernels configured with CONFIG_IKCONFIG_PROC will display "WARNING: could
    not find MAGIC_START!" during session initialization, and also when

  * Fix for the PPC64 "bt" command running against kernels that are configured
    with CONFIG_THREAD_INFO_IN_TASK.  Without the patch, the "bt" command
    fails with the message "bt: invalid/stale stack pointer for this task:

  * Fix for the "files -d <dentry>" option if the dentry.d_inode pointer is
    NULL.  Without the patch, the command output does not display the

  * When the is_s390_dump() function is called to determine whether a file is
    an s390 dumpfile, it currently presumes that the fopen() call always
    works, and then tries to read it with using a NULL file pointer.  Change
    it to verify that the fopen() was successful, and if not, print an error
    message as is done with the other dumpfile type verifier functions.

  * Implement support for ARM64 kernels that are configured with:
    CONFIG_ARM64_PA_BITS=52 CONFIG_ARM64_64K_PAGES CONFIG_PGTABLE_LEVELS=3 and
    that run on a host containing physical memory that utilizes any bit in the
    uppermost 4 bits of the 52-bit physical address range.

  * Extension of the "snap.so" extension module to pass a second
    architecture-specific value in the ELF header; its initial use is for
    support of the upcoming ARM64 52-bit kernel virtual address space by

  * Apply initial changes to support kernel address space layout randomization
    (KASLR) for s390X.  This is the minimal patch-set required to process
    s390x dumps for the kernels configured with CONFIG_RANDOMIZE_BASE, and to
    accept the "--kaslr" command line option.  Only dumpfiles whose headers

  * Fix for the "dev -[dD]" options on Linux 5.1-rc1 and later kernels that
    contain commit 570d0200123fb4f809aa2f6226e93a458d664d70, titled "driver
    core: move device->knode_class to device_private".  Without the patch, the
    command options fail with the error message "dev: invalid structure member

  * Linux 4.18 kernels introduced a new CONFIG_PROC_VMCORE_DEVICE_DUMP
    configuration in commit 2724273e8fd00b512596a77ee063f49b25f36507, titled
    "vmcore: add API to collect hardware dump in second kernel", in which
    device drivers may collect a device specific snapshot of the
    hardware/firmware state of their underlying devices, and export the data
    as a kdump ELF note with type NT_VMCOREDD.  This patch recognizes the new
    ELF note(s) in both ELF and compressed kdump vmcore dumpfiles.  The "help
    -[nD]" option shows basic information about each note, and two new "dev"
    command options have been introduced.  The "dev -V" option displays an
    indexed list of each note, showing the device name, the dumpfile offset,
    and the size of each note.  The "dev -v index [file]" option either dumps
    the contents of a note to the display screen in a human-readable format,
    or copies the note data directly to a specified file.

  * If the kernel's "vmap_area_list" doubly-linked list is corrupt such that
    it does not link back to the global list_head, commands that require
    information regarding the range of virtually-mapped kernel addresses will
    display a generic list-handling error message such as "kmem: invalid list
    entry: 0", and the command will typically fail to fully complete.
    However, without the patch, there will also be "WARNING: malloc/free
    mismatch (29/30)" messages that get displayed after every subsequent
    command.  This patch prevents the mismatch messages, and also adds an
    additional error message indicating "WARNING: invalid/corrupt
    vmap_area_list" to further clarify the generic list-handling error

  * Fix for the "dev" help page to remove the unused -r option letter.

  * If a duplicate list entry is encountered when using the "list -B" Brent
    algorithm, change the list loop length value from hexadecimal to decimal.

  * Update the README file to indicate the capability of building an x86_64
    crash binary with "make target=PPC64", which can be used to analyze

  * Fix for hybrid kernels that have backported support for the Xarray
    facility while allowing subsystems to continue to use radix trees.
    Without the patch, the crash session fails during initialization with the
    message "crash: xarray facility does not exist or has changed its format".

 -- Troy Heber <troyh@debian.org>  Mon, 15 Jul 2019 08:20:49 -0600

# Older entries have been removed from this changelog.
# To read the complete changelog use `apt changelog crash`.
