Hi,

This is an attempt to fix debugging of AArch32 binaries when running
under KVM on AArch64 hardware. There are two parts to this, the first is
a handling the possibility of AArch32 software breakpoints with a
heuristic based on the current execution mode. The second part is
delaying the setup of aarch64 debugging until the shared arm_cpu_realize
function is run by which point we have parsed and decoded the actual
execution mode of the guest. This doesn't solve the problem of split
mode guests which switch between an AA64 EL1 and an AA32 EL0 though.

I still ran into a problem with single-step. Even with Mark's
single-step fixup series:

  To: linux-arm-kernel@lists.infradead.org
  Cc: kvmarm@lists.cs.columbia.edu,
  Subject: [PATCH 0/2] kvm/arm: make singlestep behaviour consistent
  Date: Fri, 9 Nov 2018 15:07:09 +0000
  Message-Id: <20181109150711.45864-1-mark.rutland@arm.com>

some instructions do single-step but sometimes the single-step doesn't
return leading to a runaway until it hits a breakpoint. I'm not sure why
this is the case because the SS state machine shouldn't be instruction
sensitive.

However these two patches at least make it possible to debug an AArch32
guest.

Alex Bennée (2):
  target/arm: kvm64 make guest debug AA32 break point aware
  target/arm: defer setting up of aarch64 gdb until arm_cpu_realize

 include/hw/arm/arm.h |  2 ++
 target/arm/cpu.c     |  4 ++++
 target/arm/cpu64.c   | 20 +++++++++++++++-----
 target/arm/kvm64.c   | 13 ++++++++++---
 4 files changed, 31 insertions(+), 8 deletions(-)

-- 
2.17.1

Hi Alex,

On Thu, Dec 13, 2018 at 11:55:01AM +0000, Alex Bennée wrote:
> Hi,
> 
> This is an attempt to fix debugging of AArch32 binaries when running
> under KVM on AArch64 hardware. There are two parts to this, the first is
> a handling the possibility of AArch32 software breakpoints with a
> heuristic based on the current execution mode. The second part is
> delaying the setup of aarch64 debugging until the shared arm_cpu_realize
> function is run by which point we have parsed and decoded the actual
> execution mode of the guest. This doesn't solve the problem of split
> mode guests which switch between an AA64 EL1 and an AA32 EL0 though.
> 
> I still ran into a problem with single-step. Even with Mark's
> single-step fixup series:
> 
>   To: linux-arm-kernel@lists.infradead.org
>   Cc: kvmarm@lists.cs.columbia.edu,
>   Subject: [PATCH 0/2] kvm/arm: make singlestep behaviour consistent
>   Date: Fri, 9 Nov 2018 15:07:09 +0000
>   Message-Id: <20181109150711.45864-1-mark.rutland@arm.com>
> 
> some instructions do single-step but sometimes the single-step doesn't
> return leading to a runaway until it hits a breakpoint. I'm not sure why
> this is the case because the SS state machine shouldn't be instruction
> sensitive.

Could you please give an example sequence where this occurs? I'd be
happy to take a look.

Thanks,
Mark.

Mark Rutland <mark.rutland@arm.com> writes:

> Hi Alex,
>
> On Thu, Dec 13, 2018 at 11:55:01AM +0000, Alex Bennée wrote:
>> Hi,
>>
>> This is an attempt to fix debugging of AArch32 binaries when running
>> under KVM on AArch64 hardware. There are two parts to this, the first is
>> a handling the possibility of AArch32 software breakpoints with a
>> heuristic based on the current execution mode. The second part is
>> delaying the setup of aarch64 debugging until the shared arm_cpu_realize
>> function is run by which point we have parsed and decoded the actual
>> execution mode of the guest. This doesn't solve the problem of split
>> mode guests which switch between an AA64 EL1 and an AA32 EL0 though.
>>
>> I still ran into a problem with single-step. Even with Mark's
>> single-step fixup series:
>>
>>   To: linux-arm-kernel@lists.infradead.org
>>   Cc: kvmarm@lists.cs.columbia.edu,
>>   Subject: [PATCH 0/2] kvm/arm: make singlestep behaviour consistent
>>   Date: Fri, 9 Nov 2018 15:07:09 +0000
>>   Message-Id: <20181109150711.45864-1-mark.rutland@arm.com>
>>
>> some instructions do single-step but sometimes the single-step doesn't
>> return leading to a runaway until it hits a breakpoint. I'm not sure why
>> this is the case because the SS state machine shouldn't be instruction
>> sensitive.
>
> Could you please give an example sequence where this occurs? I'd be
> happy to take a look.

Here is a trace in gdb:

=> 0x0: b       0x1000
   0x4:                 ; <UNDEFINED> instruction: 0xffffffff
   0x8:                 ; <UNDEFINED> instruction: 0xffffffff
   0xc:                 ; <UNDEFINED> instruction: 0xffffffff
   0x10:                        ; <UNDEFINED> instruction: 0xffffffff
   0x1000:      bl      0x372c
   0x1004:      andeq   r12, r0, r1, asr r12
   0x1008:      rors    pc, lr, r0      ; <UNPREDICTABLE>
   0x100c:      andeq   r0, r0, r0
   0x1010:      cfstr32hi       mvfx14, [r12], {120}    ; 0x78
   0x372c:      bl      0x39d4
   0x3730:      bl      0x39cc
   0x3734:      mov     r5, r0
   0x3738:      bl      0x39e8
   0x373c:      movw    r1, #0
   0x39d4:      bx      lr
   0x39d8:      and     r1, r0, #255    ; 0xff
   0x39dc:      and     r0, r0, #65280  ; 0xff00
   0x39e0:      add     r0, r1, r0, lsr #7
   0x39e4:      bx      lr
Hardware assisted breakpoint 1 at 0x39d4
0x00001000 in ?? ()
=> 0x1000:      bl      0x372c
   0x1004:      andeq   r12, r0, r1, asr r12
   0x1008:      rors    pc, lr, r0      ; <UNPREDICTABLE>

Thread 1 hit Breakpoint 1, 0x000039d4 in ?? ()
=> 0x39d4:      bx      lr
   0x39d8:      and     r1, r0, #255    ; 0xff
   0x39dc:      and     r0, r0, #65280  ; 0xff00
0x1000: 0xeb0009c9      0x0000cc51

The second instruction (bl 0x372c) didn't single-step and we eventually
hit the hbreak I set at 0x39d4.

This is from ard's QEMU_EFI.fd build:

 http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/3373/QEMU-ARM/DEBUG_GCC5/QEMU_EFI.img.gz

Running with:

 ./aarch64-softmmu/qemu-system-aarch64 -M virt -cpu host,aarch64=off -enable-kvm -net none -nographic -bios ~/QEMU_EFI_aarch32.img -smp 2 -s -S

And:

 gdb -ex "target remote localhost:1234"

>
> Thanks,
> Mark.


--
Alex Bennée