On 2023/02/22 18:36, lijiang wrote:
>>> On Wed, Feb 22, 2023 at 1:17 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab@nec.com <mailto:k-hagio-ab@nec.com>> wrote:
>>>
>>>     On 2023/02/21 12:03, Lianbo Jiang wrote:
>>>     > For gdb-10.2, the disassembly code may start with "=>", which needs to
>>>     > be stripped when calculating the address. Otherwise, parsing the address
>>>     > will fail because the current code always assumes that it starts with the
>>>     > "0x". For example:
>>>     >
>>>     >    crash> gdb disassemble 0xffffffffa2317add
>>>     >    Dump of assembler code for function native_queued_spin_lock_slowpath:
>>>     >       0xffffffffa2317ab0 <+0>:     nopl   0x0(%rax,%rax,1)
>>>     >       0xffffffffa2317ab5 <+5>:     push   %rbp
>>>     >       0xffffffffa2317ab6 <+6>:     mov    %rsp,%rbp
>>>     >       ...
>>>     >       0xffffffffa2317ad3 <+35>:    mov    %edx,%eax
>>>     >       0xffffffffa2317ad5 <+37>:    lock cmpxchg %ecx,(%rdi)
>>>     >    => 0xffffffffa2317ad9 <+41>:    cmp    %eax,%edx
>>>     >       0xffffffffa2317adb <+43>:    jne    0xffffffffa2317ac0 <native_queued_spin_lock_slowpath+16>
>>>     >       0xffffffffa2317add <+45>:    pop    %rbp
>>>     >       0xffffffffa2317ade <+46>:    xchg   %ax,%ax
>>>     >       ...
>>>     Probably the following prints the "=> ".
>>>     Out of curiosity, what did you do before the gdb disas?
>>>
>>> I didn't run any crash commands or gdb commands before the gdb disass, the current command(gdb disassemble 0xffffffffa2317add) is the first one.

oh, so is it a VMware memory dump or something?

Anyway, the patch was applied.
https://github.com/crash-utility/crash/commit/59c19818190dd4b7ae0dc2221586a4ad6f4fe905

Thanks,
Kazu