Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to show text symbols of command output #112

Open
yangxingwu opened this issue Jan 18, 2022 · 1 comment
Open

how to show text symbols of command output #112

yangxingwu opened this issue Jan 18, 2022 · 1 comment

Comments

@yangxingwu
Copy link

It will be helpful if crash could show the corresponding symbols of command output

for example

crash> list packet_offload.list  -H offload_base -s packet_offload
ffffffff81b41bc0
struct packet_offload {
  type = 8,
  priority = 0,
  callbacks = {
    gso_segment = 0xffffffff816155b0 <inet_gso_segment>,
    gro_receive = 0xffffffff816159a0 <inet_gro_receive>,
    gro_complete = 0xffffffff816148c0 <inet_gro_complete>
  },
  list = {
    next = 0xffffffff81b43b40 <ipv6_packet_offload+32>,
    prev = 0xffffffff81b3f0e0 <offload_base>
  }
}

But I can NOT get the symbols when running the same CLI on my own server:

crash> list packet_offload.list  -H offload_base -s packet_offload
ffffffff81b41bc0
struct packet_offload {
  type = 8,
  priority = 0,
  callbacks = {
    gso_segment = 0xffffffff816155b0,
    gro_receive = 0xffffffff816159a0,
    gro_complete = 0xffffffff816148c0
  },
  list = {
    next = 0xffffffff81b43b40,
    prev = 0xffffffff81b3f0e0
  }
}
@k-hagio
Copy link
Contributor

k-hagio commented Jan 20, 2022

Not reproducible at my end.
What is the crash version, kernel version, architecture and distribution?

crash> list packet_offload.list -H offload_base -s packet_offload
ffffffffae02a8e0
struct packet_offload {
  type = 8,
  priority = 0,
  callbacks = {
    gso_segment = 0xffffffffad06ca80 <inet_gso_segment>,
    gro_receive = 0xffffffffad06b360 <inet_gro_receive>,
    gro_complete = 0xffffffffad06b6e0 <inet_gro_complete>
  },
  list = {
    next = 0xffffffffae02c100 <ipv6_packet_offload+32>,
    prev = 0xffffffffae028300 <offload_base>
  }
}
...

k-hagio pushed a commit that referenced this issue Dec 9, 2022
We met "bt" command on KASAN kernel vmcore display truncated backtraces
like this:

  crash> bt
  PID: 4131   TASK: ffff8001521df000  CPU: 3   COMMAND: "bash"
   #0 [ffff2000224b0cb0] machine_kexec_prepare at ffff2000200bff4c

After digging the root cause, it turns out that arm64_in_kdump_text()
found wrong bt->bptr at "machine_kexec" branch.

Disassemble machine_kexec() of KASAN vmlinux (gcc 7.3.0):

  crash> dis -x machine_kexec
  0xffff2000200bff50 <machine_kexec>:     stp     x29, x30, [sp,#-208]!
  0xffff2000200bff54 <machine_kexec+0x4>: mov     x29, sp
  0xffff2000200bff58 <machine_kexec+0x8>: stp     x19, x20, [sp,#16]
  0xffff2000200bff5c <machine_kexec+0xc>: str     x24, [sp,#56]
  0xffff2000200bff60 <machine_kexec+0x10>:        str     x26, [sp,#72]
  0xffff2000200bff64 <machine_kexec+0x14>:        mov     x2, #0x8ab3
  0xffff2000200bff68 <machine_kexec+0x18>:        add     x1, x29, #0x70
  0xffff2000200bff6c <machine_kexec+0x1c>:        lsr     x1, x1, #3
  0xffff2000200bff70 <machine_kexec+0x20>:        movk    x2, #0x41b5, lsl #16
  0xffff2000200bff74 <machine_kexec+0x24>:        mov     x19, #0x200000000000
  0xffff2000200bff78 <machine_kexec+0x28>:        adrp    x3, 0xffff2000224b0000
  0xffff2000200bff7c <machine_kexec+0x2c>:        movk    x19, #0xdfff, lsl #48
  0xffff2000200bff80 <machine_kexec+0x30>:        add     x3, x3, #0xcb0
  0xffff2000200bff84 <machine_kexec+0x34>:        add     x4, x1, x19
  0xffff2000200bff88 <machine_kexec+0x38>:        stp     x2, x3, [x29,#112]
  0xffff2000200bff8c <machine_kexec+0x3c>:        adrp    x2, 0xffff2000200bf000 <swsusp_arch_resume+0x1e8>
  0xffff2000200bff90 <machine_kexec+0x40>:        add     x2, x2, #0xf50
  0xffff2000200bff94 <machine_kexec+0x44>:        str     x2, [x29,#128]
  0xffff2000200bff98 <machine_kexec+0x48>:        mov     w2, #0xf1f1f1f1
  0xffff2000200bff9c <machine_kexec+0x4c>:        str     w2, [x1,x19]
  0xffff2000200bffa0 <machine_kexec+0x50>:        mov     w2, #0xf200
  0xffff2000200bffa4 <machine_kexec+0x54>:        mov     w1, #0xf3f3f3f3
  0xffff2000200bffa8 <machine_kexec+0x58>:        movk    w2, #0xf2f2, lsl #16
  0xffff2000200bffac <machine_kexec+0x5c>:        stp     w2, w1, [x4,#4]

We notice that:
1. machine_kexec() start address is 0xffff2000200bff50
2. the instruction at machine_kexec+0x44 stores the same value
   0xffff2000200bff50 (comes from 0xffff2000200bf000 + 0xf50)
   into stack postion [x29,#128].

When arm64_in_kdump_text() searches for LR from stack, it met
0xffff2000200bff50 firstly, so got wrong bt->bptr.

We know that the real LR is always greater than the start address
of a function, so let's fix it by changing the search conditon to
(*ptr > xxx_start) && (*ptr < xxx_end).

Signed-off-by: Ding Hui <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants