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.
