[all-commits] [llvm/llvm-project] 03d8cd: [lldb][AArch64] Add support for SME's SVE streamin...

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 03d8cd1d722daad86c45e242eb7d75d0a88bb00c
      https://github.com/llvm/llvm-project/commit/03d8cd1d722daad86c45e242eb7d75d0a88bb00c
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2023-07-26 (Wed, 26 Jul 2023)

  Changed paths:
    M lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
    M lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
    M lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
    M lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
    M lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_dynamic_resize/TestSVEThreadedDynamic.py
    M lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_dynamic_resize/main.c
    M lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/Makefile
    M lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
    M lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
    A lldb/test/API/commands/register/register/aarch64_sve_simd_registers/Makefile
    A lldb/test/API/commands/register/register/aarch64_sve_simd_registers/TestSVESIMDRegisters.py
    A lldb/test/API/commands/register/register/aarch64_sve_simd_registers/main.c

  Log Message:
  -----------
  [lldb][AArch64] Add support for SME's SVE streaming mode registers

The Scalable Matrix Extension (SME) adds a new Scalable Vector mode
called "streaming SVE mode".

In this mode a lot of things change, but my understanding overall
is that this mode assumes you are not going to move data out of
the vector unit very often or read flags.

Based on "E1.3" of "Arm® Architecture Reference Manual Supplement,
The Scalable Matrix Extension (SME), for Armv9-A".

https://developer.arm.com/documentation/ddi0616/latest/

The important details for debug are that this adds another set
of SVE registers. This set is only active when we are in streaming
mode and is read from a new ptrace regset NT_ARM_SSVE.
We are able to read the header of either mode at all times but
only one will be active and contain register data.

For this reason, I have reused the existing SVE state. Streaming
mode is just another mode value attached to that state.

The streaming mode registers do not have different names in the
architecture, so I do not plan to allow users to read or write the
inactive mode's registers. "z0" will always mean "z0" of the active
mode.

Ptrace does allow reading inactive modes, but the data is of little
use. Writing to inactive modes will switch to that mode which would
not be what a debugger user would expect. So lldb will do neither.

Existing SVE tests have been updated to check streaming mode and
mode switches. However, we are limited in what we can check given
that state for the other mode is invalidated on mode switch.

The only way to know what mode you are in for testing purposes would
be to execute a streaming only, or non-streaming only instruction in
the opposite mode. However, the CPU feature smefa64 actually allows
all non-streaming mode instructions in streaming mode.

This is enabled by default in QEMU emulation and rather than mess
about trying to disable it I'm just going to use the pseduo streaming
control register added in a later patch to make these tests more
robust.

A new test has been added to check SIMD read/write from all the modes
as there is a subtlety there that needs noting, though lldb
doesn't have to make extra effort to do so.

If you are in streaming mode and write to v0, when you later exit
streaming mode that value may not be in the non-streaming state.
This can depend on how the core works but is a valid behaviour.

For example, say I am stopped here:
mov x0, v0.d[0]

And I want to update v0 in lldb. "register write v0 ..." should update
the v0 that this instruction is about to see. Not the potential other
copy of v0 in the non-streaming state (which is what I attempted in
earlier versions of this patch).

Not to mention, switching out of streaming mode here would be unexpected
and difficult to signal to the user.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D154926