RE: [PATCH 00/17] SME support for AArch64 gdb/gdbserver on Linux.

["Willgerodt, Felix" <felix.willgerodt@intel.com>]

> -----Original Message-----
> From: John Baldwin <jhb@FreeBSD.org>
> Sent: Dienstag, 11. April 2023 17:51
> To: Luis Machado <luis.machado@arm.com>; gdb-patches@sourceware.org
> Cc: Willgerodt, Felix <felix.willgerodt@intel.com>
> Subject: Re: [PATCH 00/17] SME support for AArch64 gdb/gdbserver on
> Linux.
> 
> On 4/10/23 9:26 PM, Luis Machado via Gdb-patches wrote:
> > The following series enables SME 1 (Scalable Matrix Extension) support for
> > AArch64 gdb and gdbserver.
> >
> > SME expands on SVE by having a variable-sized matrix (ZA) of dimensions
> > SVL x SVL bytes.
> >
> > The first few patches and some intermediate ones refactor the code and
> fix
> > issues prior to enabling SME support, and thus could go in independently.
> >
> > I've kept them in the series as they are closely/logically related.
> 
> I briefly glanced at a few bits of the aarch64-specific parts I'm familiar
> with and they all look fine to me.
> 
> One note is that I think the AMX patches from Intel (which deal with a
> similar "tile area" split into variable-sized subregisters IIUC) ran into
> some issues with wanting to update the tdesc to deal with the differing
> subregisters since the layout of those can change at runtime.  I'm not
> sure if that applies to SME in the same way and if any of the issues
> Felix ran into might apply to SME as well (and thus if there are common
> solutions?)  (I've cc'd Felix FYI)

Hi John, Luis,

I didn't read the SME series in full detail and probably won't have the time to
do that for a while, sorry. I can only repeat my AMX problems.
My problem was related to the fact that I tried to make the AMX register
pseudo registers to do the dynamic resizing.
This doesn't work well with the regcache.

I am currently waiting on this series to land to continue:
https://sourceware.org/pipermail/gdb-patches/2023-January/196353.html
I am planning to do the tdesc update dynamically instead, forgoing
pseudo registers all together. But I haven't started implementing that.
We had an internal version that tried this, but in the end we scrapped that
because gdbserver doesn't support it (yet).

I think my main problem with pseudo registers is that regcache is initialized
with a certain size and types of registers. Even the pseudo registers.
For AMX we have 8 kB of register state. That is currently divided into 8 registers
of the same dimensions.
But that is actually configurable, and it could be that future platforms add a
configuration ("palette") that divides it into 4 registers of dimension "x * x". Or
another palette that divides this into 4 registers of dimension "y * z". Or another
palette that divides it into 16 registers. Switching configurations can be done
at runtime.
I was initially planning to just take the biggest dimension and the
biggest amount of names, and keep that up-to-date.

The actual problem I had in the end was discussed here:
https://sourceware.org/pipermail/gdb-patches/2022-August/191259.html
But the solution I proposed there isn't a good one.
It works by accident for now. It only touches the type, but not the actual
memory that is already reserved for the reg, which can become a problem.

I am not familiar with SME. I see that the SME series also added pseudo
registers and doesn't touch regcache.c. But I didn't look at the code in
detail. I am not familiar with the aarch64 target code. I don't know if Luis
found a way around the same problem or if it just doesn’t exist for SME.
Or if my AMX code just wasn't smart enough or done the right way.

Regards,
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928