[all-commits] [llvm/llvm-project] 27abff: [lldb] New expedited register specfication for una...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 27abffa3efe272d725a6c4eceeebfe8c17e0f8e8
      https://github.com/llvm/llvm-project/commit/27abffa3efe272d725a6c4eceeebfe8c17e0f8e8
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2026-05-26 (Tue, 26 May 2026)

  Changed paths:
    M lldb/docs/resources/lldbgdbremote.md
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    M lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
    M lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.h
    A lldb/test/API/functionalities/gdb_remote_client/TestUnavailableRegisters.py
    M lldb/tools/debugserver/source/RNBRemote.cpp

  Log Message:
  -----------
  [lldb] New expedited register specfication for unavailable regs (#193894)

When lldb-server/debugserver send a stop packet, they expedite the
vaLues of many of the general purpose registers in the stop packet, so
lldb doesn't need to fetch them separately.

On Darwin systems using an AArch64 M4 or newer SOC with SME, we need to
fetch the streaming vector length (svl) register when in Streaming SVE
Mode to correctly size the registers in lldb. On Darwin systems, when we
are not in SSVE mode, svl is undefined -- it is not included in the
expedited registers. However, lldb will still try to fetch the value, so
we get a register-read packet at every stop on M4 and newer systems,
trying to fetch the value.

This patch adds a new format for the expedited registers. They are
normally a `;` separated series of `{regnum}:{native endian bytes}`.
This allows for `{regnum}:` alone, indicating that the register value
for regnum cannot be fetched at this stop.

It updates debugserver to always add svcr, tpidr2, and svl to the
expedited registers, whether we can fetch them or not.

Most of the changes happen in GDBRemoteRegisterContext. This class
maintains a buffer sized for the register context bytes, and an array of
bool to indicate whether we have fetched the value for a given register
yet or not. If we have fetched the value, we can supply the bytes from
the register context byte array. If it is not yet fetched, we read it.

This PR changes this fetched-or-not bool array to a LazyBool with

eLazyBoolYes meaning we have the bytes for the register value in the
lldb buffer.
eLazyBoolCalculate means we have not yet tried to read the register
value.
eLazyBoolNo means that the register is currently readable.

The meaning of these 3 LazyBool states could be a little confusing as
you read GDBRemoteRegisterContext, so all getting/setting of these is
done through the methods

SetAllRegistersValid()
SetAllRegistersUnfetched()

{Set,Get}RegisterIsValid()
{Set,Get}RegisterIsUnavailable()
{Set,Get}RegisterIsUnfetched()

Whcih I think makes it a little easer to understand. The changes to
GDBRemoteRegisterContext were the trickiest part of this PR, all the
other changes are simple.

Linux et al mostly work on AArch64 systems with SVE + SME, in which case
we have either a vector length or a streaming vector length, at all
times. But the M4 & newer SOCs from Apple don't have any SVE registers
when not in streaming SVE mode, so we have this issue of an extra
register read at all stops, unless in SSVE mode.

rdar://161581129

---------

Co-authored-by: Jonas Devlieghere <jonas at devlieghere.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications