[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: Thu, 4 Nov 2021 18:03:02 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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

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

reply via email to

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