On 2023/02/27 12:41, lijiang wrote:
> On Mon, Feb 27, 2023 at 8:59 AM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com <mailto:k-hagio-ab@nec.com>> wrote:
>
> On 2023/02/22 18:36, lijiang wrote:
> >>> On Wed, Feb 22, 2023 at 1:17 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com <mailto:k-hagio-ab@nec.com> <mailto: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?
>
>
> Yes. This is a vmss vmcore. And this issue was observed on the kernel-3.10.
Got it, probably it's set by crash commit 2f967fb5ebd7.
Thanks,
Kazu