This is the release of crash gcore command, version 1.5.0.

The aim of this release is mainly to support v4.18 and newer kernels.


  - Fix the issue that special vmas such as vdso and vsyscall are not
    saved in a produced core file due to the commit
    78d683e838a60ec4ba4591cca4364cba84a9e626 titled "mm, fs: Add
    vm_ops->name as an alternative to arch_vma_name" and merged at
    v3.15-rc5, which replaced the way of naming special vma such as
    vdso and vsyscall.

  - Fix the issue that no NT_PRFPREG is collected due to repeated
    changes on the x86 FPU code in the upstream kernel. Note that
    although the issue that no NT_PRFPREG is collected is (probably
    temporarily) fixed, its content would be useless in most cases
    since the FPU registers to be saved in NT_PRFPREG are now read
    dynamically when a core file is created.

  - Change the logic of restoring general-purpose registers at
    interrupt contexts according to the commit
    ff467594f2a4be01a0fa5e9ffc223fa930d232dd titled "x86/asm/entry/64:
    Save all regs on interrupt entry" and merged at v4.2-rc2 where all
    the registers including callee-saved registers are saved on
    interrupt entry. Thus, we don't have to try to restore
    callee-saved registers in the function frames. I'm very happy.

  - Address the change of vsyscall logic that vsyscall page is not
    mapped in user-space if vsyscall=none is configured in the kernel
    command-line parameters by the commit
    87983c66bc02c9cd8e4a42e7924435145d52bb13 titled "x86_64, vsyscall:
    Turn vsyscalls all the way off when vsyscall==none" and merged at

  - Fix NULL pointer dereference caused by the removal of old_rsp
    symbol by the commit 9854dd74c3f6af8d9d527de86c6074b7ed0495f1
    titled "x86: fix NULL pointer dereference caused by the removal of
    old_rsp" and merged at v4.0-rc3. But the commit simplifies how to
    save old_rsp and now it is saved in the bottom of kernel stack as
    part of a pt_regs structure object. Hence this also simplifies
    gcore's register restoration logic.

This is the release of crash gcore command, version 1.4.0.


 - Add MIPS support.

This is the release of crash gcore command, version 1.3.2.

This release includes a fix for the issue reported by Eric Ewanco and
some bugfixes found on 4.8 kernel.


 - Fix a Segmentation fault issue caused by NULL pointer dereference
   due to a renaming of symbol old_rsp to rsp_scratch at the commit
   ac9af4983e77765a642b5a21086bc1fdc55418c4, triggered by the commit
   263042e4630a85e856b4a8cd72f28dab33ef4741 that changes a saving
   location of user stack pointer in syscall path from
   thread_struct::usersp to pt_regs at the bottom of kernel stack.

 - Fix a runtime error with an error message "invalid structure member
   offset: thread_struct_fs" due to a renaming of fs/gs members of
   thread_struct on x86 to fsbase/gsbase. Without this fix, gcore
   exits abnormally without producing any core file on this issue.

 - Fix a Segmentation fault issue caused by NULL pointer dereference
   due to buffer overrun during a copy of floating pointer register
   values onto a buffer allocated on the stack where detected size of
   the copied floating register values are too large, larger than
   prepared buffer size.  This fix makes the copying floating pointer
   register values more fail safe to make sure at least that such
   detection of wrong data structure size doesn't make gcore process
   abnormally terminate.

This is the release of crash gcore command, version 1.3.1.

This release only aims at fixing building failure on x86 I overlooked
at the release of version 1.3.0.



 - Fix building failure on x86 caused by a static reference to type
   struct user_i387_struct that is used on x86_64 only. This reference
   was introduced at v1.3.0 by the bugfix of segfault issue due to a
   buffer overwrite of NT_FPREGSET. Correct one on x86 is struct
   user_i387_ia32_struct, and we use it now.

This is the release of crash gcore command, version 1.3.0.

This release newly adds ARM64 and PPC64 supports, thanks to respective
maintainers for their development of patch sets and verifications at
each rc release.

The remaining changes are all bugfixes.

# The ChangeLog includes those that appeared at each rc release.


[new features]

 - Add ARM64 support. In addition to native ARM64 build, like crash
   utility, we can build x86_64 executable of crash gcore command for
   ARM64 crash dump by make target=ARM64, just like crash utility.

 - Add ARM64 compat mode support. This allows gcore to create
   corefiles for tasks running in 32-bit compatible mode on ARM64.

 - Add PPC64 support. This includes both big-endian and little-endian


 - Correct a read buffer size for NT_FPREGSET as sizeof(struct
   user_i387_struct). So far we had used sizeof(union thread_xstate)
   falsely as a read buffer size but it had accidentally been equal to
   sizeof(struct user_i387_struct). However, the following patch
   extended union thread_xstate and sizeof(union thread_xstate) became
   larger than sizeof(struct user_i387_struct):

    commit e7d820a5e549b3eb6c3f9467507566565646a669
    Author: Qiaowei Ren <>
    Date:   Thu Dec 5 17:15:34 2013 +0800

        x86, xsave: Support eager-only xsave features, add MPX support

        Some features, like Intel MPX, work only if the kernel uses eagerfpu
        model.  So we should force eagerfpu on unless the user has explicitly
        disabled it.

        Add definitions for Intel MPX and add it to the supported list.

        [ hpa: renamed XSTATE_FLEXIBLE to XSTATE_LAZY and added comments ]

        Signed-off-by: Qiaowei Ren < com>
        Signed-off-by: H. Peter Anvin <>

   Without this patch, for vmcores whose kernel versions are v3.14 or
   later, gcore results in segmentation fault due to a buffer overrite

 - Although ELF_DATA is defined in gcore_defs.h, ELFDATA2LSB is used
   directly at elf{64,32}_fill_elf_header(). There's so far been no
   problem since the exisitng supported architectures are all
   little-endian systems. Fix this to support PPC64 that uses
   little-endian format.

 - Fix a bug that registers in NT_PRSTATUS note information is
   broken. This had been since v1.2.2 when O(1) note informaiton
   collection was added. Without this fix, we can never get reliable
   register values for failure analysis.

 - Fix a bug that NT_386_IOPERM note information is not collected. So
   far, ioperm_get() had always returned 1. As a result, NT_386_IOPERM
   note information had never been not included in a generated core
   file even if it is available for a given task on a given crash

 - Add new member offset initialization for struct
   nsproxy::pid_ns_for_children. In upstream, the following patch
   renamed struct nsproxy::pid_ns into struct

    $ git log -1 c2b1df2e
    commit c2b1df2eb42978073ec27c99cc199d20ae48b849
    Author: Andy Lutomirski <>
    Date:   Thu Aug 22 11:39:16 2013 -0700

        Rename nsproxy.pid_ns to nsproxy.pid_ns_for_children

        nsproxy.pid_ns is *not* the task's pid namespace. The name
        should clarify that.

        This makes it more obvious that setns on a pid namespace is weird --
        it won't change the pid namespace shown in procfs.

        Signed-off-by: Andy Lutomirski <>
        Reviewed-by: "Eric W. Biederman" <>
        Signed-off-by: David S. Miller <>

   Without this fix, gcore exited abnormally at its initialization
   part and so core file is never generated.

 - Fix a bug that a wrong way of checking return value of
   fopen(). fopen() returns NULL in case of error, but gcore had seen
   it as returning a minus integer. As a result, gcore continues
   execution after the check even in case of error and then exits
   abnormally at the first call of fwrite() with the broken file
   pointer gcore failed to open.

   From users' viewpoint, we face this bug when trying to overwrite an
   existing corefile with more priviledged permission and resulting in
   EPERM failure.

This is the release of crash gcore command, version 1.2.2.


 - Now gcore collects and writes ELF note segments in O(1) memory
   consumption with regard to the number of threads. The implementation
   so far had created ELF note segments for all the threads as a list
   at the same time, and so memory consumption had grown in proportion
   to the number of threads. In contrast, new implementation writes
   ELF note segments one by one. Without this change, gcore could fail
   abnormally if specified process consists of threads more than tens of
   thousands, with the message: "gcore: cannot allocate any more memory!".

 - Fix the address of vdso virtual address in x86_64 compat mode by using
   fixed VDSO_HIGH_BASE, not by vma->vm_mm->context.vdso. Without this
   fix, access to vdso page fails in x86_64 compat mode and vdso page
   fails to be collected in generated process core dump.

 - Tested on RHEL5.10.

This is the release of crash gcore command, version 1.2.1.


 - Fix failure of coredump at accessing memory for VSYSCALL page due
   to wrong conversion of uvtop which wrongly treats address
   VSYSCALL_START as belongs to kernel direct mapping region. This fix
   executes uvtop in verbose mode to make it always paging and
   retrieves the correct physical address from its output. Without
   this fix, VSYSCALL page fails to be collected and core dump process
   is aborted; though VSYSCALL page is done in the last so allmost all
   corefile is already generated.

 - Skip page-faulted pages by lseek() rather than writing zero-filled
   pages. By this, generated core file has holes in the corresponding
   positions for each page-faulted pages if filesystem supports sparse
   files. This is highly useful when the target process has huge
   virtual memory space such as qemu process that has huge physical
   memory of KVM guest machine.

 - Fix the bug that filter for hugepage shared/private memory can
   depend on flags other than HP or HS flags. This was introduced at
   the introduction of VM_DONTDUMP where VM_RESERVED flag was
   removed. At the time, there was a check to see if VM_REESRVED flag
   was set after a check to see if VM_HUGETLB. But the latter check
   was not changed when the former check was removed.

This is the release of crash gcore command, version 1.2.0.


 - Add new dump filter level for memory advised with MADV_DONTDUMP.
   By specifying this new dump level, gcore generates core dump
   including the ranges with VM_DONTDUMP flag. The new dump level is
   not specified at default. See help gcore, in particular, part of -f
   option forcusing on DD.

 - Deal with anonymous i_nlink member of inode, caused by the kernel's
   commit a78ef704a8dd430225955f0709b22d4a6ba21deb. Without this
   patch, gcore fails and no core file is generated on the kernels of
   the commit or later.

 - Deal with removal of VM_ALWAYDUMP flag, caused by the kernel's
   commit 909af768e88867016f427264ae39d27a57b6a8ed. Without this
   change, vdso or vsyscall page is not included in core file on the
   kernels of the commit or later.

 - Deal with introduction of VM_DONTDUMP flag, on the kernel's commit
   a0f5202d695d492221dd946aafbfb3d993f6cbe0. Without this patch,
   VM_DONTDUMP flag is wrongly regarded as VM_ALWAYSFLAG flag, and the
   corresponding memory is intensinally included in a generated core

 - Deal with removal of VM_RESERVED flag, caused by the kernel's
   commit e4bffd16e615edfa42aa4f37224c3a26c6ef2436. Without this
   patch, gcore checks VM_RESERVED flag even if it is no longer
   present on given kernel.

Supported Kernels:

 * Upstream Kernels

   version  | x86  |x86_64| ARM
 -----------+------+------+----- |  --  |  --  | OK
   2.6.36   |  OK  |  OK  | --
   3.0.8    |  --  |  --  | OK
   3.6.0    |  --  |  OK  | --   (new)
   3.7-rc5  |  --  |  OK  | --   (new)

 OK : Support
 -- : Not support

 * RHEL Kernels (#1

          | x86  |     x86_64
  version |      | 64 bit ; 32 bit
    4.8   |  OK  |   OK   |   --
    5.5   |  OK  |   OK   |   OK
    5.6   |  --  |   OK   |   OK
    5.7   |  --  |   OK   |   OK
    5.8   |  --  |   OK   |   OK
    6.0   |  OK  |   OK   |   OK
    6.1   |  --  |   OK   |   OK
    6.2   |  --  |   OK   |   OK
    6.3   |  --  |   OK   |   OK      (new)

  #1) RHEL4 is based on 2.6.9 kernel,
      RHEL5 is based on 2.6.18 kernel and
      RHEL6 is based on 2.6.32 kernel.


 - Support for nested NMI handling on X86


 1) The versions signed OK are the ones I did verification. gcore
 might work well on kernel versions near the supported ones.

 2) The reason why I separate table for RHEL series and table for
 upstream series is that RHEL kernels are being made based on upstream
 kernels _plus a variety of additional patches_. So, rigorously, they
 must be thought of as differnet kernels. However, just as 1), it
 would be likely that gcore works well on vmcores for upstream kernels
 near the corresponding RHEL versions.