----- Original Message -----
> 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.
Hello Daisuke,
Because Red Hat no longer support 32-bit x86 in RHEL7, I never bothered to
test it. However, in our build system, the 32-bit x86 package does still
get built. And as luck would have it, it fails to build, because the
user_i387_struct is not defined for X86:
# make -f gcore.mk
make[1]: Entering directory `/root/crash-gcore-command-1.3.0'
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_coredump.o libgcore/gcore_coredump.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_coredump_table.o libgcore/gcore_coredump_table.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_dumpfilter.o libgcore/gcore_dumpfilter.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_elf_struct.o libgcore/gcore_elf_struct.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_global_data.o libgcore/gcore_global_data.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_regset.o libgcore/gcore_regset.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_verbose.o libgcore/gcore_verbose.c
gcc -D_FILE_OFFSET_BITS=64 -Wall -I/usr/include/crash -I./libgcore -fPIC -DX86 -DVERSION='"1.3.0"' -DRELEASE_DATE='"4 Nov 2014"' -DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_x86.o libgcore/gcore_x86.c
libgcore/gcore_x86.c: In function ‘gcore_x86_get_thread_struct_fpu_thread_xstate_size’:
libgcore/gcore_x86.c:580: error: invalid application of ‘sizeof’ to incomplete type ‘struct user_i387_struct’
make[1]: *** [libgcore/gcore_x86.o] Error 1
make[1]: Leaving directory `/root/crash-gcore-command-1.3.0'
make: *** [gcore.so] Error 2
#
As I understand it, it can be fixed like so:
--- crash-gcore-command-1.3.0/libgcore/gcore_x86.c.orig
+++ crash-gcore-command-1.3.0/libgcore/gcore_x86.c
@@ -577,7 +577,11 @@ static ulong gcore_x86_get_thread_struct
static ulong gcore_x86_get_thread_struct_fpu_thread_xstate_size(void)
{
+#ifdef X86
+ return sizeof(struct user_i387_ia32_struct);
+#else
return sizeof(struct user_i387_struct);
+#endif
}
static ulong gcore_x86_get_thread_struct_thread_xstate(struct task_context *tc)
But how do you want to handle this?
Dave
>
> The remaining changes are all bugfixes.
>
> # The ChangeLog includes those that appeared at each rc release.
>
> 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@xxxxxxxxxx)
>
> - Add ARM64 compat mode support. This allows gcore to create
> corefiles for tasks running in 32-bit compatible mode on ARM64.
> (weishu@xxxxxxxxxxx)
>
> - Add PPC64 support. This includes both big-endian and little-endian
> formats.
> (mtoman@xxxxxxxxxx, anderson@xxxxxxxxxx)
>
> [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@xxxxxxxxx>
> 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@xxxxxxxxx>
> Link:
> http://lkml.kernel.org/r/9E0BE1322F2F2246BD820DA9FC397ADE014A6115@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxx)
>
> - 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@xxxxxxxxxx)
>
> - 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@xxxxxxxxxxx)
>
> - 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@xxxxxxxxxxxxxx)
>
> - 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@xxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxx>
> Reviewed-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>
> Without this fix, gcore exited abnormally at its initialization
> part and so core file is never generated.
> (d.hatayama@xxxxxxxxxxxxxx)
>
> - 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@xxxxxxxxxxxxxx)
>
> MD5 CheckSum:
>
> $ md5sum ./crash-gcore-command-1.3.0.tar.gz
> d530b7211793f1541a0da5968a305f4d ./crash-gcore-command-1.3.0.tar.gz
>
> --
> Thanks.
> HATAYAMA, Daisuke
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
