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.
(anderson@redhat.com)
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.
(anderson@redhat.com)
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.
(surendra@chelsio.com)
loaded eBFP (extended Berkeley Packet Filter) programs and maps.
Because of its upstream fluidity, the capabilities of this command
will be an ongoing task. In its initial form, the command displays
the addresses, basic information, and key data structures of eBPF
programs and maps. It also translates the bytecode, and disassembles
the jited code, of loaded eBPF programs.
(anderson@redhat.com)
calculating phys_base and the mapped kernel offset for KASLR-enabled
kernels on SADUMP dumpfiles by using a technique developed by Takao
Indoh. Originally, the patchset included support for kdumps, but this
was dropped in v2, as it was deemed unnecessary due to the upstream
implementation of the "vmcoreinfo device" in QEMU. However, there
are still several reasons for which the vmcoreinfo device may not be
present at the time when a memory dump is taken from a VM, ranging
from a host running older QEMU/libvirt versions, to misconfigured VMs
or environments running Hypervisors that doesn't support this device.
This patchset generalizes the KASLR-related functions from sadump.c
and moves them to kaslr_helper.c, and makes kdump analysis fall back
to KASLR offset calculation if vmcoreinfo data is missing.
(slp@redhat.com)
on the host build machine. Without the patch, the build fails with
the error message "amd64-linux-nat.c:496:1: error: conflicting types
for 'ps_get_thread_area'".
(anderson@redhat.com)
version supports running against a live kernel. Compressed kdump
support is also here, but the crash dump support for the kernel,
kexec-tools, and makedumpfile is still pending. Initial work was
done by Karl Volz with help from Bob Picco.
(dave.kleikamp@oracle.com)
version of the gdb-7.6.patch in a pre-existing build directory.
Without the patch, it is possible that a previously-applied patch
could be applied a second time without the fuzz restriction.
(anderson@redhat.com)
Since makedumpfile commit 349a0ed1, it is now possible to save Xen
dumps in compressed kdump format. This patch set adds support for
these files. Two new files, xen_dom0.c and xen_dom0.h, have been
added to provide the common functionality required by both ELF and
compressed kdump formats.
(ptesarik@suse.cz)
done from within a previously-existing build tree, the "patch -N"
option is used to ignore patches that have been previously applied;
this patch also applies the "patch -r-" option to prevent unnecessary
.rej files from being created.
(anderson@redhat.com)
Similar to all other supported dumpfile types, it is invoked as:
$ crash vmlinux <vmname>.vmss
A "<vmname>.vmss" file created by the VMware vSphere ESX hypervisor
contains a header and the full memory image. A "<vmname>.vmss" file
created by the VMware Workstation facility only contains the header,
and must be accompanied by a companion "<vmname>.vmem" memory image
that is located in the same directory as the "<vmname>.vmss" file.
(hfu@vmware.com)
initial support is restricted to 32-bit MIPS kernels that are
configured as little-endian. With respect to dumpfile types, only
ELF vmcores are recognized. In addition to building crash as a
32-bit MIPS binary, it is also possible to build crash as an x86
binary on an x86 or x86_64 host so that crash analysis of MIPS
dumpfiles can be performed on an x86 or x86_64 host. The x86 binary
can be built by entering "make target=MIPS" for the initial build;
subsequent builds with MIPS support can be accomplished by entering
"make" alone.
(rabin@rab.in)
for analyzing little-endian PPC64 dumpfiles on an x86_64 host, which
can be done by entering "make target=PPC64". After the initial build
is complete, subsequent builds can be done by entering "make" alone.
(anderson@redhat.com)
Since this required a large number of patches to be applied to
architecture-neutral files in the gdb-7.6 tree, the changes are
only applied if the host build system is a ppc64le.
(ptesarik@suse.cz, normand@linux.vnet.ibm.com)
more "ramdump" files may be entered on the crash command line
in an ordered pair format consisting of the RAM dump filename
and the starting physical address expressed in hexadecimal,
connected with an ampersand:
$ crash vmlinux ramdump@address [ramdump@address]
A temporary ELF header will be created in /var/tmp, and the
combination of the header and the ramdump file(s) will be handled
like a normal ELF vmcore. The ELF header will only exist during
the crash session. If desired, an optional "-o <filename>"
may be entered to create a permanent ELF vmcore file from the
ramdump file(s).
(vinayakm.list@gmail.com, paawan1982@yahoo.com, anderson@redhat.com)
done from within a previously-existing build tree, "patch -N" the
gdb sources, and start the rebuild from the gdb-<version> directory
instead of the gdb-<version>/gdb directory.
(anderson@redhat.com)
the crash package is built from a directory that was git-cloned
from github.com/crash-utility/crash.git, the error message has
been clarified to indicate "/usr/bin/wget is required to download
gdb-7.6.tar.gz". Without the patch, the message indicates "tar
(child): gdb-7.6.tar.gz: Cannot open: No such file or directory".
(anderson@redhat.com)
