qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v12 27/65] target/arm: split a15 cpu model and 32bit class func


From: Claudio Fontana
Subject: Re: [RFC v12 27/65] target/arm: split a15 cpu model and 32bit class functions to cpu32.c
Date: Mon, 12 Apr 2021 11:05:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Hi Peter,

On 4/8/21 12:36 PM, Peter Maydell wrote:
> 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.

Isn't this "easily" solvable? Probably I am missing something obvious..

I mean we could dispatch to the one or to the other according to ->is_aa64()?


> 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.


Ok, but given the restriction that we can only support one or the other the 
whole time,
wouldn't adding this check ensure that at least we would do the right thing 
with -cpu aarch64=off?

Or is this on the way out, support-wise?

Thanks,

Claudio

> 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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]