Patch adds new 'sbitmapq' command. This command dumps
the contents of the sbitmap_queue structure and the used
bits in the bitmap. Also, it shows the dump of a structure
array associated with the sbitmap_queue.
Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
Introduce a new "log -s" option, which outputs unflushed logs in the
printk safe buffers (safe_print_seq and nmi_print_seq) as follows:
crash> log -s
PRINTK_SAFE_SEQ_BUF: nmi_print_seq
CPU: 0 ADDR: ffff8ca4fbc19ce0 LEN: 150 MESSAGE_LOST: 0
Uhhuh. NMI received for unknown reason 20 on CPU 0.
Do you have a strange power saving mode enabled?
Dazed and confused, but trying to continue
...
The buffers are displayed for each CPU. For an empty buffer,
'(empty)' will be printed.
Also append those to the bottom of "log" command output so as not to
overlook them like this:
crash> log
...
[nmi_print_seq] Uhhuh. NMI received for unknown reason 30 on CPU 0.",
[nmi_print_seq] Do you have a strange power saving mode enabled?",
[nmi_print_seq] Dazed and confused, but trying to continue",
Note that the safe buffer (struct printk_safe_seq_buf) was introduced
at kernel-4.11 (Merge commit 7d91de74436a69c2b78a7a72f1e7f97f8b4396fa)
and removed at kernel-5.15 (93d102f094be9beab28e5afb656c188b16a3793b).
Link: https://listman.redhat.com/archives/crash-utility/2022-January/msg00052.html
Signed-off-by: Shogo Matsumoto <shogo.matsumoto@fujitsu.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Previously, the ps command will iterate over all threads which
have the same tgid, to accumulate their rss value, in order to
get a thread/process's final rss value as part of the final output.
For non-live systems, the rss accumulation values are identical for
threads which have the same tgid, so there is no need to do the
iteration and accumulation repeatly, thus a lot of readmem calls are
skipped. Otherwise it will be the performance bottleneck if the
vmcores have a large number of threads.
In this patch, the rss accumulation value will be stored in a cache,
next time a thread with the same tgid will take it directly without
the iteration.
For example, we can monitor the performance issue when a vmcore has
~65k processes, most of which are threads for several specific
processes. Without the patch, it will take ~7h for ps command
to finish. With the patch, ps command will finish in 1min.
Signed-off-by: Tao Liu <ltao@redhat.com>
Commit <2fab8fbc0c4f> ("symbols: Implement install and remove operations
for mod_symname_hash") added new member variable mod_symname_hash in the
middle of struct symbol_table_date, which breaks compatibility of struct
symbol_table_data for extension modules. As the result, crash trace command
results in segmentation fault.
Fixes: 2fab8fbc0c ("symbols: Implement install and remove operations for mod_symname_hash")
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Commit <2f967fb5ebd7> ("crash_taget: fetch_registers support") added new
member get_cpu_reg in the middle of struct machdep_table, which breaks
compatibility of struct machdep_table for extension modules. As the result,
crash gcore command results in unexpected behavior, furthermore may cause
segmentation fault.
Fixes: 2f967fb5eb ("crash_taget: fetch_registers support")
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Update the default SECTION_SIZE_BITS value for arm64 Linux 5.12
and later kernels that contain kernel commit f0b13ee23241
("arm64/sparsemem: reduce SECTION_SIZE_BITS").
Reported-by: Ankur Bansal <er.ankurbansal@gmail.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Commit 167d37e347 ("arm64: assign page_offset with VA_BITS kernel
configuration value") changed the page_offset calculation from
using VA_BITS_ACTUAL to CONFIG_ARM64_VA_BITS. This caused an error
for ramdumps without vmcoreinfo like this:
crash: vmlinux and /var/tmp/ramdump_elf_XUtCMT do not match!
Set the vmcoreinfo value to VA_BITS if available, and use VA_BITS
for page_offset calculation instead.
Also remove ARM64_FLIP_PAGE_OFFSET_ACTUAL because it's not used
actually.
Reported-by: Ankur Bansal <er.ankurbansal@gmail.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
SYMNAME_HASH_INDEX is used as the index of symname hash table. It will
be out of range if SYMNAME_HASH_INDEX is negative. This patch avoids
the risk by changing the marco into a function, and casting and calculating
the numbers as unsigned.
Suggested-by: Lianbo Jiang <lijiang@redhat.com>
Suggested-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Currently the sequence for symbol_search to search a symbol is: 1) kernel
symname hash table, 2) iterate all kernel symbols, 3) iterate all kernel
modules and their symbols. In the worst case, if a non-exist symbol been
searched, all 3 stages will be went through. The time consuming status for
each stage is like:
stage 1 stage 2 stage 3
0.007000(ms) 0.593000(ms) 2.421000(ms)
stage 3 takes too much time when comparing to stage 1. This patch series
introduces a symname hash table for kernel modules, to improve the
performance of symbol searching.
Functions symbol_search() and symbol_exists() are fundamental and widely
used by other crash functions, thus the benefit of performance improvement
can get accumulated. For example, "ps -m" and "irq" commands, which call
the functions many times, will become faster with the patch series.
This patch indroduces mod_symname_hash, and its install/remove operations.
Since symbol_search() has to return the lowest address symbol and
symbol_search_next() returns the next lowest symbol, thus the installation
should be sorted ascendingly.
In mod_symname_hash_install_range() scenario, spn are already arranged
ascendingly, so for mod_symname_hash_install():
Install spn previous to sp:
If sp is the start of bucket, or
1) spn->value is smaller than sp->value.
Install spn next to sp:
1) sp->name_hash_next is NULL, or
2) sp->name_hash_next->value is larger than spn->value
spn->value is the kernel address of the symbol and will not change.
So we use it mainly to determine the sequence. When spn->value equals
sp->value, they must be symbols within a kernel module.
Signed-off-by: Tao Liu <ltao@redhat.com>
The text value cache was implemented for analysis of remote dumpfiles
using the deprecated "crash daemon" running on the remote host. On
updating GDB to 10.2, a regression occurred when we tried to fix a
"help -x" command problem, and there was no performance degradation
even without the text cache, so let's drop this functionality.
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Provides API for crash_target to fetch registers of given
CPU. It will allow gdb to perform such commands as "bt",
"frame", "info locals".
Highlevel API is crash_get_cpu_reg (). It calls machine
(architecture) specific function: machdep->get_cpu_reg().
Input arguments such as register number and register size
come from gdb arch information. So, get_cpu_regs()
implementations in crash must understand it.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Main changes:
[1] update gdb-7.6.patch to gdb-10.2.patch, and keep all functionality
and good compatibility
[2] remove unneeded patches(gdb-7.6-proc_service.h.patch and
gdb-7.6-ppc64le-support.patch)
[3] to make the c++ compiler happy, add the extern "C" to eliminate
compilation issues, also add CXXFLAGS=-m32 to generate proper
32bit object files
[4] the parameter types of some functions are changed, eg, the set of
prettyprint variables
[5] eliminate error_hook() and SJLJ while running in C++ code (after
gdb_command_funnel()) use try-catch mechanism instead
[6] request_types() is redone to do not call GNU_GET_NEXT_DATATYPE multiple
times but single usage of GNU_ITERATE_DATATYPES with proper callback
instead. Complete iteration happens on C++ side now.
[7] remove "struct global_iterator" from request structure, but add
several fields (including callback pointer) to be able to perform
iteration on C++ side
[8] type of "linux_banner" symbol is reported as 'D' by new gdb as its
section ".rodata" marked as writable in vmlinux
[9] BFD API has changed.
[10] the deprecated_command_loop_hook got deprecated. So, call crash
main_loop() directly from gdb captured_main()
[11] remove previously used hooks for that in target.c. Add crash_target
for gdb to provide target operations such as xfer_partial to read
and write crash dump memory.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Add support for reading dumpfiles compressed by Zstandard (zstd)
using makedumpfile.
To build crash with zstd support, type "make zstd".
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
kdump format description [1] says:
[...] zero page has its own offset not equal 0. So when reading page
from incomplete core, only the page lost by ENOSPACE errors has 0 in its
corresponding page descriptor's member offset.
crash has special treatment for page descriptors with zero offset only if
DUMP_DH_COMPRESSED_INCOMPLETE is set in dump header. However,
makedumpfile places the flag after ENOSPC is hit and only if dump header
modification went without errors.
In case if crashkernel environment was terminated early (e.g. by BMC) or
some other reason, DUMP_DH_COMPRESSED_INCOMPLETE won't be set on the
dump header. Then cache_page() would be performed on pages with
pd.offset == 0 and due to pd.size == 0 it'll skip read into
compressed_page and then non related pre-existing contents of
compressed_page will copied into page cache for the non-present page.
Ultimately, it'll lead to a cryptic failure, like:
crash: invalid kernel virtual address: 72288cacacf427f8 [...]
The failure would be a bit cleaner if crash explicitly fails on the page
that is an outcome of incomplete dump:
crash: page incomplete: kernel virtual address: c000003fff9d17e8 [...]
Debugging level 8 would also produce exact offset from data_offset to
print descriptor value with ease:
read_diskdump/cache_page: descriptor with zero offset found at paddr/pfn/pos: 3fff9d0000/3fff9d/743dd
That helps in inspecting broken descriptor with hexdump or similar tools:
hexdump -s (data_offset + pos * 0x18) -n 0x18
[1] https://github.com/makedumpfile/makedumpfile/blob/master/IMPLEMENTATION
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
arm64 memory layout experiences big changes due to the following kernel
commits in date descending order:
5. 7bc1a0f9e176 arm64: mm: use single quantity to represent the PA to VA translation
4. b6d00d47e81a arm64: mm: Introduce 52-bit Kernel VAs
3. 5383cc6efed1 arm64: mm: Introduce vabits_actual
2. 14c127c957c1 arm64: mm: Flip kernel VA space
1. f80fb3a3d508 arm64: add support for kernel ASLR
For 1, crash has already used NEW_VMEMMAP to trace it.
For 2, crash lacks a flag to tag it and handle it differently.
For 3, two important kernel variables vabits_actual and physvirt_offset
are introduced.
For 4, since it comes immediately after 3, crash-utility does not need
to distinguish it.
For 5, kernel variable phyvirt_offset is removed
These changes have effects on PTOV()/VTOP() formula. So introducing
two bits HAS_PHYSVIRT_OFFSET and FLIPPED_VM as hint to apply different
formula.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
On RHEL9, crash hits a bug when executing "crash /proc/kcore":
seek error: kernel virtual address: ffff6a0f3fff0000 type: "pmd page"
The kernel virtual address does not vary with vabits_actual, instead,
is determined by configuration value. But crash does not observe this
fact.
Since vabits_actual related kernel commit is introduced after arm64
mm layout flip commit, so changes are safe under the condition if
(ms->VA_BITS_ACTUAL), and keep the else branch untouched.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reflect the flipped layout of kernel VA, which is introduced by
kernel commit 14c127c957c1 ("arm64: mm: Flip kernel VA space").
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Kernel commit 2f064a59a11ff9bc22e52e9678bc601404c7cb34 ("sched: Change
task_struct::state") renamed the member state of task_struct to __state
and its type changed from long to unsigned int. Without the patch,
crash fails to start up with the following error:
crash: invalid structure member offset: task_struct_state
FILE: task.c LINE: 5929 FUNCTION: task_state()
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
The wait queue structs and members were renamed in 4.13 in commits:
ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
9d9d676f595b ("sched/wait: Standardize internal naming of wait-queue heads")
2055da97389a ("sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming")
Add support to the 'waitq' command for these more recent kernels.
[ kh: suppressed compilation warnings ]
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
The -O option is very useful to specify the embedded head node's
offset which is different to the offset of other nodes embedded,
e.g. dentry.d_subdirs (the head node) and dentry.d_child.
[ kh: did some cosmetic adjustments ]
Signed-off-by: Firo Yang <firo.yang@suse.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Three fixes for MIPS64 kernels:
(1) To support ramdumps, add the machine_type() check for MIPS64 in
ramdump_to_elf().
(2) To fix a stuck issue when invoking crash with "-d1" or larger
debug value, add the machine_type() check to get the correct
dump NOTE offsets.
(3) Fix the reference file path to the definition of the pt_regs
structure, to which mips64_regster refers.
[ kh: merged three patches into one ]
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Correct the change of the value of TIF_SIGPENDING macro between
different kernel versions.
TIF_SIGPENDING changes with the kernel version as follows:
ARM 2 -> 0 at v2.6.23
MIPS 2 -> 1 at v2.6.23
MIPS64 2 -> 1 at v2.6.23
PPC 2 -> 1 at v2.6.23
IA64 1 -> 0 at v2.6.23
PPC64 2 -> 1 at v2.6.23
S390 2 -> 1 at v3.16
S390X 2 -> 1 at v3.16
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Mainly added some environment configurations, macro definitions, specific
architecture structures and some function declarations supported by the
MIPS64 architecture.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
try_zram_decompress() is currently exported to extension modules, but
from a viewpoint of author of extension modules, it's better to export
an interface to read memory on swap; difference of decompressor are
then hidden within the interface and there is no need for extension
modules to update accordingly each time new decompressor are added in
the future.
So let's introduce function readswap() as an interface to read memory
on swap.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Currently, zram code is included only when LZO is enabled. However,
more natural implementation is that if users encounter pages swapped
into zram that are compressed with unsupported compression algorithm,
crash notifies that. To do so, let's include zram code by default.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
In older kernels that have the variable-length-record log_buf, the
log level and the log flags/facility are not separated. Since the
log level is only the last three bits, and the flags/facility and
level are separated in 5.10 and later kernels, only print those last
three bits when using 'log -m'.
[ kh: modified commit message ]
Suggested-by: David Jeffery <djeffery@redhat.com>
Signed-off-by: John Pittman <jpittman@redhat.com>
The current value of __PHYSICAL_MASK_SHIFT_XEN in crash (40) is
smaller than the kernel (52) since kernel commit 6f0e8bf167 (xen:
support 52 bit physical addresses in pv guests).
This can cause x86_64_pud_offset() to lose the most significant
bits of pgd_pte, leading to a failed xen_m2p() translation,
resulting in crash failing with an error message like this:
crash: read error: physical address: ffffffffffffffff type: "pud page"
Both Intel and AMD documentation mandate that unused physical
address bits must be 0, so there is no need to explicitly mask them
out with a mask narrower than the architecture limit of 52. This
is also confirmed by this kernel commit: b83ce5ee91.
Increase the value of __PHYSICAL_MASK_SHIFT_XEN to 52.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Fix the "dev -d" option on Linux 5.11-rc1 and later kernels that
contains commit 0d02129e76edf91cf04fabf1efbc3a9a1f1d729a
("block: merge struct block_device and struct hd_struct").
Without the patch, the option fails with the error message
"dev: invalid structure member offset: hd_struct_dev".
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Linux 5.10 has introduced SEV-ES support. New (5th) exception
stack was added: 'VC_stack'.
'struct exception_stacks' cannot be used to obtain the size
of VC stack, as the size of VC stack is zero there. Try
another structure 'struct cea_exception_stacks' first as it
represents actual CPU entry area with valid stack sizes and
guard pages.
Handled the case if VC stack is not mapped (present).
It happens when SEV-ES is not active or not supported.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Linux 5.10 introduces a new lockless ringbuffer. The new ringbuffer
is structured completely different to the previous iterations.
Add support for dumping the ringbuffer with the "log" command.
The new ringbuffer is detected based on the availability of
the "prb" symbol.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Use LA57 bit in CR4 to check whether 5-level paging enabled.
Initialize machdep to 5-level paging operation mode used by
x86_64_kvtop.
Replaced *_get_cr3_idtr() set of functions by *_get_cr3_cr4_idtr().
[ kh: added malloc for p4d page ]
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Qemu and VMWare facilities rely only on CPU #0 to provide
CR3 and IDTR. But these registers can be not initialized
or clobbered, depending on the state of CPU. For example,
kernel can trigger triple fault by zeroing IDTR and doing
int3. This is used in Linux to reboot machine using triple
fault: "reboot=t" cmdline. In that case CPU which triggered
triple fault will have zeroed IDTR.
Generalize the method used by Sadump facility to analyze
every pair of registers from all available CPUs.
Create subfunctions for easy reading.
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Acked-by: Lianbo Jiang <lijiang@redhat.com>
vmware_guestdump is extension to vmware_vmss with ability to debug
debug.guest and debug.vmem files.
debug.guest.gz and debug.vmem.gz can be obtained using following
.vmx options from VM running in debug mode:
monitor.mini-suspend_on_panic = TRUE
monitor.suspend_on_triplefault = TRUE
guestdump (debug.guest) is simplified version of *.vmss which does
not contain full VM state, but minimal guest state, such as memory
layout and CPUs state, needed for debugger. is_vmware_guestdump()
and vmware_guestdump_init() functions parse guestdump header and
populate vmss data structure (from vmware_vmss.c). As result, all
handlers (except mempry_dump) from vmware_vmss.c can be reused.
How to use: $ crash /path/to/debug_file.guest vmlinux
Companion debug_file.vmem must be present in the same folder as
debug_file.guest. Otherwise crash will shot a message:
vmw: Open the companion vmem file: /path/to/debug_file.vmem
crash: vmw: /path/to/debug_file.vmem: No such file or directory
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
The offset of the field 'init_uts_ns.name' has changed
since commit 9a56493f6942 ("uts: Use generic ns_common::count").
Link: https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
Read the offset from the vmlinux file's debuginfo data properly
to fix a failure during crash initialization.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Currently it's not easy to distinguish which time zone the output of
DATE uses:
crash> sys | grep DATE
DATE: Thu Nov 29 06:44:02 2018
Let's introduce ctime_tz() function like ctime() but explicitly appends
the time zone to its result string.
DATE: Thu Nov 29 06:44:02 JST 2018
Resolves: https://github.com/crash-utility/crash/issues/62
Suggested-by: Jacob Wen <jian.w.wen@oracle.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
On kernels that contain commit 9df872faa7e1 ("genirq: Move field
'affinity' from irq_data into irq_common_data"), without the patch,
the "irq -a" option cannot work with the message "irq: -a option not
supported or applicable on this architecture or kernel".
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
On kernels that contain commit 1008fe6dc36d ("block: remove the all_bdevs
list"), without the patch, the "kmem -i" option fails halfway with the
error message 'kmem: cannot resolve: "all_bdevs"'.
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
PaX and grsecurity kernels split module memory into dedicated r/x and
r/w mappings using '*_rw' and '*_rx' named member variables in 'struct
module'. To add basic support for such kernels detect the split layout
by testing for the corresponding structure members and use these
instead.
So far we limit ourself to only track module code mappings for such
kernels as adding support for separate data mappings violates lots of
invariants in the rest of our code base, thereby would require a major
rework. However, with that patch applied, module code references can be
resolved in backtraces, memory and code dumps, which makes it already
very useful for analyzing such kernels.
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Add linux_banner_vmlinux in symbol table, which we'll later use in
calc_kaslr_offset() to do a sanity check in calculation of
kaslr_offset and phys_base.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Add support for 1GB huge pages to "vtop" command on x86_64. Without
this patch, the command with a user virtual address corresponding to
a 1GB huge page fails with the error message "vtop: seek error:
physical address: <address> type: "page table".
crash> vtop 7f6e40000000
VIRTUAL PHYSICAL
vtop: seek error: physical address: 3f53f000f000 type: "page table"
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Chu Kaiping <chukaiping@foxmail.com>
Fedora kernel version 5.6.7-200.fc31. The patch adds the following:
(1) Redefine _PFN_BITS() macro to use MAX_POSSIBLE_PHYSMEM_BITS.
(2) Fix to determine whether address_space.i_pages is a radix tree
or an xarray.
(3) Fix to not mistakenly select the "lzo" compressor when the
kernel has used the default "lzo-rle" compressor.
(4) Since zram may be provided as a kernel module, it would be
necessary to load its debuginfo during the crash session;
therefore perform the zram structure-size/member-offset
initializations when first required instead of during
session initialization.
(5) Handle the zram_table_entry structure member name change
from "value" to "flags".
(1) Linux kernel patch "arm64: mm: Introduce vabits_actual"
introduced "physvirt_offset", which is not equal to
(PHYS_OFFSET - PAGE_OFFSET) when KASLR is enabled.
physvirt_offset is caculated in arch/arm64/mm/init.c
before memstart_addr (PHYS_OFFSET) is randomized. Let
arm64_VTOP() and arm64_PTOV() use physvirt_offset instead,
whose default value is set to (phys_offset - page_offset)
(2) For ARM64 RAM dumps without any vmcoreinfo and KASLRpassed as
argument, " _stext_vmlinux" is not set. This causes incorrect
calculation of vmalloc_start with VA_BITS_ACTUAL.
(3) For ARM64 RAM dumps For ramdumps without vmcoreinfo, get
CONFIG_ARM64_VA_BITS from in-kernel config. Without this,
vmemmap size is calculated incorrectly.
(4) Fix the vmemmap_start to match with what the kernel uses.
(vinayakm.list@gmail.com)
as in-kernel feature. The value of CONFIG_ARM64_KERNELPACMASK
will be exported as a vmcoreinfo entry, and will be used with text
return addresses on the kernel stack.
(amit.kachhap@arm.com)
display of a single data structure member. Without the patch, the
option only supported the raw display of a complete data structure.
(asmadeus@codewreck.org)
