Hi Xianting
On Mon, Aug 1, 2022 at 2:36 AM Xianting Tian
<xianting.tian(a)linux.alibaba.com> wrote:
 在 2022/8/1 上午10:09, Yixun Lan 写道:
 > HI Xianting:
 >
 > On Sat, Jul 30, 2022 at 8:56 AM Xianting Tian
 > <xianting.tian(a)linux.alibaba.com> wrote:
 >>
 >> 在 2022/7/30 上午7:29, Yixun Lan 写道:
 >>> HI Xianting
 >>>
 >>> On Fri, Jul 29, 2022 at 3:11 PM Xianting Tian
 >>> <xianting.tian(a)linux.alibaba.com> wrote:
 >>>> 在 2022/7/29 下午9:44, Yixun Lan 写道:
 >>>>> Hi Xianting
 >>>>>
 >>>>> On Mon, Jul 18, 2022 at 2:55 AM Xianting Tian
 >>>>> <xianting.tian(a)linux.alibaba.com> wrote:
 >>>>>> 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 and so on).
 >>>>>>
 >>>>>> To make the crash tool work normally for RISCV64 arch, we need a
Linux kernel
 >>>>>> patch(under reviewing), 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 patches:
 >>>>>>
https://lore.kernel.org/linux-riscv/20220717101323.370245-1-xianting.tian...
 >>>>>>
 >>>>>> This series of patches are tested on QEMU RISCV64 env and SoC
platform of
 >>>>>> T-head Xuantie 910 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
 >>>>>>
 >>>>>> Xianting Tian (8):
 >>>>>>      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 'mach' command support
 >>>>>>      RISCV64: Add the implementation of symbol verify
 >>>>>>
 >>>>>>     Makefile            |    7 +-
 >>>>>>     README              |    2 +-
 >>>>>>     configure.c         |   39 +-
 >>>>>>     defs.h              |  248 +++++++-
 >>>>>>     diskdump.c          |   21 +-
 >>>>>>     help.c              |    2 +-
 >>>>>>     lkcd_vmdump_v2_v3.h |    2 +-
 >>>>>>     netdump.c           |   22 +-
 >>>>>>     ramdump.c           |    2 +
 >>>>>>     riscv64.c           | 1414
+++++++++++++++++++++++++++++++++++++++++++
 >>>>>>     symbols.c           |   10 +
 >>>>>>     11 files changed, 1759 insertions(+), 10 deletions(-)
 >>>>>>     create mode 100644 riscv64.c
 >>>>>>
 >>>>>> --
 >>>>>> 2.17.1
 >>>>>>
 >>>>> I'm actually having problem with these patch set, got a
compiling error:
 >>>>>
 >>>>> === error log ===
 >>>>> riscv64-unknown-linux-gnu-gcc -c -g -DRISCV64  -DGDB_10_2 -O2 -pipe
 >>>>> lkcd_common.c
 >>>>> riscv64-unknown-linux-gnu-gcc -c -g -DRISCV64  -DGDB_10_2 -O2 -pipe
 >>>>> lkcd_v1.c -DMCLX
 >>>>> riscv64-unknown-linux-gnu-gcc -c -g -DRISCV64  -DGDB_10_2 -O2 -pipe
 >>>>> lkcd_v2_v3.c -DMCLX
 >>>>> In file included from lkcd_v1.c:21:
 >>>>> lkcd_vmdump_v1.h:121:30: error: field ‘dh_regs’ has incomplete type
 >>>>>      121 |         struct pt_regs       dh_regs;
 >>>>>          |                              ^~~~~~~
 >>>>> make[5]: *** [Makefile:385: lkcd_v1.o] Error 1
 >>>>> make[5]: *** Waiting for unfinished jobs....
 >>>>> In file included from lkcd_v2_v3.c:21:
 >>>>> lkcd_vmdump_v2_v3.h:90:30: error: field ‘dha_regs’ has incomplete
type
 >>>>>       90 |         struct pt_regs       dha_regs;
 >>>>>          |                              ^~~~~~~~
 >>>>> make[5]: *** [Makefile:388: lkcd_v2_v3.o] Error 1
 >>>>> make[4]: *** [Makefile:1871: gdb] Error 2
 >>>>> make[3]: *** [Makefile:10072: all-gdb] Error 2
 >>>>> make[2]: *** [Makefile:860: all] Error 2
 >>>>>
 >>>>> crash build failed
 >>>> It's strange, actually I didn't meet such compiling error by
'make
 >>>> target=RISCV64', the compiling is OK.
 >>>>
 >>>> Do you have more details for the build?
 >>>>
 >>> FYI, I'm using source code of crash, commit: f37df7df8a50
 >>> I don't think it's necessary to pass 'target' variable
explicitly, see
 >>> the comment of Makefile
 >>>
 >>> ==== snip of Makefile
 >>> # target could be set on command line when invoking make. Like: make
target=ARM
 >>> # otherwise target will be the same as the host
 >>> ifneq ($(target),)
 >>> CONF_TARGET_FLAG="-t$(target)"
 >>> endif
 >>> ====
 >>>
 >>> besides, it actually recognized the correct target successfully
 >>>
 >>> ==== snip of build log
 >>> make -j8 CC=riscv64-unknown-linux-gnu-gcc
 >>> AR=riscv64-unknown-linux-gnu-ar 'CFLAGS=-O2 -pipe'
'LDFLAGS=-Wl,-O1
 >>> -Wl,--as-needed'
 >>> TARGET: RISCV64
 >>>    CRASH: 8.0.1++
 >>>      GDB: 10.2
 >>> ====
 >> Sorry, I don't quite understand, we usually build crash tool on x86_64
 >> for analyzing other ARCH's vmcore.
 >>
 >> As README shows, we need type target=XXX for analyzing XXX arch vmcore.
 >> If we only use 'make' to build on X86_64, it is used to analyze
x86_64's
 >> vmcore.
 >>
 >> I don't think "make -j8 CC=riscv64-unknown-linux-gnu-gcc" is ok
for the
 >> build.  If I am wrong, please correct me. thanks
 >>
 > the difference is :
 > I'm here using native compiling approach for crash utility, which mean
 > the host OS distro is also a riscv64 (lp64d) Linux.
 >
 > # uname -a
 > Linux unmatch 5.18.15-gentoo-riscv64 #1 SMP Sat Jul 30 20:12:16 CST
 > 2022 riscv64 GNU/Linux
 >
 > this should also work as expected which already proved by arm64/ppc/etc..
 Thanks, seems not all ARCHs support such build.
 Anyway, I will add your fix as a separate patch to be included by my
 patch set, and add "Co-developed-by: Yixun Lan <yixun.lan(a)gmail.com>"
 
hey, I think it's not quite an independent patch, so I'm totally fine
with it folding into other patches,
and since it's trivial, I don't mind dropping the "Co-developed-by"
tag,
instead if you like, you can add my "Tested-by" tag
thanks
Yixun