On Tue, 19 Jan 2021 at 15:57, Alex Bennée <alex.ben...@linaro.org> wrote: > > > Claudio Fontana <cfont...@suse.de> writes: > > > On 1/19/21 3:50 PM, Alex Bennée wrote: > >> > >> Claudio Fontana <cfont...@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
