On Thu, 8 Apr 2021 at 11:23, Claudio Fontana <cfont...@suse.de> wrote: > Mainly for this code here a question from my side: is the current code > actually already "wrong"? > > I mean, we unconditionally set the aarch64-capable cpu classes to all use > aarch64_gdb_arch_name and gdbstub64, > but what about an aarch64-capable cpu running in 32bit mode?
This is somewhere between a bug and a missing feature. The 'bug' part is that for running a guest on AArch64 KVM with -cpu aarch64=off' (ie a 32-bit guest) we should be presenting an aarch32 gdb stub, and we don't. The 'missing feature' part is that in an ideal world we would support mixed aarch64-and-aarch32 guest debugging, and we don't. This needs support on the gdb side as well as on our side, AIUI. > Why don't we have, like tentatively done here for arm_cpu_dump_state, > > an arm_gdb_arch_name and an arm_cpu_gdb_read_register that check is_a64() and > call aaarch32_cpu_gdb_read_register or aarch64_cpu_gdb_read_register > accordingly? Because the gdb on the other end of the gdbstub does not expect the target to suddenly change in the middle of execution like that. gdb is really a userspace-process debugger at heart, and it only negotiates "what are all the register types, what is the debuggee architecture, etc" once when it connects. Once we've told gdb what the registers are we need to stick to them. Properly supporting mixed-mode debugging would require support for telling gdb "I support both this set of registers for aarch64 and this other set for aarch32" and notifying it about which mode we were in (and support in gdb for understanding this). I don't think anybody's ever seriously tried to work out a design for this. thanks -- PMM
