[Top][All Lists]

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

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

From: Luis Machado
Subject: Re: [PULL 21/30] target/arm: use official org.gnu.gdb.aarch64.sve layout for registers
Date: Fri, 5 Nov 2021 13:29:20 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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:

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>

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
info: QEMU waiting for connection on:
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 ?

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

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.

reply via email to

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