On 2023/02/22 18:36, lijiang wrote: >>> On Wed, Feb 22, 2023 at 1:17 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx <mailto:k-hagio-ab@xxxxxxx>> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki