Debugging 32 bit ARM guests running under QEMU KVM on 64 bit ARM hosts with gdb

[Berto Furth]

Hi qemu friends,

I have noticed that when debugging a 32 bit arm (AA32) kvm guest running in a 
64 bit ARM (aarch64 / AA64) host with "qemu-system-aarch64" and the 
"aarch64=off" flag set that a remote gdb debugger still thinks that it's 
debugging ARM64. This results in GDB being unable to properly decode assembly 
instructions and register values from the guest. Additionally breakpoints set 
in GDB are ignored. (hbreak still works)

What's the expected behavior in a case like this? Has anyone else got this sort 
of thing working with a recent version of QEMU (5.2.0 or latest git).

For everyone else who's interested, here are the details of what I'm seeing and 
how it can be fixed with a patch that was posted on the qemu-arm developers 
list in 2018. Hopefully this will be able to help someone else in the same 
situation as me.

When you run QEMU with the following style to launch a 32 bit guest running in 
kvm mode on a 64 bit ARM machine (e.g Raspberry Pi 4) ...

qemu-system-aarch64 -machine <my-machine> -cpu host,aarch64=off -S -enable-kvm 
-gdb tcp::12345  <insert other startup parameters of course>

and then you start gdb in another window and connect it to the QEMU instance 
(Tried this with GDB 10.1 and 11.0.50 with multiple architectures enabled) ...

gdb -ex "target remote 127.0.0.1:12345"

GDB shows garbage and a number of "undefined" instructions when trying to 
disassemble. GDB also shows that it is in aarch64 architecture mode and 
although other arm architectures are available GDB refuses to be manually 
changed to a 32 bit arm mode. For example...


(gdb) x/5i 0x207c
   0x207c:      .inst   0xe1510002 ; undefined
   0x2080:      adc     w22, w0, w0
   0x2084:      .inst   0xe1a0100d ; undefined
   0x2088:      str     p0, [x10, #4, mul vl]
   0x208c:      .inst   0xe51f0054 ; undefined

(gdb) show architecture
The target architecture is set to "auto" (currently "aarch64").

(gdb) set architecture arm<tab to auto-complete and show options>
arm             armv2a          armv4           armv5t          armv6           
armv6kz         armv7           armv8-m.base    armv8.1-m.main
arm_any         armv3           armv4t          armv5te         armv6-m         
armv6s-m        armv7e-m        armv8-m.main
armv2           armv3m          armv5           armv5tej        armv6k          
armv6t2         armv8-a         armv8-r

(gdb) set architecture arm
warning: Selected architecture arm is not compatible with reported target 
architecture aarch64
Architecture `arm' not recognized.
The target architecture is set to "auto" (currently "aarch64").


There is a thread from December 2018 on the qemu-arm mailing list that 
discusses this topic and proposes a patch but the suggested patch doesn't 
appear to be applied in the latest 5.2.0 release or the latest code at the qemu 
git repository.

[Qemu-arm] [PATCH v1 1/2] target/arm: kvm64 make guest debug AA32 break point 
aware
https://lists.nongnu.org/archive/html/qemu-arm/2018-12/msg00225.html

[Qemu-arm] [PATCH v1 2/2] target/arm: defer setting up of aarch64 gdb until 
arm_cpu_realize
https://lists.nongnu.org/archive/html/qemu-arm/2018-12/msg00227.html
(This patch is a little out of date. For recent qemu versions move the new code 
shown in non-existent file "include/hw/arm/arm.h" to somewhere in 
"target/arm/cpu.h" or something like that. Also ignore the line with 
"aarch64_cpu_set_pc")


I get the impression the proposed code may not have been committed because it 
didn't cater for a corner case involving big/little endian hosts or something.

I've tested the suggested patches as applied to QEMU 5.2.0 and they seem to 
work fine in my case where I'm running a ARM32 OS as guest on a Raspberry Pi 4 
Model B host. Here is the output I see in gdb in the same situation as the non 
working example above. Note that architecture is now "arm" (32 bit arm) and the 
assembly decode is sensible.

(gdb) show architecture
The target architecture is set to "auto" (currently "arm").
(gdb) x/5i 0x207c
   0x207c:      cmp     r1, r2
   0x2080:      bne     0x20e0
   0x2084:      mov     r1, sp
   0x2088:      str     r1, [r0, #320]  ; 0x140
   0x208c:      ldr     r0, [pc, #-84]  ; 0x2040

Can someone with some experience point me in the right direction to get these 
patches applied? I don't know if I'm meant to directly email the qemu-arm 
developer list or the code maintainers because it seems as though there are 
some strict conditions on what you send to them.

Should I just raise a bug in the bug tracker app and hope it gets fixed one day?

Thanks for your help!

Berto.