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.
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
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
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
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
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
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
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>
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
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;
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
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
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
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
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
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
16 matches
Mail list logo