Re: [PULL 21/30] target/arm: use official org.gnu.gdb.aarch64.sve layout for registers

[Peter Maydell]

On Tue, 19 Jan 2021 at 15:57, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Claudio Fontana <cfontana@suse.de> writes:
>
> > On 1/19/21 3:50 PM, Alex Bennée wrote:
> >>
> >> Claudio Fontana <cfontana@suse.de> writes:
> >>> qemu-system-aarch64: -gdb 
> >>> unix:path=/tmp/tmp9ru5tgk8qemu-gdbstub/gdbstub.socket,server: info: QEMU 
> >>> waiting for connection on: 
> >>> disconnected:unix:/tmp/tmp9ru5tgk8qemu-gdbstub/gdbstub.socket,server
> >>> warning: while parsing target description (at line 47): Vector "svevhf" 
> >>> references undefined type "ieee_half"
> >>> warning: Could not load XML target description; ignoring
> >>> qemu-system-aarch64: QEMU: Terminated via GDBstub
> >>>
> >>> Seems to indicate it is "ieee_half" -related?

> So it looks like TDESC_TYPE_IEEE_HALF was only implemented in GDB 9.1
> and there is no probing possible during the gdbstub connection. I guess
> I can either go back to stubbing it out (which would break gdb's SVE
> understanding) or up our minimum GDB version check for running tests.
> That would mean less people test GDB (or at least until the distros
> catch up) but considering it was zero people not too long ago maybe
> that's acceptable?

I just ran into this trying to connect qemu-aarch64 to the
Ubuntu gdb-multiarch. I don't care about SVE at all in this
case, but the 'max' CPU includes SVE by default, so we report
it to gdb even if the guest program being run doesn't use SVE at all.
This effectively means that usecases that used to work no longer do :-(

Luis: do we really have to report to gdb all the possible
data types that might be in SVE vector registers? Won't
gdb autogenerate pseudoregisters the way it does with
Neon d0..d31 ?

thanks
-- PMM