[Crash-utility] [ANNOUNCE] crash gcore command, version 1.3.0-rc2 is released

This is the release of crash gcore command, version 1.3.0-rc2. The version 1.3.0 is going to newly add ARM64 support, including compat mode, and PPC64 support, and the purpose of this serise of rc version releases is for verification by other architecture maintainers. Please give me a verfication result as a reply to this mail. The remaining changes are all bugfixes. # The changes include those that appeared in v1.3.0-rc. ChangeLog: [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. (anderson(a)redhat.com) - Add ARM64 compat mode support. This allows gcore to create corefiles for tasks running in 32-bit compatible mode on ARM64. (weishu(a)marvell.com) - Add PPC64 support. This includes both big-endian and little-endian formats. (mtoman(a)redhat.com, anderson(a)redhat.com) [bugfixes] - 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 <qiaowei.ren(a)intel.com&gt; 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 <qiaowei.ren(a)intel.com&gt; Link: http://lkml.kernel.org/r/9E0BE1322F2F2246BD820DA9FC397ADE014A6115@SHSMSX1... Signed-off-by: H. Peter Anvin <hpa(a)linux.intel.com&gt; Without this patch, for vmcores whose kernel versions are v3.14 or later, gcore results in segmentation fault due to a buffer overrite of NT_FPREGSET. (d.hatayama(a)jp.fujitsu.com) - 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. (anderson(a)redhat.com) - 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. (weishu(a)marvell.com) - 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 dump. (d.hatayama(a)jp.fujitsu.com) - Add new member offset initialization for struct nsproxy::pid_ns_for_children. In upstream, the following patch renamed struct nsproxy::pid_ns into struct nsproxy::pid_ns_for_children. $ git log -1 c2b1df2e commit c2b1df2eb42978073ec27c99cc199d20ae48b849 Author: Andy Lutomirski <luto(a)amacapital.net&gt; 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 <luto(a)amacapital.net&gt; Reviewed-by: "Eric W. Biederman" <ebiederm(a)xmission.com&gt; Signed-off-by: David S. Miller <davem(a)davemloft.net&gt; Without this fix, gcore exited abnormally at its initialization part and so core file is never generated. (d.hatayama(a)jp.fujitsu.com) - 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. (d.hatayama(a)jp.fujitsu.com) MD5 CheckSum: $ md5sum ./crash-gcore-command-1.3.0-rc2.tar.gz 07757d2ee044b19cac6b652de0d757fc ./crash-gcore-command-1.3.0-rc2.tar.gz -- Thanks. HATAYAMA, Daisuke