Re: [RFC v12 27/65] target/arm: split a15 cpu model and 32bit class functions to cpu32.c

[Peter Maydell]

On Thu, 8 Apr 2021 at 11:23, Claudio Fontana <cfontana@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