qemu-arm
[Top][All Lists]
Advanced

[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: Alex Bennée
Subject: Re: [PULL 21/30] target/arm: use official org.gnu.gdb.aarch64.sve layout for registers
Date: Fri, 05 Nov 2021 16:15:39 +0000
User-agent: mu4e 1.7.4; emacs 28.0.60

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.


-- 
Alex Bennée



reply via email to

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