在 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
README:
   The crash binary can only be used on systems of the same architecture as
   the host build system.  There are a few optional manners of building the
   crash binary:
   o  On an x86_64 host, a 32-bit x86 binary that can be used to analyze
      32-bit x86 dumpfiles may be built by typing "make target=X86".
   o  On an x86 or x86_64 host, a 32-bit x86 binary that can be used to 
analyze
      32-bit arm dumpfiles may be built by typing "make target=ARM".
   o  On an x86 or x86_64 host, a 32-bit x86 binary that can be used to 
analyze
      32-bit mips dumpfiles may be built by typing "make target=MIPS".
   o  On an ppc64 host, a 32-bit ppc binary that can be used to analyze
      32-bit ppc dumpfiles may be built by typing "make target=PPC".
   o  On an x86_64 host, an x86_64 binary that can be used to analyze
      arm64 dumpfiles may be built by typing "make target=ARM64".
   o  On an x86_64 host, an x86_64 binary that can be used to analyze
      ppc64le dumpfiles may be built by typing "make target=PPC64".
   o  On an x86_64 host, an x86_64 binary that can be used to analyze
      riscv64 dumpfiles may be built by typing "make target=RISCV64".
 please check [1] for full build log
 [1] 
https://dev.gentoo.org/~dlan/logs/crash-build.log.xz
>> =====
>> and this error can be fixed by applying the following patch,
>> can you help to double check if it's a correct fix?
>>
>> diff --git a/lkcd_vmdump_v1.h b/lkcd_vmdump_v1.h
>> index 4933427..f6c4a26 100644
>> --- a/lkcd_vmdump_v1.h
>> +++ b/lkcd_vmdump_v1.h
>> @@ -118,10 +118,12 @@ typedef struct _dump_header_s {
>>    #ifndef S390
>>    #ifndef S390X
>>    #ifndef ARM64
>> +#ifndef RISCV64
>>           struct pt_regs       dh_regs;
>>    #endif
>>    #endif
>>    #endif
>> +#endif
>>    #endif
>>
>>           /* the address of the current task */
>> diff --git a/lkcd_vmdump_v2_v3.h b/lkcd_vmdump_v2_v3.h
>> index 7fa70b9..6d4fd27 100644
>> --- a/lkcd_vmdump_v2_v3.h
>> +++ b/lkcd_vmdump_v2_v3.h
>> @@ -87,10 +87,12 @@ typedef struct _dump_header_asm_s {
>>    #ifndef S390
>>    #ifndef S390X
>>    #ifndef ARM64
>> +#ifndef RISCV64
>>           struct pt_regs       dha_regs;
>>    #endif
>>    #endif
>>    #endif
>> +#endif
>>
>>    } dump_header_asm_t;
>>
>> ===
>>
>> Yixun Lan