[PATCH 0/2] Revert two patches to fix a regression issue
by Lianbo Jiang
This reverts two patches:
[1] [PATCH 1/2] Revert "defs.h: fix breakage of compatibility of struct
machdep_table for extension modules"
- Because the 2f967fb5ebd7 ("crash_taget: fetch_registers support") will
be removed by the [PATCH 2/2], the old fix won't be needed.
[2] [PATCH 2/2] Revert "crash_taget: fetch_registers support"
- The original patch causes a regression issue, try to revert it and
this issue disappeared.
Lianbo Jiang (2):
Revert "defs.h: fix breakage of compatibility of struct machdep_table
for extension modules"
Revert "crash_taget: fetch_registers support"
crash_target.c | 33 +-------------------------------
defs.h | 51 -------------------------------------------------
gdb_interface.c | 19 +++++-------------
vmware_vmss.c | 51 +------------------------------------------------
x86_64.c | 16 ----------------
5 files changed, 7 insertions(+), 163 deletions(-)
--
2.37.1
1 year, 9 months
Re: [Crash-utility] [PATCH v4 4/4] Let kmem print task context with physical address
by lijiang
Hi, Tao
Thank you for the update.
On Mon, Sep 19, 2022 at 8:00 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Mon, 19 Sep 2022 17:49:24 +0800
> From: Tao Liu <ltao(a)redhat.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH v4 4/4] Let kmem print task context
> with physical address
> Message-ID: <20220919094924.17078-5-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> With patch [1], kmem <phyaddr> will print task context when
> CONFIG_VMAP_STACK enabled. However when CONFIG_VMAP_STACK disabled,
> kmem <phyaddr> will never print task context, so the behaviour is
> inconsistent.
>
> This patch addresses the issue, to let kmem <phyaddr> can output
> task context when CONFIG_VMAP_STACK disabled.
>
> Before:
> crash> kmem 16663edfda0
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffee33998fb7c0 16663edf000 0 0 0
> 6fffff00000000
>
> After:
> crash> kmem 16663edfda0
> PID: 19007
> COMMAND: "bash"
> TASK: ffff8bb405d320e0 [THREAD_INFO: ffff8bb463edc000]
> CPU: 59
> STATE: TASK_RUNNING (SYSRQ)
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffee33998fb7c0 16663edf000 0 0 0
> 6fffff00000000
>
> [1]:
> https://listman.redhat.com/archives/crash-utility/2022-September/010117.html
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> memory.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/memory.c b/memory.c
> index eac8262..d0daa58 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -13566,11 +13566,13 @@ kmem_search(struct meminfo *mi)
> /*
> * Check whether it's a current task or stack address.
> */
> - if ((mi->memtype == KVADDR) && (task =
> vaddr_in_task_struct(vaddr)) &&
> + if (((mi->memtype == KVADDR) || (mi->memtype == PHYSADDR)) &&
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With the following minor changes:
mi->memtype & (KVADDR|PHYSADDR)
The v4 looks good to me, so: Ack.
Thanks.
Lianbo
> + (task = vaddr_in_task_struct(vaddr)) &&
> (tc = task_to_context(task))) {
> show_context(tc);
> fprintf(fp, "\n");
> - } else if ((mi->memtype == KVADDR) && (task =
> stkptr_to_task(vaddr)) &&
> + } else if (((mi->memtype == KVADDR) || (mi->memtype == PHYSADDR))
> &&
>
Ditto.
> + (task = stkptr_to_task(vaddr)) &&
> (tc = task_to_context(task))) {
> show_context(tc);
> fprintf(fp, "\n");
> --
> 2.33.1
>
1 year, 9 months
[PATCH] Fix for the invalid linux_banner pointer issue
by Lianbo Jiang
Currently, crash may fail with the following error:
# ./crash vmlinux /var/crash/127.0.0.1-2022-09-15-09:31:55/vmcore -s
WARNING: invalid linux_banner pointer: 65762078756e694c
crash: vmlinux and /var/crash/127.0.0.1-2022-09-15-09:31:55/vmcore do not match!
The reason is that the type of symbols in the data segment may be
defined as 'D' or 'd'. The crash only handled the type 'D', but it
didn't deal with the type 'd'. For example:
# nm vmlinux |grep linux_banner
ffffffff827cfa80 d linux_banner
Let's add the type 'd' recognition to solve such issue.
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
kernel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel.c b/kernel.c
index a521ef30cdb0..aa030e8097ea 100644
--- a/kernel.c
+++ b/kernel.c
@@ -1060,7 +1060,7 @@ verify_version(void)
if (!(sp = symbol_search("linux_banner")))
error(FATAL, "linux_banner symbol does not exist?\n");
else if ((sp->type == 'R') || (sp->type == 'r') ||
- (THIS_KERNEL_VERSION >= LINUX(2,6,11) && sp->type == 'D') ||
+ (THIS_KERNEL_VERSION >= LINUX(2,6,11) && (sp->type == 'D' || sp->type == 'd')) ||
(machine_type("ARM") && sp->type == 'T') ||
(machine_type("ARM64")))
linux_banner = symbol_value("linux_banner");
--
2.37.1
1 year, 9 months
[PATCH V3 0/9] Support RISCV64 arch and common commands
by Xianting Tian
This series of patches are for Crash-utility tool, it make crash tool support
RISCV64 arch and the common commands(*, bt, p, rd, mod, log, set, struct, task,
dis, help -r, help -m, and so on).
To make the crash tool work normally for RISCV64 arch, we need a Linux kernel
patch, which exports the kernel virtual memory layout, va_bits, phys_ram_base
to vmcoreinfo, it can simplify the development of crash tool.
The Linux kernel patch set:
https://lore.kernel.org/linux-riscv/20220811074150.3020189-1-xianting.tia...
[ Patch 1 ~ 4 already merged to Linux for-next branch, targeted for 5.20;
Patch 5, 6 already merged to Palmer's riscv-crash branch:
https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=r... ]
This series of patches are tested on QEMU RISCV64 env and SoC platform of
T-head Xuantie 910 RISCV64 CPU.
====================================
Some test examples list as below
====================================
... ...
KERNEL: vmlinux
DUMPFILE: vmcore
CPUS: 1
DATE: Fri Jul 15 10:24:25 CST 2022
UPTIME: 00:00:33
LOAD AVERAGE: 0.05, 0.01, 0.00
TASKS: 41
NODENAME: buildroot
RELEASE: 5.18.9
VERSION: #30 SMP Fri Jul 15 09:47:03 CST 2022
MACHINE: riscv64 (unknown Mhz)
MEMORY: 1 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 113
COMMAND: "sh"
TASK: ff60000002269600 [THREAD_INFO: ff60000002269600]
CPU: 0
STATE: TASK_RUNNING (PANIC)
carsh>
crash> p mem_map
mem_map = $1 = (struct page *) 0xff6000003effbf00
crash> p /x *(struct page *) 0xff6000003effbf00
$5 = {
flags = 0x1000,
{
{
{
lru = {
next = 0xff6000003effbf08,
prev = 0xff6000003effbf08
},
{
__filler = 0xff6000003effbf08,
mlock_count = 0x3effbf08
}
},
mapping = 0x0,
index = 0x0,
private = 0x0
},
... ...
crash> mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffff0113e740 nvme_core ffffffff01133000 98304 (not loaded) [CONFIG_KALLSYMS]
ffffffff011542c0 nvme ffffffff0114c000 61440 (not loaded) [CONFIG_KALLSYMS]
crash> rd ffffffff0113e740 8
ffffffff0113e740: 0000000000000000 ffffffff810874f8 .........t......
ffffffff0113e750: ffffffff011542c8 726f635f656d766e .B......nvme_cor
ffffffff0113e760: 0000000000000065 0000000000000000 e...............
ffffffff0113e770: 0000000000000000 0000000000000000 ................
crash> vtop ffffffff0113e740
VIRTUAL PHYSICAL
ffffffff0113e740 8254d740
PGD: ffffffff810e9ff8 => 2ffff001
P4D: 0000000000000000 => 000000002fffec01
PUD: 00005605c2957470 => 0000000020949801
PMD: 00007fff7f1750c0 => 0000000020947401
PTE: 0 => 209534e7
PAGE: 000000008254d000
PTE PHYSICAL FLAGS
209534e7 8254d000 (PRESENT|READ|WRITE|GLOBAL|ACCESSED|DIRTY)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ff6000003f0777d8 8254d000 0 0 1 0
crash> bt
PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh"
#0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8
#1 [ff20000010333cf0] panic at ffffffff806578c6
#2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
#3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
#4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
#5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
#6 [ff20000010333e40] vfs_write at ffffffff80152bb2
#7 [ff20000010333e80] ksys_write at ffffffff80152eda
#8 [ff20000010333ed0] sys_write at ffffffff80152f52
-------
Changes V1 -> V2:
1, Do the below fixes based on HAGIO KAZUHITO's comments:
Fix build warnings,
Use MACRO for Linux version,
Add description of x86_64 binary for riscv64 in README,
Fix build error for the "sticky" target for build on x86_64,
Fix the mixed indent.
2, Add 'help -m/M' support patch to this patch set.
3, Support native compiling approach, which means the host OS distro
is also a riscv64 (lp64d) Linux, based on Yixun Lan's comments.
4, Use __riscv and __riscv_xlen instead of __riscv64__ based on Yixun Lan's comments.
Changes V2 -> V3:
1, Fix coding style, avoid including the header twice, move free() to right place,
introduce VM_FLAGS and so on based on Li Jiang's comments.
2, Adjust the implementation of riscv64_verify_symbol(refer to the logic of x86_64_verify_symbol)
as KSYMS_START isn't set when verify symbol in some case.
Xianting Tian (9):
Add RISCV64 framework code support
RISCV64: Make crash tool enter command line and support some commands
RISCV64: Add 'dis' command support
RISCV64: Add 'irq' command support
RISCV64: Add 'bt' command support
RISCV64: Add 'help -r' command support
RISCV64: Add 'help -m/M' command support
RISCV64: Add 'mach' command support
RISCV64: Add the implementation of symbol verify
Makefile | 7 +-
README | 4 +-
configure.c | 43 +-
defs.h | 252 +++++++-
diskdump.c | 21 +-
help.c | 2 +-
lkcd_vmdump_v1.h | 8 +-
lkcd_vmdump_v2_v3.h | 8 +-
netdump.c | 22 +-
ramdump.c | 2 +
riscv64.c | 1491 +++++++++++++++++++++++++++++++++++++++++++
symbols.c | 10 +
12 files changed, 1848 insertions(+), 22 deletions(-)
create mode 100644 riscv64.c
--
2.17.1
1 year, 9 months
Re: [Crash-utility] [PATCH v3 3/3] Let kmem print task context when physical address is vmalloced stack
by lijiang
Hi, Tao
Thank you for the update.
On Mon, Sep 5, 2022 at 8:00 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Mon, 5 Sep 2022 15:09:22 +0800
> From: Tao Liu <ltao(a)redhat.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH v3 3/3] Let kmem print task context
> when physical address is vmalloced stack
> Message-ID: <20220905070922.14426-4-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Patch [1] enables kmem to print task context if the given virtual
> address is a vmalloced stack.
>
> This patch handles the same issue except the given address is
> physical address.
>
Before:
> crash> kmem 1883700e28
> VMAP_AREA VM_STRUCT ADDRESS RANGE
> SIZE
> ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 -
> ffffb7efce9bd000 20480
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffdd28220dc000 1883700000 0 0 1 50000000000000
>
> After:
> crash> kmem 1883700e28
> PID: 847
> COMMAND: "khungtaskd"
> TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
> CPU: 72
> STATE: TASK_RUNNING (PANIC)
>
> VMAP_AREA VM_STRUCT ADDRESS RANGE
> SIZE
> ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 -
> ffffb7efce9bd000 20480
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffdd28220dc000 1883700000 0 0 1 50000000000000
>
> [1]:
> https://listman.redhat.com/archives/crash-utility/2022-August/010074.html
>
>
I did the test and got different results with yours as below. Did I miss
anything else?
crash> kmem ffff94e088110000
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff94e080c22a00 12040 3126 3129 3129 16k task_struct
SLAB MEMORY NODE TOTAL ALLOCATED FREE
ffffdd27c4204400 ffff94e088110000 0 1 1 0
FREE / [ALLOCATED]
[ffff94e088110000]
PID: 0
COMMAND: "swapper/2"
TASK: ffff94e088110000 (1 of 96) [THREAD_INFO: ffff94e088110000]
CPU: 2
STATE: TASK_RUNNING (ACTIVE)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd27c4204400 108110000 ffff94e080c22a00 0 1 10000000008100
slab,head
crash> kmem 108110000
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff94e080c22a00 12040 3126 3129 3129 16k task_struct
SLAB MEMORY NODE TOTAL ALLOCATED FREE
ffffdd27c4204400 ffff94e088110000 0 1 1 0
FREE / [ALLOCATED]
[ffff94e088110000]
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd27c4204400 108110000 ffff94e080c22a00 0 1 10000000008100
slab,head
crash>
Thanks
Lianbo
Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> memory.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/memory.c b/memory.c
> index 1b6f9ba..eac8262 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -13506,6 +13506,10 @@ kmem_search(struct meminfo *mi)
> mi->flags &= ~GET_PHYS_TO_VMALLOC;
>
> if (mi->retval) {
+ if ((task = stkptr_to_task(mi->retval)) && (tc =
> task_to_context(task))) {
> + show_context(tc);
> + fprintf(fp, "\n");
> + }
> if ((sp = value_search(mi->retval, &offset))) {
> show_symbol(sp, offset,
> SHOW_LINENUM | SHOW_RADIX());
> --
> 2.33.1
>
1 year, 9 months
Re: [Crash-utility] [PATCH v2] Fix kmem failing to print task context when address is vmalloced stack
by lijiang
Hi, Tao
Thank you for the fix.
On Thu, Aug 25, 2022 at 8:00 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Thu, 25 Aug 2022 14:42:45 +0800
> From: Tao Liu <ltao(a)redhat.com>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH v2] Fix kmem failing to print task
> context when address is vmalloced stack
> Message-ID: <20220825064243.71447-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> When kernel enabled CONFIG_VMAP_STACK, stack can be allocated to
> vmalloced area. Currently crash didn't handle the case, as a result,
> kmem will not print the task context as expected. This patch fix the
> bug by checking if the address is a vmalloced stack first.
>
> Before:
> crash> kmem ffffb7efce9bbe28
> VMAP_AREA VM_STRUCT ADDRESS RANGE
> SIZE
> ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 -
> ffffb7efce9bd000 20480
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffdd28220dc000 1883700000 0 0 1 50000000000000
>
> After:
> crash> kmem ffffb7efce9bbe28
> PID: 847
> COMMAND: "khungtaskd"
> TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
> CPU: 72
> STATE: TASK_RUNNING (PANIC)
>
> VMAP_AREA VM_STRUCT ADDRESS RANGE
> SIZE
> ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 -
> ffffb7efce9bd000 20480
>
>
I have one question: If the given physical address falls in the vmalloc
area, it won't print the task context, is that expected? For example:
[1] Before this patch: the "kmem + physical/virtual address" has the same
output asbelow.
crash> kmem ffffb7efce9bbe28
VMAP_AREA VM_STRUCT ADDRESS RANGE
SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000
20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
crash> kmem 1883700e28 <----- vtop ffffb7efce9bbe28
VMAP_AREA VM_STRUCT ADDRESS RANGE
SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000
20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
[2] After this patch: the "kmem + physical/virtual address" has different
output asbelow.
crash> kmem ffffb7efce9bbe28
PID: 847
COMMAND: "khungtaskd"
TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
CPU: 72
STATE: TASK_RUNNING (PANIC)
VMAP_AREA VM_STRUCT ADDRESS RANGE
SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000
20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
crash> kmem 1883700e28 <----- vtop ffffb7efce9bbe28
VMAP_AREA VM_STRUCT ADDRESS RANGE
SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000
20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
Thanks.
Lianbo
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffdd28220dc000 1883700000 0 0 1 50000000000000
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
>
> v1 -> v2: 1) Remove goto to print task context and vmlist.
> 2) Update commit log to show the change.
>
> ---
> memory.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/memory.c b/memory.c
> index 7339f0c..9ab5781 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -13477,6 +13477,10 @@ kmem_search(struct meminfo *mi)
> * Check for a valid mapped address.
> */
> if ((mi->memtype == KVADDR) && IS_VMALLOC_ADDR(mi->spec_addr)) {
> + if ((task = stkptr_to_task(vaddr)) && (tc =
> task_to_context(task))) {
> + show_context(tc);
> + fprintf(fp, "\n");
> + }
> if (kvtop(NULL, mi->spec_addr, &paddr, 0)) {
> mi->flags = orig_flags | VMLIST_VERIFY;
> dump_vmlist(mi);
> --
> 2.33.1
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://listman.redhat.com/mailman/listinfo/crash-utility
>
>
> ------------------------------
>
> End of Crash-utility Digest, Vol 203, Issue 41
> **********************************************
>
>
1 year, 9 months
[PATCH v2] Fix gcc-11 compiler warnings on gdb-10.2/gdb/symtab.c
by HAGIO KAZUHITO(萩尾 一仁)
Without the patch, the following gcc-11 compiler warnings are emitted
for gdb-10.2/gdb/symtab.c:
symtab.c: In function 'void gdb_get_datatype(gnu_request*)':
symtab.c:7131:31: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
7131 | register struct type *type;
| ^~~~
symtab.c:7132:31: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
7132 | register struct type *typedef_type;
| ^~~~~~~~~~~~
...
Usually we don't fix compiler warnings for gdb, but these are emitted
even by "make clean ; make warn", which doesn't recompile the whole
gdb, so it would be better to fix.
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
v2
- rebased to the current gdb-10.2.patch.
gdb-10.2.patch | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index 642cd6a78a1d..91edfb338445 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -9,6 +9,7 @@
# to all subsequent patch applications.
tar xvzmf gdb-10.2.tar.gz \
+ gdb-10.2/gdb/symtab.c \
gdb-10.2/gdb/printcmd.c \
gdb-10.2/gdb/symfile.c \
gdb-10.2/gdb/Makefile.in
@@ -1696,3 +1697,43 @@ exit 0
/* If the nearest symbol is too far away, don't print anything symbolic. */
+--- gdb-10.2/gdb/symtab.c.orig
++++ gdb-10.2/gdb/symtab.c
+@@ -7128,8 +7128,8 @@ gdb_get_line_number(struct gnu_request *
+ static void
+ gdb_get_datatype(struct gnu_request *req)
+ {
+- register struct type *type;
+- register struct type *typedef_type;
++ struct type *type;
++ struct type *typedef_type;
+ expression_up expr;
+ struct symbol *sym;
+ struct value *val;
+@@ -7235,7 +7235,7 @@ gdb_get_datatype(struct gnu_request *req
+ static void
+ dump_enum(struct type *type, struct gnu_request *req)
+ {
+- register int i;
++ int i;
+ int len;
+ long long lastval;
+
+@@ -7271,7 +7271,7 @@ dump_enum(struct type *type, struct gnu_
+ static void
+ eval_enum(struct type *type, struct gnu_request *req)
+ {
+- register int i;
++ int i;
+ int len;
+ long long lastval;
+
+@@ -7298,7 +7298,7 @@ eval_enum(struct type *type, struct gnu_
+ static void
+ get_member_data(struct gnu_request *req, struct type *type, long offset, int is_first)
+ {
+- register short i;
++ short i;
+ struct field *nextfield;
+ short nfields;
+ struct type *typedef_type, *target_type;
--
2.31.1
1 year, 10 months
[PATCH] Fix gcc-12 compiler warnings on lkcd_*.c
by HAGIO KAZUHITO(萩尾 一仁)
Without the patch, the following gcc-12 compiler warnings are emitted
for lkcd_*.c:
lkcd_v1.c: In function 'dump_lkcd_environment_v1':
lkcd_v1.c:252:20: warning: the comparison will always evaluate as 'true' for the address of 'dh_panic_string' will never be NULL [-Waddress]
252 | dh && dh->dh_panic_string &&
| ^~
In file included from lkcd_v1.c:21:
lkcd_vmdump_v1.h:108:30: note: 'dh_panic_string' declared here
108 | char dh_panic_string[DUMP_PANIC_LEN];
| ^~~~~~~~~~~~~~~
...
Reporeted-by: Lianbo Jiang <lijiang(a)redhat.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
lkcd_v1.c | 3 +--
lkcd_v2_v3.c | 3 +--
lkcd_v5.c | 3 +--
lkcd_v7.c | 3 +--
lkcd_v8.c | 3 +--
5 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/lkcd_v1.c b/lkcd_v1.c
index 5f891ae..31bdc04 100644
--- a/lkcd_v1.c
+++ b/lkcd_v1.c
@@ -249,8 +249,7 @@ dump_header_only:
lkcd_print(" dh_eip: %lx\n", dh->dh_eip);
lkcd_print(" dh_num_pages: %d\n", dh->dh_num_pages);
lkcd_print(" dh_panic_string: %s%s", dh->dh_panic_string,
- dh && dh->dh_panic_string &&
- strstr(dh->dh_panic_string, "\n") ? "" : "\n");
+ dh && strstr(dh->dh_panic_string, "\n") ? "" : "\n");
lkcd_print(" dh_time: %s\n",
strip_linefeeds(ctime(&(dh->dh_time.tv_sec))));
diff --git a/lkcd_v2_v3.c b/lkcd_v2_v3.c
index 8635a7b..edcb663 100644
--- a/lkcd_v2_v3.c
+++ b/lkcd_v2_v3.c
@@ -307,8 +307,7 @@ dump_header_only:
lkcd_print(" dh_num_pages: ");
lkcd_print(BITS32() ? "%ld\n" : "%d\n", dh->dh_num_pages);
lkcd_print(" dh_panic_string: %s%s", dh->dh_panic_string,
- dh && dh->dh_panic_string &&
- strstr(dh->dh_panic_string, "\n") ? "" : "\n");
+ dh && strstr(dh->dh_panic_string, "\n") ? "" : "\n");
lkcd_print(" dh_time: %s\n",
strip_linefeeds(ctime(&(dh->dh_time.tv_sec))));
diff --git a/lkcd_v5.c b/lkcd_v5.c
index cb7634d..e3bfa6f 100644
--- a/lkcd_v5.c
+++ b/lkcd_v5.c
@@ -270,8 +270,7 @@ dump_header_only:
lkcd_print(" dh_num_pages: ");
lkcd_print(BITS32() ? "%ld\n" : "%d\n", dh->dh_num_pages);
lkcd_print(" dh_panic_string: %s%s", dh->dh_panic_string,
- dh && dh->dh_panic_string &&
- strstr(dh->dh_panic_string, "\n") ? "" : "\n");
+ dh && strstr(dh->dh_panic_string, "\n") ? "" : "\n");
lkcd_print(" dh_time: %s\n",
strip_linefeeds(ctime(&(dh->dh_time.tv_sec))));
diff --git a/lkcd_v7.c b/lkcd_v7.c
index 608e148..97d9900 100644
--- a/lkcd_v7.c
+++ b/lkcd_v7.c
@@ -347,8 +347,7 @@ dump_header_only:
lkcd_print(" dh_num_pages: ");
lkcd_print(BITS32() ? "%ld\n" : "%d\n", dh->dh_num_pages);
lkcd_print(" dh_panic_string: %s%s", dh->dh_panic_string,
- dh && dh->dh_panic_string &&
- strstr(dh->dh_panic_string, "\n") ? "" : "\n");
+ dh && strstr(dh->dh_panic_string, "\n") ? "" : "\n");
lkcd_print(" dh_time: %s\n",
strip_linefeeds(ctime(&(dh->dh_time.tv_sec))));
diff --git a/lkcd_v8.c b/lkcd_v8.c
index 3b355e0..4167fa5 100644
--- a/lkcd_v8.c
+++ b/lkcd_v8.c
@@ -543,8 +543,7 @@ dump_header_only:
lkcd_print(" dh_num_pages: ");
lkcd_print(BITS32() ? "%ld\n" : "%d\n", dh->dh_num_pages);
lkcd_print(" dh_panic_string: %s%s", dh->dh_panic_string,
- dh && dh->dh_panic_string &&
- strstr(dh->dh_panic_string, "\n") ? "" : "\n");
+ dh && strstr(dh->dh_panic_string, "\n") ? "" : "\n");
tv.tv_sec = dh->dh_time.tv_sec;
lkcd_print(" dh_time: %s\n",
strip_linefeeds(ctime(&(tv.tv_sec))));
--
2.37.1
1 year, 10 months
