[Crash-utility] Re: [PATCH v4 ] Adding the zram decompression algorithm "lzo-rle" to support kernel versions >= 5.1

2024-04-27 Thread Yulong Tang
Hi, Lianbo Thanks for the improvement and testing. So, I'll add this modification into the latest patch by Kazu and submit the patch v5, right? Thanks Yulong -- Crash-utility mailing list -- devel@lists.crash-utility.osci.io To unsubscribe send an email to devel-le...@lists.crash-utility.osci.

[Crash-utility] [Crash-Utility][PATCH v2 00/13] gdb stack unwinding support for crash utility

2024-04-27 Thread Tao Liu
This patchset is a rebase/merged version of the following 3 patchsets: 1): [PATCH v10 0/5] Improve stack unwind on ppc64 [1] 2): [PATCH 0/5] x86_64 gdb stack unwinding support [2] 3): Clean up on top of one-thread-v2 [3] A complete description of gdb stack unwinding support for crash can be found

[Crash-utility] [Crash-Utility][PATCH v2 01/13] Remove 'frame' from prohibited commands list

2024-04-27 Thread Tao Liu
From: Aditya Gupta Currently, 'frame' is prohibited on every architecture, even in gdb mode. But with gdb stack unwinding working correctly on some architectures (eg. ppc64, x86_64, arm64), so remove it from prohibited list, so that 'frame' command can be used This has an implication on all arch

[Crash-utility] [Crash-Utility][PATCH v2 02/13] Leave only one gdb thread for crash

2024-04-27 Thread Tao Liu
This patch is a preparation of gdb stack unwinding support. There are 3 designs for supporting arbitrary tasks stack unwinding: 1) One gdb thread represent a task[1][2]. 2) One gdb thread represent a cpu[3]. 3) Leaving only one gdb thread[4]. 1 & 2 have a flaw that, when there are lots of tasks/c

[Crash-utility] [Crash-Utility][PATCH v2 03/13] Let crash change gdb context

2024-04-27 Thread Tao Liu
This patch is a preparation of gdb stack unwinding support. "set" command is extended with gdb context change: crash> set or crash> set Then the task context of crash and gdb will both be switched to pid/task, and the following command: "bt" "gdb bt" will output the same task context. Co-devel

[Crash-utility] [Crash-Utility][PATCH v2 04/13] Rename get_cpu_reg to get_current_task_reg

2024-04-27 Thread Tao Liu
Since we only leave one gdb thread, or 1 cpu thread, and can use cmd "set" to switch task context by reusing the thread. So the word "get_cpu_reg", which stands for "fetch registers' value for cpu thread x", is no longer appropriate, better using "get_current_task_reg", which stands for "fetch regi

[Crash-utility] [Crash-Utility][PATCH v2 05/13] Print task pid/command instead of CPU index

2024-04-27 Thread Tao Liu
This patch is a preparation of gdb stack unwinding support. "info threads" will output useful info for current task, such as pid, command, stack frame. Before the patch: crash> info threads Id Target Id Frame * 1CPU 0 crash_setup_regs (oldregs=0x0, newregs=0xbd1040

[Crash-utility] [Crash-Utility][PATCH v2 06/13] Fix gdb_interface: restore gdb's output streams at end of gdb_interface

2024-04-27 Thread Tao Liu
Currently for most gdb_interface call, in which a non-null file pointer is passed, GDB's output stream is replaced with the passed file pointer Due to this, 'info threads', which is a gdb passthrough, doesn't print any thread, after support was added to get registers from crash_target: crash>

[Crash-utility] [Crash-Utility][PATCH v2 07/13] Stop stack unwinding at non-kernel address

2024-04-27 Thread Tao Liu
The stack unwinding is for kernel addresses only. If non-kernel address encountered, it is usually a user space address, or non-address value like a function call parameter. So stopping stack unwinding at non-kernel address will decrease the invalid unwind results. Before: crash> gdb bt #0 0xfff

[Crash-utility] [Crash-Utility][PATCH v2 10/13] Parse stack by inactive_stack_frame priorily if the struct is valid

2024-04-27 Thread Tao Liu
Signed-off-by: Tao Liu --- x86_64.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/x86_64.c b/x86_64.c index 4ba0b40..54c69fd 100644 --- a/x86_64.c +++ b/x86_64.c @@ -6519,6 +6519,17 @@ x86_64_ORC_init(void) }; struct ORC_data *orc;

[Crash-utility] [Crash-Utility][PATCH v2 08/13] ppc64: correct gdb passthroughs by implementing machdep->get_cpu_reg

2024-04-27 Thread Tao Liu
From: Aditya Gupta Currently, gdb passthroughs of 'bt', 'frame', 'up', 'down', 'info locals' don't work. This is due to gdb not knowing the register values to unwind the stack frames Every gdb passthrough goes through `gdb_interface`. And then, gdb expects `crash_target::fetch_registers` to give

[Crash-utility] [Crash-Utility][PATCH v2 12/13] x86_64: Fix invalid input "=>" for bt command

2024-04-27 Thread Tao Liu
There may be extra "=>" prefix before gdb disassembly, as a result, parse_line() will return string "=>" as arglist[0], which will be converted to number by htol() and fails. E.g.: crash> gdb x/40i __list_del_entry ... 0x8133c384 <__list_del_entry+36>:cmp%rcx,%rax 0xff

[Crash-utility] [Crash-Utility][PATCH v2 09/13] x86_64: Add gdb stack unwinding support

2024-04-27 Thread Tao Liu
This patch will add stack unwinding support for x86_64 CPU arch. It follows the tech path of ppc64_get_stack_frame() & ppc64_get_cpu_reg() in ppc64.c, to get and consume the cpu regs. One different case is, we need to handle inactive_task_frame structure specifically in x86_64. If inactive_task_f

[Crash-utility] [Crash-Utility][PATCH v2 11/13] Fix cpumask_t recursive dependence issue

2024-04-27 Thread Tao Liu
There is recursive dependence for cpumask_t and will exhause the stack, see the following stack trace: (gdb) bt ...snip... #61965 0x005de98c in datatype_info (name=name@entry=0xa5b1fd "cpumask_t", member=member@entry=0x0, dm=dm@entry=0xfffc) at symbols.c:6694 #61966 0x

[Crash-utility] [Crash-Utility][PATCH v2 13/13] arm64: Add gdb stack unwinding support

2024-04-27 Thread Tao Liu
Signed-off-by: Tao Liu --- arm64.c | 114 +--- defs.h | 36 ++ 2 files changed, 145 insertions(+), 5 deletions(-) diff --git a/arm64.c b/arm64.c index af0e0d7..5f9be82 100644 --- a/arm64.c +++ b/arm64.c @@ -116,6 +116,23 @@ st

[Crash-utility] Re: [Crash-Utility][PATCH v2 00/13] gdb stack unwinding support for crash utility

2024-04-27 Thread Tao Liu
On Sun, Apr 28, 2024 at 12:02 PM Tao Liu wrote: > > This patchset is a rebase/merged version of the following 3 patchsets: > > 1): [PATCH v10 0/5] Improve stack unwind on ppc64 [1] > 2): [PATCH 0/5] x86_64 gdb stack unwinding support [2] > 3): Clean up on top of one-thread-v2 [3] > > A complete de