August 2022 - Crash-utility - Crash Utility List Archives

Re: [Crash-utility] Kernel Crash Analysis on Android

by Shankar, AmarX

Hi Dave, Thanks for your info regarding kexec tool. I am unable to download kexec from below link. http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-too... It says HTTP 404 Page Not Found. Could you please guide me on this? Thanks & Regards, Amar Shankar > On Wed, Mar 21, 2012 at 06:00:00PM +0000, Shankar, AmarX wrote: > > > I want to do kernel crash Analysis on Android Merrifield Target. > > > > Could someone please help me how to do it? > > Merrifield is pretty much similar than Medfield, e.g it has x86 core. So I > guess you can follow the instructions how to setup kdump on x86 (see > Documentation/kdump/kdump.txt) unless you already have that configured. > > crash should support this directly presuming you have vmlinux/vmcore files to > feed it. You can configure crash to support x86 on x86_64 host by running: > > % make target=X86 > & make > > (or something along those lines). Right -- just the first make command will suffice, i.e., when running on an x86_64 host: $ wget http://people.redhat.com/anderson/crash-6.0.4.tar.gz $ tar xzf crash-6.0.4.tar.gz ... $ cd crash-6.0.4 $ make target=X86 ... $ ./crash <path-to>/vmlinux <path-to>/vmcore Dave From: Shankar, AmarX Sent: Wednesday, March 21, 2012 11:30 PM To: 'crash-utility(a)redhat.com' Subject: Kernel Crash Analysis on Android Hi, I want to do kernel crash Analysis on Android Merrifield Target. Could someone please help me how to do it? Thanks & Regards, Amar Shankar

10 months, 1 week

2
1
0 / 0

[PATCH] kmem, snap: iomem/ioport display and vmcore snapshot support

by HATAYAMA Daisuke

Some days ago I was in a situation that I had to convert vmcore in kvmdump format into ELF since some extension module we have locally can be used only on relatively old crash utility, around version 4, but such old crash utility cannot handle kvmdump format. To do the conversion in handy, I used snap command with some modifications so that it tries to use iomem information in vmcore instead of host's /proc/iomem. This patch is its cleaned-up version. In this development, I naturally got down to also making an interface for an access to resource objects, and so together with the snap command's patch, I also extended kmem command for iomem/ioport support. Actually: kmem -r displays /proc/iomem crash> kmem -r 00000000-0000ffff : reserved 00010000-0009dbff : System RAM 0009dc00-0009ffff : reserved 000c0000-000c7fff : Video ROM ... and kmem -R displays /proc/ioport crash> kmem -R 0000-001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 ... Looking into old version of kernel source code back, resource structure has been unchanged since linux-2.4.0. I borrowed the way of walking on resouce tree in this patch from the lastest v3.3-rc series, but I guess the logic is also applicable to old kernels. I expect Dave's regression testsuite. Also, there would be another command more sutable for iomem/ioport. If necessay, I'll repost the patch. --- HATAYAMA Daisuke (4): Add vmcore snapshot support Add kmem -r and -R options Add dump iomem/ioport functions; a helper for resource objects Add a helper function for iterating resource objects defs.h | 9 ++++ extensions/snap.c | 54 ++++++++++++++++++++++- help.c | 2 + memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 4 files changed, 180 insertions(+), 7 deletions(-) -- Thanks. HATAYAMA Daisuke

10 months, 1 week

2
4
0 / 0

Re: [Crash-utility] question about phys_base

by Dave Anderson

----- Original Message ----- > > > > OK, so then I don't understand what you mean by "may be the same"? > > > > You didn't answer my original question, but if I understand you correctly, > > it would be impossible for the qemu host to create a PT_LOAD segment that > > describes an x86_64 guest's __START_KERNEL_map region, because the host > > doesn't know that what kind of kernel the guest is running. > > Yes. Even if the guest is linux, it is still impossible to do it. Because > the guest maybe in the second kernel. > > qemu-dump walks all guest's page table and collect virtual address and > physical address mapping. If the page is not used by guest, the virtual is set > to 0. I create PT_LOAD according to such mapping. So if the guest is linux, > there may be a PT_LOAD segment that describes __START_KERNEL_map region. > But the information stored in PT_LOAD maybe for the second kernel. If crash > uses it, crash will see the second kernel, not the first kernel. Just to be clear -- what do you mean by the "second" kernel? Do you mean that a guest kernel crashed guest, and did a kdump operation, and that second kdump kernel failed somehow, and now you're trying to do a "virsh dump" on the kdump kernel? Dave

10 months, 1 week

3
16
0 / 0

[PATCH makedumpfile 0/2] LZO Compression Support

by HATAYAMA Daisuke

The following series implements LZO compression support to makedumpfile. LZO is as good as in size but by far better in speed than ZLIB, readucing down time during generation of crash dump and refiltering. The RFC discussion: http://lists.infradead.org/pipermail/kexec/2011-November/005783.html http://lists.infradead.org/pipermail/kexec/2011-December/005868.html How to build: 1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of the following: 1) Original author's website: http://www.oberhumer.com/opensource/lzo/ 2) yum framework on fedora. Older releases don't have the packages. 2. Apply the patch set to makedumpfile v1.4.2. 3. Do make. How to use: Introduce new -l option. If a user specify this, makedumpfile generates dumpfile compressed by pages with lzo compression. Example) $ makedumpfile -l vmcore dumpfile Performance evaluation: - Kumagai-san's evaluation simulating actually working servers: http://lists.infradead.org/pipermail/kexec/2011-December/005868.html - My evaluation focusing on the worst cases: http://lists.infradead.org/pipermail/kexec/2011-November/005783.html LZO Support for crash: I'll post LZO support patch for crash after makedumpfile merges these patches. --- HATAYAMA Daisuke (2): Add help and manual messages about LZO compression support Add LZO Support Makefile | 2 +- diskdump_mod.h | 3 ++- makedumpfile.8 | 6 +++--- makedumpfile.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++--------- makedumpfile.h | 2 ++ print_info.c | 16 ++++++++-------- 6 files changed, 64 insertions(+), 22 deletions(-) -- HATAYAMA Daisuke

10 months, 1 week

2
6
0 / 0

question about phys_base

by Wen Congyang

Hi, Dave I am implementing a new dump command in the qemu. The vmcore's format is elf(like kdump). And I try to provide phys_base in the PT_LOAD. But if the os uses the first vcpu do kdump, the value of phys_base is wrong. I find a function x86_64_virt_phys_base() in crash's code. Is it OK to call this function first? If the function successes, we do not calculate phys_base according to PT_LOAD. Thanks Wen Congyang

10 months, 1 week

3
6
0 / 0

[PATCH] runq: search current task's runqueue explicitly

by HATAYAMA Daisuke

Currently, runq sub-command doesn't consider CFS runqueue's current task removed from CFS runqueue. Due to this, the remaining CFS runqueus that follow the current task's is not displayed. This patch fixes this by making runq sub-command search current task's runqueue explicitly. Note that CFS runqueue exists for each task group, and so does CFS runqueue's current task, and the above search needs to be done recursively. Test ==== On vmcore I made 7 task groups: root group --- A --- AA --- AAA + +- AAB | +- AB --- ABA +- ABB and then I ran three CPU bound tasks, which is exactly the same as int main(void) { for (;;) continue; return 0; } for each task group, including root group; so total 24 tasks. For readability, I annotated each task name with its belonging group name. For example, loop.ABA belongs to task group ABA. Look at CPU0 collumn below. [before] lacks 8 tasks and [after] successfully shows all tasks on the runqueue, which is identical to the result of [sched debug] that is expected to ouput correct result. I'll send this vmcore later. [before] crash> runq | cat CPU 0 RUNQUEUE: ffff88000a215f80 CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA" RT PRIO_ARRAY: ffff88000a216098 [no tasks queued] CFS RB_ROOT: ffff88000a216010 [120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA" <cut> [after] crash_fix> runq CPU 0 RUNQUEUE: ffff88000a215f80 CURRENT: PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA" RT PRIO_ARRAY: ffff88000a216098 [no tasks queued] CFS RB_ROOT: ffff88000a216010 [120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA" [120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB" [120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB" [120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB" [120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB" [120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA" [120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA" [120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA" [120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A" <cut> [sched debug] crash> runq -d CPU 0 [120] PID: 28232 TASK: ffff880079b5d4c0 COMMAND: "loop.A" [120] PID: 28239 TASK: ffff8800785774c0 COMMAND: "loop.AA" [120] PID: 28240 TASK: ffff880078617580 COMMAND: "loop.AA" [120] PID: 28241 TASK: ffff880078616b40 COMMAND: "loop.AA" [120] PID: 28245 TASK: ffff8800785e8b00 COMMAND: "loop.AB" [120] PID: 28246 TASK: ffff880078628ac0 COMMAND: "loop.AB" [120] PID: 28262 TASK: ffff880037cc40c0 COMMAND: "loop.ABA" [120] PID: 28263 TASK: ffff880037aaa040 COMMAND: "loop.ABA" [120] PID: 28271 TASK: ffff8800787a8b40 COMMAND: "loop.ABB" [120] PID: 28272 TASK: ffff880037afd580 COMMAND: "loop.ABB" <cut> Diff stat ========= defs.h | 1 + task.c | 37 +++++++++++++++++-------------------- 2 files changed, 18 insertions(+), 20 deletions(-) Thanks. HATAYAMA, Daisuke

10 months, 1 week

2
2
0 / 0

[RFC] makedumpfile, crash: LZO compression support

by HATAYAMA Daisuke

Hello, This is a RFC patch set that adds LZO compression support to makedumpfile and crash utility. LZO is as good as in size but by far better in speed than ZLIB, leading to reducing down time during generation of crash dump and refiltering. How to build: 1. Get LZO library, which is provided as lzo-devel package on recent linux distributions, and is also available on author's website: http://www.oberhumer.com/opensource/lzo/. 2. Apply the patch set to makedumpfile v1.4.0 and crash v6.0.0. 3. Build both using make. But for crash, do the following now: $ make CFLAGS="-llzo2" How to use: I've newly used -l option for lzo compression in this patch. So for example, do as follows: $ makedumpfile -l vmcore dumpfile $ crash vmlinux dumpfile Request of configure-like feature for crash utility: I would like configure-like feature on crash utility for users to select wheather to add LZO feature actually or not in build-time, that is: ./configure --enable-lzo or ./configure --disable-lzo. The reason is that support staff often downloads and installs the latest version of crash utility on machines where lzo library is not provided. Looking at the source code, it looks to me that crash does some kind of configuration processing in a local manner, around configure.c, and I guess it's difficult to use autoconf tools directly. Or is there another better way? Performance Comparison: Sample Data Ideally, I must have measured the performance for many enough vmcores generated from machines that was actually running, but now I don't have enough sample vmcores, I couldn't do so. So this comparison doesn't answer question on I/O time improvement. This is TODO for now. Instead, I choosed worst and best cases regarding compression ratio and speed only. Specifically, the former is /dev/urandom and the latter is /dev/zero. I get the sample data of 10MB, 100MB and 1GB by doing like this: $ dd bs=4096 count=$((1024*1024*1024/4096)) if=/dev/urandom of=urandom.1GB How to measure Then I performed compression for each block, 4096 bytes, and measured total compression time and output size. See attached mycompress.c. Result See attached file result.txt. Discussion For both kinds of data, lzo's compression was considerably quicker than zlib's. Compression ratio is about 37% for urandom data, and about 8.5% for zero data. Actual situation of physical memory would be in between the two cases, and so I guess average compression time ratio is between 37% and 8.5%. Although beyond the topic of this patch set, we can estimate worst compression time on more data size since compression is performed block size wise and the compression time increases linearly. Estimated worst time on 2TB memory is about 15 hours for lzo and about 40 hours for zlib. In this case, compressed data size is larger than the original, so they are really not used, compression time is fully meaningless. I think compression must be done in parallel, and I'll post such patch later. Diffstat * makedumpfile diskdump_mod.h | 3 +- makedumpfile.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++------ makedumpfile.h | 12 +++++++ 3 files changed, 101 insertions(+), 12 deletions(-) * crash defs.h | 1 + diskdump.c | 20 +++++++++++++++++++- diskdump.h | 3 ++- 3 files changed, 22 insertions(+), 2 deletions(-) TODO * evaluation including I/O time using actual vmcores Thanks. HATAYAMA, Daisuke

10 months, 1 week

3
15
0 / 0

Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format

by tachibana＠mxm.nes.nec.co.jp

Hi Hatayama-san, On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote: > From: Dave Anderson <anderson(a)redhat.com> > Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format > Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT) > > > > > > > ----- Original Message ----- > >> Fujitsu has stand-alone dump mechanism based on firmware level > >> functionality, which we call SADUMP, in short. > >> > >> We've maintained utility tools internally but now we're thinking that > >> the best is crash utility and makedumpfile supports the sadump format > >> for the viewpoint of both portability and maintainability. > >> > >> We'll be of course responsible for its maintainance in a continuous > >> manner. The sadump dump format is very similar to diskdump format and > >> so kdump (compressed) format, so we estimate patch set would be a > >> relatively small size. > >> > >> Could you tell me whether crash utility and makedumpfile can support > >> the sadump format? If OK, we'll start to make patchset. I think it's not bad to support sadump by makedumpfile. However I have several questions. - Do you want to use makedumpfile to make an existing file that sadump has dumped small? - It isn't possible to support the same form as kdump-compressed format now, is it? - When the information that makedumpfile reads from a note of /proc/vmcore (or a header of kdump-compressed format) is added by an extension of makedumpfile, do you need to modify sadump? Thanks tachibana > > > > Sure, yes, the crash utility can always support another dumpfile format. > > > > Thanks. It helps a lot. > > > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump. > > Does your internal version patch diskdump.c, or do you maintain your > > own "sadump.c"? I ask because if your patchset is at all intrusive, > > I'd prefer it be kept in its own file, primarily for maintainability, > > but also because SADUMP is essentially a black-box to anybody outside > > Fujitsu. > > What I meant when I used ``similar'' is both literally and > logically. The format consists of diskdump header-like header, two > kinds of bitmaps used for the same purpose as those in diskump format, > and memory data. They can be handled in common with the existing data > structure, diskdump_data, non-intrusively, so I hope they are placed > in diskdump.c. > > On the other hand, there's a code to be placed at such specific > area. sadump is triggered depending on kdump's progress and so > register values to be contained in vmcore varies according to the > progress: If crash_notes has been initialized when sadump is > triggered, sadump packs the register values in crash_notes; if not > yet, packs registers gathered by firmware. This is sadump specific > processing, so I think putting it in specific sadump.c file is a > natural and reasonable choise. > > Anyway, I have not made any patch set for this. I'll post a patch set > when I complete. > > Again, thanks a lot for the positive answer. > > Thanks. > HATAYAMA, Daisuke > > > _______________________________________________ > kexec mailing list > kexec(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec

10 months, 1 week

3
5
0 / 0

[PATCH V6 0/6] RISC-V fixups to work with crash tool

by Xianting Tian

I ever sent the patch 1 in the link: https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352... And patch 2,3 in the link: https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367... https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367... This patch set just put these patches together, and with three new patch 4, 5, 6. these six patches are the fixups for machine_kexec, kernel mode PC for vmcore and improvements for vmcoreinfo, memory layout dump and fixup schedule out issue in machine_crash_shutdown(). The main changes in the six patchs as below, Patch 1: Fixup use of smp_processor_id() in preemptible context, to cleanup the console prints. Patch 2: Fixup to get correct kernel mode PC for kernel mode regs for vmcore. Patch 3: Fixup schedule out issue in machine_crash_shutdown() Patch 4: Add modules to virtual kernel memory layout dump. Patch 5: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify the development of crash tool as ARM64 already did (arch/arm64/kernel/crash_core.c). Patch 6: Updates vmcoreinfo.rst for vmcoreinfo export for RISCV64. With these six patches(patch 2 is must), crash tool can work well to analyze a vmcore. The patches for crash tool for RISCV64 is in the link: https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.tia... ------ Changes v1 -> v2: 1, remove the patch "Add a fast call path of crash_kexec()" from this series of patches, as it already applied to riscv git. https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h... 2, add 'Reviewed-by' based on the comments of v1. Changes v2 -> v3: use "riscv" instead of "riscv64" in patch 5 subject line. Changes v3 -> v4: use "riscv" instead of "riscv64" in the summary of patch 5 subject line. Changes v4 -> v5: add a new patch "RISC-V: Fixup schedule out issue in machine_crash_shutdown()" Changes v5 -> v6: 1, move "fixup" patches to the start of the patch set. 2, change patch 1, 2, 6's subject to make it tell more what it's about. 3, add Fixes for patch 3. 4, adjuest the changes format for patch 6. Xianting Tian (6): RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context RISC-V: Fixup get incorrect user mode PC for kernel mode regs RISC-V: Fixup schedule out issue in machine_crash_shutdown() RISC-V: Add modules to virtual kernel memory layout dump RISC-V: Add arch_crash_save_vmcoreinfo support Documentation: kdump: describe VMCOREINFO export for RISCV64 .../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++ arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++ arch/riscv/kernel/crash_save_regs.S | 2 +- arch/riscv/kernel/machine_kexec.c | 28 ++++++++++++++--- arch/riscv/mm/init.c | 4 +++ 6 files changed, 89 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/kernel/crash_core.c -- 2.17.1

1 year, 11 months

6
17
0 / 0

[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

2 years

4
18
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Crash-utility August 2022