6:12 p.m.
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>
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>
Link:
http://lkml.kernel.org/r/9E0BE1322F2F2246BD820DA9FC397ADE014A6115@SHSMSX1...
Signed-off-by: H. Peter Anvin <hpa(a)linux.intel.com>
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>
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>
Reviewed-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
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
1:59 a.m.
New subject: [ANNOUNCE] crash gcore command version 1.3.0-rc2 is released
----- Original Message -----
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.
Hello Daisuke,
We have successfully tested the support for the ARM64 and PPC64 architectures.
Thanks very much for accepting them.
However, I have attached one small patch to the gcore.mk file that is required
for ARM64 in order to build the module in the "extensions" subdirectory
of the crash source tree.
The standalone package builds OK on an ARM64 host:
# make -f gcore.mk
make[1]: Entering directory `/root/crash-gcore-command-1.3.0-rc2'
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_coredump.o libgcore/gcore_coredump.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_coredump_table.o libgcore/gcore_coredump_table.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_dumpfilter.o libgcore/gcore_dumpfilter.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_elf_struct.o libgcore/gcore_elf_struct.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_global_data.o libgcore/gcore_global_data.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_regset.o
libgcore/gcore_regset.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_verbose.o
libgcore/gcore_verbose.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_arm64.o
libgcore/gcore_arm64.c
Make[1]: Leaving directory `/root/crash-gcore-command-1.3.0-rc2'
#
Note that the compile lines above contain -D_SYS_UCONTEXT_H=1 because
of this "(shell arch)" section of the gcore.mk file:
ifeq ($(shell arch), aarch64)
TARGET=ARM64
TARGET_CFLAGS=-D_SYS_UCONTEXT_H=1
ARCH=SUPPORTED
endif
However, when building the package from within a crash source tree in its
"extensions" subdirectory, the package fails to compile because the
-D_SYS_UCONTEXT_H=1 gets dropped. That is because the top-level Makefile
issues the make command with TARGET_CFLAGS defined on the command line,
which overrides the "(shell arch)" TARGET_CFLAGS setting in gcore.mk:
(cd extensions; make -i TARGET=ARM64 TARGET_CFLAGS="" GDB=gdb-7.6
GDB_FLAGS=-DGDB_7_6)
In order to build both standalone and from within the crash source tree,
I've modified the gcore.mk file to use a new "ARCH_CFLAGS" definition,
and added $(ARCH_CFLAGS) to both compile lines below it:
ifeq ($(shell arch), aarch64)
TARGET=ARM64
ARCH_CFLAGS=-D_SYS_UCONTEXT_H=1
ARCH=SUPPORTED
endif
Note that if the ARM64 gcore.so is compiled from an x86_64 host that
was built with "make target=ARM64", the "(shell arch), aarch64"
section
is not used (and not necessary).
Thanks,
Dave
5:09 p.m.
New subject: [ANNOUNCE] crash gcore command version 1.3.0-rc2 is released
From: Dave Anderson <anderson(a)redhat.com>
Subject: Re: [Crash-utility] [ANNOUNCE] crash gcore command version 1.3.0-rc2 is released
Date: Mon, 27 Oct 2014 13:59:04 -0400
----- Original Message -----
> 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.
Hello Daisuke,
We have successfully tested the support for the ARM64 and PPC64 architectures.
Thanks very much for accepting them.
Thanks for your verification.
However, I have attached one small patch to the gcore.mk file that is
required
for ARM64 in order to build the module in the "extensions" subdirectory
of the crash source tree.
The standalone package builds OK on an ARM64 host:
# make -f gcore.mk
make[1]: Entering directory `/root/crash-gcore-command-1.3.0-rc2'
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_coredump.o libgcore/gcore_coredump.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_coredump_table.o libgcore/gcore_coredump_table.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_dumpfilter.o libgcore/gcore_dumpfilter.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_elf_struct.o libgcore/gcore_elf_struct.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o
libgcore/gcore_global_data.o libgcore/gcore_global_data.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_regset.o
libgcore/gcore_regset.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_verbose.o
libgcore/gcore_verbose.c
gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -DARM64
-DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct 2014"'
-DPERIOD='"2010, 2011, 2012, 2013, 2014"' -c -o libgcore/gcore_arm64.o
libgcore/gcore_arm64.c
Make[1]: Leaving directory `/root/crash-gcore-command-1.3.0-rc2'
#
Note that the compile lines above contain -D_SYS_UCONTEXT_H=1 because
of this "(shell arch)" section of the gcore.mk file:
ifeq ($(shell arch), aarch64)
TARGET=ARM64
TARGET_CFLAGS=-D_SYS_UCONTEXT_H=1
ARCH=SUPPORTED
endif
However, when building the package from within a crash source tree in its
"extensions" subdirectory, the package fails to compile because the
-D_SYS_UCONTEXT_H=1 gets dropped. That is because the top-level Makefile
issues the make command with TARGET_CFLAGS defined on the command line,
which overrides the "(shell arch)" TARGET_CFLAGS setting in gcore.mk:
(cd extensions; make -i TARGET=ARM64 TARGET_CFLAGS="" GDB=gdb-7.6
GDB_FLAGS=-DGDB_7_6)
In order to build both standalone and from within the crash source tree,
I've modified the gcore.mk file to use a new "ARCH_CFLAGS" definition,
and added $(ARCH_CFLAGS) to both compile lines below it:
ifeq ($(shell arch), aarch64)
TARGET=ARM64
ARCH_CFLAGS=-D_SYS_UCONTEXT_H=1
ARCH=SUPPORTED
endif
Note that if the ARM64 gcore.so is compiled from an x86_64 host that
was built with "make target=ARM64", the "(shell arch), aarch64"
section
is not used (and not necessary).
I confirmed that after applying this patch, both make and make
target=ARM64 work fine.
If there's no other large issue, I'll release v1.3.0, not -rc3, this
weekend including this change.
--
Thanks.
HATAYAMA, Daisuke
7:43 p.m.
New subject: [ANNOUNCE] crash gcore command version 1.3.0-rc2 is released
Hi Daisuke,
I verified arm64 compat mode, it works, thanks
Best Regards,
Wei
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-
bounces(a)redhat.com] On Behalf Of HATAYAMA Daisuke
Sent: Tuesday, October 28, 2014 5:10 PM
To: anderson(a)redhat.com
Cc: crash-utility(a)redhat.com
Subject: Re: [Crash-utility] [ANNOUNCE] crash gcore command version 1.3.0-rc2
is released
From: Dave Anderson <anderson(a)redhat.com>
Subject: Re: [Crash-utility] [ANNOUNCE] crash gcore command version 1.3.0-rc2
is released
Date: Mon, 27 Oct 2014 13:59:04 -0400
>
>
> ----- Original Message -----
>> 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.
>
> Hello Daisuke,
>
> We have successfully tested the support for the ARM64 and PPC64
architectures.
> Thanks very much for accepting them.
>
Thanks for your verification.
> However, I have attached one small patch to the gcore.mk file that is
> required for ARM64 in order to build the module in the "extensions"
> subdirectory of the crash source tree.
>
> The standalone package builds OK on an ARM64 host:
>
> # make -f gcore.mk
> make[1]: Entering directory `/root/crash-gcore-command-1.3.0-rc2'
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_coredump.o
libgcore/gcore_coredump.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_coredump_table.o
libgcore/gcore_coredump_table.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_dumpfilter.o
libgcore/gcore_dumpfilter.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_elf_struct.o
libgcore/gcore_elf_struct.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_global_data.o
libgcore/gcore_global_data.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_regset.o
libgcore/gcore_regset.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_verbose.o
libgcore/gcore_verbose.c
> gcc -D_SYS_UCONTEXT_H=1 -Wall -I/usr/include/crash -I./libgcore -fPIC -
DARM64 -DVERSION='"1.3.0-rc2"' -DRELEASE_DATE='"24 Oct
2014"' -DPERIOD='"2010,
2011, 2012, 2013, 2014"' -c -o libgcore/gcore_arm64.o libgcore/gcore_arm64.c
> Make[1]: Leaving directory `/root/crash-gcore-command-1.3.0-rc2'
> #
>
> Note that the compile lines above contain -D_SYS_UCONTEXT_H=1 because
> of this "(shell arch)" section of the gcore.mk file:
>
> ifeq ($(shell arch), aarch64)
> TARGET=ARM64
> TARGET_CFLAGS=-D_SYS_UCONTEXT_H=1
> ARCH=SUPPORTED
> endif
>
> However, when building the package from within a crash source tree in
> its "extensions" subdirectory, the package fails to compile because
> the
> -D_SYS_UCONTEXT_H=1 gets dropped. That is because the top-level
> Makefile issues the make command with TARGET_CFLAGS defined on the
> command line, which overrides the "(shell arch)" TARGET_CFLAGS setting in
gcore.mk:
>
> (cd extensions; make -i TARGET=ARM64 TARGET_CFLAGS="" GDB=gdb-7.6
> GDB_FLAGS=-DGDB_7_6)
>
> In order to build both standalone and from within the crash source
> tree, I've modified the gcore.mk file to use a new "ARCH_CFLAGS"
> definition, and added $(ARCH_CFLAGS) to both compile lines below it:
>
> ifeq ($(shell arch), aarch64)
> TARGET=ARM64
> ARCH_CFLAGS=-D_SYS_UCONTEXT_H=1
> ARCH=SUPPORTED
> endif
>
> Note that if the ARM64 gcore.so is compiled from an x86_64 host that
> was built with "make target=ARM64", the "(shell arch), aarch64"
> section is not used (and not necessary).
>
I confirmed that after applying this patch, both make and make
target=ARM64 work fine.
If there's no other large issue, I'll release v1.3.0, not -rc3, this weekend
including this change.
--
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
3642
days inactive
3647
days old
devel@lists.crash-utility.osci.io
3 comments
3 participants
participants (3)
-
Dave Anderson -
HATAYAMA Daisuke -
Wei Shu