[PATCH v3 0/8] gdbserver improvements for AArch64 SVE support

[Willgerodt, Felix]

> -----Original Message-----
> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> Sent: Dienstag, 7. Mai 2024 18:34
> To: Luis Machado <luis.machado@arm.com>
> Cc: Willgerodt, Felix <felix.willgerodt@intel.com>; gdb-patches@sourceware.org
> Subject: Re: [PATCH v3 0/8] gdbserver improvements for AArch64 SVE support
> 
> 
> Hello Felix, Hello Luis,
> 
> Luis Machado <luis.machado@arm.com> writes:
> 
> > Hi,
> >
> > On 5/7/24 15:29, Willgerodt, Felix wrote:
> >>> -----Original Message-----
> >>> From: Gdb-patches <gdb-patches-
> >>> bounces+felix.willgerodt=intel.com@sourceware.org> On Behalf Of Thiago
> Jung
> >>> Bauermann via Gdb-patches
> >>>
> >>> This is version 3 of the patch series adding support to gdbserver for
> >>> inferiors that change the SVE vector length at runtime. This is already
> >>> supported by GDB, but not by gdbserver. Version 2 was posted here:
> >>
> >> I wonder what happened to this series. Do you plan to revive it at some
> >> point? I realise this isn't an easy series to land. Tough it would be great
> >> to have in my view.
> >
> > I think it is an essential piece to make gdbserver work correctly for both
> > SVE and SME (and similar features on other architectures), as well as enabling
> > remote debugging stubs to support vector size changes mid-execution.
> >
> > Thiago was the last one to touch this code, so he may have better information
> on
> > future plans.
> >
> > Unfortunately I don't have cycles to get back to this particular feature at the
> > moment, but I'd gladly review future iterations of the series.
> 
> Thank you for your interest in this series! I think it's very important
> too, and it nags me that I haven't been able to finish it yet. I gave up
> on the approach from this patch series, which was to have a different
> target description for each register size, which implies a different
> target description for each inferior thread.
>
> I have a branch where I implemented support in the XML target
> description to specify a register whose size is given by a math
> expression involving other registers. This way, a single target
> description is enough for the whole duration of the inferior execution,
> and for all inferior threads. But it still has significant bugs, and
> only occasionally I have been able to get back to it and try to move it
> forward. I pushed what I have to the sve-tdesc-dynamic-size branch at
> this repo, if you would like to have a look:
> 
> https://git.linaro.org/people/thiago.bauermann/binutils-gdb.git
> 
> If you "git diff 1bdabb9e9fe8..<remote>/sve-tdesc-dynamic-size" you can
> see the code.
> 
> I think I will be able to work on it again in a month or two. If you
> think my approach is good and the branch is a good starting point for
> you, feel free to work on it. I'd be happy to collaborate.
> 

Thanks for the clarification.
I briefly looked at your branch, but I didn't have enough time to really
understand it yet. But I still wanted to give some feedback based on
my current knowledge and what you wrote.

On x86 we will also need resizable registers. Though on x86, the
sizing information is only partially found in other registers. Some of
the sizing information comes e.g. from the CPUID instruction
(basically an instruction to query features of your CPU, no idea if
there is an ARM equivalent). And x86 would also need the full
flexibility of adding or removing registers I think. So would the
Intel GPU port, that is currently still a downstream fork.

I realize that this is mainly our problem. We will start working on
This eventually.  Though I think any series touching generic code
should offer enough flexibility for all architectures. I wonder
if your new approach offers that (I actually don't know),
if it is only based on other registers and only offers resizing.
Though if it doesn't prevent adding additional input for re-sizing
and could live in parallel to adding/removing registers at runtime
it could be viewed as ok.

But it makes me wonder a bit if the older approach isn't more
flexible for future architectures that want to use it. And it also
seems to be closer to the way GDB has already implemented.
Of course that doesn't mean we can't switch GDB to
a better solution at some point.

So I am curious: What was your reason for switching to the
new approach?

Thanks,
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928