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

[Luis Machado]

On 11/5/21 1:15 PM, Alex Bennée wrote:
> Luis Machado <luis.machado@linaro.org> writes:
>
> > On 11/4/21 6:03 PM, Luis Machado wrote:
> > > On 10/4/21 3:44 PM, Luis Machado wrote:
> > > > Hi,
> > > >
> > > > On 9/21/21 10:55 AM, Peter Maydell wrote:
> > > > > 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
> > > >
> > > > I'll check what can be done here.
> > > Apologies. I got sidetracked with a few other things. I'm getting
> > > back to this one.
> > > I'm guessing the less painful solution would be for QEMU to report a
> > > more compact XML description for SVE, supported by the oldest GDB we
> > > would like to validate things on, and leave it to GDB (newer
> > > releases) to add whatever pseudo-registers it deems appropriate.
> >
> > Is it only the ieee_half type that is causing issues here? Or are
> > there other types?
>
> That was the only one I noticed - which makes sense as it's a fairly new
> type.

Ok. I'm considering dialing down the number of subtypes for SVE Z 
registers, which would greatly simplify the generation of the XML for 
SVE features. But I still need to do some more investigation.