7:15 a.m.
Hi Tao,
On Fri, Dec 15, 2023 at 06:54:52PM +0800, Tao Liu wrote:
Hi Aditya,
On Fri, Dec 15, 2023 at 4:00 PM Aditya Gupta <adityag(a)linux.ibm.com> wrote:
>
> The Problem:
> ============
>
> Currently crash is unable to show function arguments and local variables, as
> gdb can do. And functionality for moving between frames
('up'/'down') is not
> working in crash.
>
> Crash has 'gdb passthroughs' for things gdb can do, but the gdb
passthroughs
> 'bt', 'frame', 'info locals', 'up', 'down'
are not working either, due to
> gdb not getting the register values from `crash_target::fetch_registers`,
> which then uses `machdep->get_cpu_reg`, which is not implemented for PPC64
>
> Proposed Solution:
> ==================
>
> Fix the gdb passthroughs by implementing "machdep->get_cpu_reg" for
PPC64.
> This way, "gdb mode in crash" will support this feature for both ELF and
> kdump-compressed vmcore formats, while "gdb" would only have supported
ELF
> format
>
> This way other features of 'gdb', such as seeing
> backtraces/registers/variables/arguments/local variables, moving up and
> down stack frames, can be used with any ppc64 vmcore, irrespective of
> being ELF format or kdump-compressed format.
>
> Note: This doesn't support live debugging on ppc64, since registers are not
> available to be read
I tried to enable live debugging on ppc64 arch based on your patch but
failed. I cannot get the saved register state from kernel:
task_struct-> thread_struct -> struct pt_regs *regs. The "regs" value
I read is always 0.
Thanks for trying that. This is based on my observation, but the 'regs' should
not be NULL for most threads, but yes, it is NULL for let's say PID 0, which is
the default we have in crash during live debug session.
Such as I found the PID for my current crash process using 'pgrep -a crash',
then used the 'task' command in crash to get the information, it showed some
value for 'thread.regs', which I dump with 'x' to get registers:
crash> task 26657
PID: 26657 TASK: c00000000dc61780 CPU: 27 COMMAND: "crash"
struct task_struct {
...
thread = {
ksp = 13835058056980675152,
ksp_vsid = 0,
regs = 0xc0000000653d3e80,
...
}
crash> x/40g 0xc0000000653d3e80
0xc0000000653d3e80: 0x00000000000000b3 0x00007ffffcafe9f0
0xc0000000653d3e90: 0x0000000010c47a00 0x0000000000000004
0xc0000000653d3ea0: 0x000000001bbc0440 0x0000000000000008
0xc0000000653d3eb0: 0x00000000653e3eb0 0x00007fff943180c0
0xc0000000653d3ec0: 0x00007fff94310988 0x0000000000000000
0xc0000000653d3ed0: 0x0000000000000000 0x0000000000000000
0xc0000000653d3ee0: 0x0000000000000000 0x00007fff943180c0
0xc0000000653d3ef0: 0x0000000000000000 0xc0000000653d3ef0
0xc0000000653d3f00: 0x000000001096d5f8 0x0000000080000000
0xc0000000653d3f10: 0x0000000000000000 0x00007ffffcafeb28
0xc0000000653d3f20: 0xffffffffffffdfff 0x0000000010c41bc8
0xc0000000653d3f30: 0x0000000000000008 0x0000000000000004
0xc0000000653d3f40: 0x000000001095ebe0 0x0000000010c41bf0
0xc0000000653d3f50: 0x000000001cbfd460 0xc0000000653d3f58
0xc0000000653d3f60: 0x000000001cbfd460 0x0000000000000004
0xc0000000653d3f70: 0x0000000000000000 0x00000000653e3f78
0xc0000000653d3f80: 0x00007fff93d379a4 0x800000000280f033
0xc0000000653d3f90: 0x0000000000000004 0x0000000000000000
0xc0000000653d3fa0: 0x0000000000000000 0x0000000000000000
0xc0000000653d3fb0: 0x0000000044882284 0x0000000000000000
Here the first 32 8-byte values should be the General Purpose Registers on
PPC64, the 33rd 8-byte value (0x00007fff93d379a4) should be NIP, and 34th
should be Machine State Register (MSR), ie. (0x800000000280f033), and so on
So it should be able to get some registers, but for PID 0 atleast the .regs is
NULL.
That said, I think it might be more effort to implement this feature on live
debugging.
Currently this feature requires the current context to be set to the CPU for
the task/thread we want the backtrace for.
But on crash side, changing cpu context is not allowed in live debugging. And on
gdb side, we add only as many threads as the number of CPUs, in
'crash_target_init'. Both might have to be changed to allow support in live
debugging, but for that I guess tools like 'drgn' are already doing good.
Thanks,
Aditya Gupta