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>> 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/59c19818190dd4b7ae0dc222158...
Thanks,
Kazu