Re: [Qemu-devel] [RFC PATCH v4 5/5] target/ppc: support single stepping with KVM HV

[Alexey Kardashevskiy]

On 12/06/2019 23:34, Fabiano Rosas wrote:
> Alexey Kardashevskiy <address@hidden> writes:
> 
>> Are you reposting this any time soon?
> 
> I have sent a v2 to the kernel side of it:
> 
> https://lore.kernel.org/kvm/address@hidden/
> 
> I'm depending on what we decide to do there. The core of this patchset
> will not change, just the mechanism by which the feature is selected
> (patch 2, kvm-all: Introduce kvm_set_singlestep).
> 
>> In meanwhile I hit a problem when I cannot step over the "stdu" instruction.
>>
>> I basically put this:
>> stdu    r1,-368(r1)
>>
>> and "ni" in gdb does not stop on the next instruction which is quite
>> confusing. Ideas?
> 
> Perhaps the next instruction is one that is not traced? See the programming
> note at the end of section 6.5.15 in Book III.

No, it is not it, it is more subtle. The problem piece was originally this:

c0000000010f16b4:       f0 ff c1 fb     std     r30,-16(r1)
c0000000010f16b8:       f8 ff e1 fb     std     r31,-8(r1)
c0000000010f16bc:       91 fe 21 f8     stdu    r1,-368(r1)
c0000000010f16c0:       39 00 22 3d     addis   r9,r2,57
c0000000010f16c4:       18 97 49 39     addi    r10,r9,-26856
c0000000010f16c8:       08 00 22 3d     addis   r9,r2,8
c0000000010f16cc:       00 78 29 39     addi    r9,r9,30720

It is Linux'es prom_init().


> Or maybe the step got preempted? You should see GDB messages indicating
> changing threads right before or after the stdu. However that would only
> happen with more than one VCPU and if 'show scheduler-locking' in GDB is
> 'off'. And even then, that should not cause any issues, but it is a more
> complex scenario so there could be a bug in the code.

It is TCG, a single CPU with a single thread and no matter where I put
this "stdu    r1,-368(r1)" - GDB does not stop on the next one and just
runs.

In the example above:
1. "b *0x10f16bc" makes GDB stop there, "ni" continues without stopping
on at 0x10f16c0.
2. "b *0x10f16bc" and "b *0x10f16c0" make GDB stop at 0x10f16bc and "ni"
steps to 0x10f16c0 but it is rather because it is a breakpoint and not
the next instruction.
3. "b *0x10f16bc" and "b *0x10f16c4" make GDB stop at 0x10f16bc and "ni"
stops GDB at 0x10f16bc but again it is a breakpoint.

In 2 and 3 it is possible to continue step debugging till the next "stdu".


> 
>> On 20/03/2019 12:42, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 20/03/2019 01:32, Fabiano Rosas wrote:
>>>> Alexey Kardashevskiy <address@hidden> writes:
>>>>
>>>>> Looks good to me, does not break what already works. However I cannot
>>>>> debug SLOF real mode and I am not sure why.
>>>>>
>>>>> (gdb) set endian big
>>>>>
>>>>> The target is assumed to be big endian
>>>>> (gdb) b *0x3f00
>>>>>
>>>>> Breakpoint 2 at 0x3f00
>>>>
>>>> I think I'm missing the point here. Why 0x3f00?
>>>
>>> Because I am stupid and did not realize that 0x3f00 is a relative offset
>>> and 0x4000 is the correct address which works.
>>>
>>>
>>> Reviewed-by: Alexey Kardashevskiy <address@hidden>
>>>
>>>
>>>>
>>>> (qemu) info roms
>>>> addr=0000000000000000 size=0x0e22b8 mem=ram name="...qemu/slof.bin"        
>>>>                        
>>>> addr=0000000000400000 size=0x17976d0 mem=ram name="...vmlinux"
>>>>
>>>>
>>>> $ objdump -d board-qemu/llfw/stage1.elf | grep "_start>"
>>>> 0000000000000100 <__start>:
>>>>      100:       48 00 3f 00     b       4000 <_start>
>>>> 0000000000004000 <_start>:
>>>>
>>>>
>>>> Thread 1 hit Breakpoint 3, _start () at startup.S:82
>>>> (gdb) p/x $pc
>>>> $1 = 0x4000
>>>> (gdb) si
>>>> (gdb) p/x $pc
>>>> $3 = 0x4004
>>>> (gdb) c
>>>> Thread 1 hit Breakpoint 4, early_c_entry (start_addr=49056, 
>>>> fdt_addr=49024) at stage2.c:202
>>>> (gdb) p/x $pc
>>>> $4 = 0x4d18
>>>>
>>>

-- 
Alexey