[lldb][AArch64] Add Guarded Control Stack support for Linux core files (#124293)

This allows you to read the same registers as you would for a live
process.

As the content of proc/pid/smaps is n

[lldb][AArch64] Add Guarded Control Stack support for Linux core files (#124293)

This allows you to read the same registers as you would for a live
process.

As the content of proc/pid/smaps is not included in the core file, we
don't get the "ss" marker that tell us that it is shadow stack. The GCS
region is still in the list though.

show more ...

[lldb][AArch64] Read fpmr register from core files (#110104)

https://developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registers/FPMR--Floating-point-Mode-Register
for details of the register.

[lldb][FreeBSD][AArch64] Enable register field detection (#85058)

This extends the existing register fields support from AArch64 Linux
to AArch64 FreeBSD. So you will now see output like this:
```

[lldb][FreeBSD][AArch64] Enable register field detection (#85058)

This extends the existing register fields support from AArch64 Linux
to AArch64 FreeBSD. So you will now see output like this:
```
(lldb) register read cpsr
cpsr = 0x60000200
= (N = 0, Z = 1, C = 1, V = 0, DIT = 0, SS = 0, IL = 0, SSBS = 0, D = 1, A = 0, I = 0, F = 0, nRW = 0, EL = 0, SP = 0)
```

Linux and FreeBSD both have HWCAP/HWCAP2 so the detection mechanism
is the same and I've renamed the detector class to reflect that.

I have confirmed that FreeBSD's treatment of CPSR (spsr as the kernel
calls it) is similair enough that we can use the same field information.

(see `sys/arm64/include/armreg.h` and `PSR_SETTABLE_64`)

For testing I've enabled the same live process test as Linux
and added a shell test using an existing FreeBSD core file.

Note that the latter does not need XML support because when reading
a core file we are not sending the information via target.xml,
it's just internal to LLDB.

show more ...

[lldb][AArch64][Linux] Add field information for the CPSR register (#70300)

The contents of which are mostly SPSR_EL1 as shown in the Arm manual,
with a few adjustments for things Linux says usersp

[lldb][AArch64][Linux] Add field information for the CPSR register (#70300)

The contents of which are mostly SPSR_EL1 as shown in the Arm manual,
with a few adjustments for things Linux says userspace shouldn't concern
itself with.

```
(lldb) register read cpsr
cpsr = 0x80001000
= (N = 1, Z = 0, C = 0, V = 0, SS = 0, IL = 0, ...
```

Some fields are always present, some depend on extensions. I've checked
for those extensions using HWCAP and HWCAP2.

To provide this for core files and live processes I've added a new class
LinuxArm64RegisterFlags. This is a container for all the registers we'll
want to have fields and handles detecting fields and updating register
info.

This is used by the native process as follows:
* There is a global LinuxArm64RegisterFlags object.
* The first thread takes a mutex on it, and updates the fields.
* Subsequent threads see that detection is already done, and skip it.
* All threads then update their own copy of the register information
with pointers to the field information contained in the global object.

This means that even though every thread will have the same fields, we
only detect them once and have one copy of the information.

Core files instead have a LinuxArm64RegisterFlags as a member, because
each core file could have different saved capabilities. The logic from
there is the same but we get HWACP values from the corefile note.

This handler class is Linux specific right now, but it can easily be
made more generic if needed. For example by using LLVM's FeatureBitset
instead of HWCAPs.

Updating register info is done with string comparison, which isn't
ideal. For CPSR, we do know the register number ahead of time but we do
not for other registers in dynamic register sets. So in the interest of
consistency, I'm going to use string comparison for all registers
including cpsr.

I've added tests with a core file and live process. Only checking for
fields that are always present to account for CPU variance.

show more ...

[lldb][AArch64] Read SME2's ZT0 register from Linux core files (#70934)

The ZT0 register is always 64 bytes in size so it is a lot easier to
handle than ZA which is scalable. In addition, reading a

[lldb][AArch64] Read SME2's ZT0 register from Linux core files (#70934)

The ZT0 register is always 64 bytes in size so it is a lot easier to
handle than ZA which is scalable. In addition, reading an inactive ZT0
via ptrace returns all 0s, unlike ZA which returns no register data.

This means that a corefile from a process where ZA and ZT0 were inactive
still contains an NT_ARM_ZT note and we can simply say that if it's
there, then we should be able to read from it.

Along the way I removed a redundant check on the size of the ZA note. If
that note's size is < the ZA header size, we do not have SME, and
therefore could not have SME2 either.

I have added ZT0 to the existing SME core files tests. This means that
you need an SME2 system to generate them (Arm's FVP at this point). I
think this is a fair tradeoff given that this is all running in
simulation anyway and seperate ZT0 tests would be 99% identical copies
of the ZA only tests.

show more ...

[lldb][AArch64][Linux] Rename Is<ext>Enabled to Is<ext>Present (#70303)

For most register sets, if it was enabled this meant you could use it,
it was present in the process. There was no present bu

[lldb][AArch64][Linux] Rename Is<ext>Enabled to Is<ext>Present (#70303)

For most register sets, if it was enabled this meant you could use it,
it was present in the process. There was no present but turned off
state. So "enabled" made sense.

Then ZA came along (and soon to be ZT0) where ZA can be present in the
hardware when you have SME, but ZA itself can be made inactive. This
means that "IsZAEnabled()" doesn't mean is it active, it means do you
have SME. Which is very confusing when we actually want to know if ZA is
active.

So instead say "IsZAPresent", to make these checks more specific. For
things that can't be made inactive, present will imply "active" as
they're never inactive.

show more ...

[lldb][AArch64] Read mte_ctrl register from core files (#69689)

This register reports the configuration of the AArch64 Linux tagged
address ABI, part of which is the memory tagging (MTE) settings.

[lldb][AArch64] Read mte_ctrl register from core files (#69689)

This register reports the configuration of the AArch64 Linux tagged
address ABI, part of which is the memory tagging (MTE) settings.

It will always be present in core files because even without MTE, there
are parts of the tagged address ABI that can be configured (these parts
use the Top Byte Ignore feature).

I missed adding this when I previously worked on MTE support. Until now
you could read memory tags from a core file but not this register.

show more ...

[lldb][AArch64] Correct type of 32 bit GPR RegisterValues when using core files (#70054)

As ReadRegister always read into a uint64_t, when it called operator=
with uint64_t it was setting the Regis

[lldb][AArch64] Correct type of 32 bit GPR RegisterValues when using core files (#70054)

As ReadRegister always read into a uint64_t, when it called operator=
with uint64_t it was setting the RegisterValue's type to eTypeUInt64
regardless of its size.

This mostly works because most registers are 64 bit, and very few bits
of code rely on the type being correct. However, cpsr, fpsr and fpcr are
in fact 32 bit, and my upcoming register fields code relies on this type
being correct.

Which is how I found this bug and unfortunately is the only way to test
it. As RegisterValue::Type never makes it out via the API anywhere. So
this change will be tested once I start adding register field
information.

show more ...

Reland "[lldb][AArch64] Linux corefile support for SME"

This reverts commit 3fa503582315f23f187a019f026c5fce59b3f3d8.

m_sve_state was not initialised which (I'm guessing) meant that
it could potent

Reland "[lldb][AArch64] Linux corefile support for SME"

This reverts commit 3fa503582315f23f187a019f026c5fce59b3f3d8.

m_sve_state was not initialised which (I'm guessing) meant that
it could potentially be a value that matched a real SVE state.
Then we'd be acting as if we're streaming mode, for example,
without ever having the data required to back that up.

By sheer luck this only turn up on x86, AArch64 and ARM were fine.
It is UB regardless.

show more ...

Revert "[lldb][AArch64] Linux corefile support for SME"

This reverts commit 43812c8c87b1c14bbcd160d613b7d8a60c21f260.

Due to failures on x86_64: https://lab.llvm.org/buildbot/#/builders/68/builds/6

Revert "[lldb][AArch64] Linux corefile support for SME"

This reverts commit 43812c8c87b1c14bbcd160d613b7d8a60c21f260.

Due to failures on x86_64: https://lab.llvm.org/buildbot/#/builders/68/builds/60416

show more ...

[lldb][AArch64] Linux corefile support for SME

This adds the ability to read streaming SVE registers,
ZA, SVCR and SVG from core files.

Streaming SVE is in a new note NT_ARM_SSVE but otherwise
has

[lldb][AArch64] Linux corefile support for SME

This adds the ability to read streaming SVE registers,
ZA, SVCR and SVG from core files.

Streaming SVE is in a new note NT_ARM_SSVE but otherwise
has the same format as SVE. So I've done the same as I
did for live processes and reused the existing SVE state
with an extra state for the mode variable.

ZA is in a note NT_ARM_ZA and again the handling matches
live processes. Except that it gets setup only once. A
disabled ZA reads as 0s as usual.

SVCR and SVG are pseudo registers, generated from the notes.

An important detail is that the notes represent what
you would have got if you read from ptrace at the time of
the crash.

This means that for a corefile in non-streaming mode,
there is still an NT_ARM_SSVE note and we check the header
flags to tell if it is active. We cannot just say if you
have the note you're in streaming mode.

The kernel does not provide register values for the inactive
mode and even if it did, they would be undefined, so if we find
streaming state, we ignore the non-streaming state.

Same for ZA, a disabled ZA still has the header in the note.

The tests do not cover all combinations but enough different
vector lengths, modes and ZA states to be confident.

Reviewed By: omjavaid

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

show more ...

[lldb][AArch64] Add SME's Array Storage (ZA) register

Note: This requires later commits for ZA to function properly,
it is split for ease of review. Testing is also in a later patch.

The "Matrix" p

[lldb][AArch64] Add SME's Array Storage (ZA) register

Note: This requires later commits for ZA to function properly,
it is split for ease of review. Testing is also in a later patch.

The "Matrix" part of the Scalable Matrix Extension is a new register
"ZA". You can think of this as a square matrix made up of scalable rows,
where each row is one scalable vector long. However it is not made
of the existing scalable vector registers, it is its own register.
Meaning that the size of ZA is the vector length in bytes * the vector
length in bytes.

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

It uses the streaming vector length, even when streaming mode itself
is not active. For this reason, it's register data header always
includes the streaming vector length.

Due to it's size I've changed kMaxRegisterByteSize to the maximum
possible ZA size and kTypicalRegisterByteSize will be the maximum
possible scalable vector size. Therefore ZA transactions will cause heap
allocations, and non ZA registers will perform exactly as before.

ZA can be enabled and disabled independently of streaming mode. The way
this works in ptrace is different to SVE versus streaming SVE. Writing
NT_ARM_ZA without register data disables ZA, writing NT_ARM_ZA with
register data enables ZA (LLDB will only support the latter, and only
because it's convenient for us to do so).

https://kernel.org/doc/html/v6.2/arm64/sme.html

LLDB does not handle registers that can appear and dissappear at
runtime. Rather than add complexity to implement that, LLDB will
show a block of 0s when ZA is disabled.

The alternative is not only updating the vector lengths every stop,
but every register definition. It's possible but I'm not sure it's worth
pursuing.

Users should refer to the SVCR register (added in later patches)
for the final word on whether ZA is active or not.

Writing to "VG" during streaming mode will change the size of the
streaming sve registers and ZA. LLDB will not attempt to preserve
register values in this case, we'll just read back the undefined
content the kernel shows. This is in line with, as stated, the
kernel ABIs and the prospective software ABIs look like.

ZA is defined as a vector of size SVL*SVL, so the display in lldb
is very basic. A giant block of values. This is no worse than SVE,
just larger. There is scope to improve this but that can wait
until we see some use cases.

Reviewed By: omjavaid

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

show more ...

[lldb][AArch64] Add reading of TLS tpidr register from core files

7e229217f4215b519b886e7881bae4da3742a7d2 did live processes, this does
core files. Pretty simple, there is an NT_ARM_TLS note that c

[lldb][AArch64] Add reading of TLS tpidr register from core files

7e229217f4215b519b886e7881bae4da3742a7d2 did live processes, this does
core files. Pretty simple, there is an NT_ARM_TLS note that contains
at least tpidr, and on systems with the Scalable Matrix Extension (SME), tpidr2
as well.

tpidr2 will be handled in future patches for SME support.

This NT_ARM_TLS note has always been present but it seems convenient to
handle it as "optional" inside of LLDB. We'll probably want the flexibility
when supporting tpidr2.

Normally the C library would set tpidr but all our test sources build
without it. So I've updated the neon test program to write to tpidr
and regenerated the corefile.

I've removed the LLDB_PTRACE_NT_ARM_TLS that was unused, we get
what we need from llvm's defs instead.

Reviewed By: omjavaid

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

show more ...

[LLDB] Change RegisterValue::SetFromMemoryData to const RegisterInfo&

All callers were either assuming their pointer was not null before calling
this, or checking beforehand.

Reviewed By: clayborg

[LLDB] Change RegisterValue::SetFromMemoryData to const RegisterInfo&

All callers were either assuming their pointer was not null before calling
this, or checking beforehand.

Reviewed By: clayborg

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

show more ...

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
mem

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

Differential revision: https://reviews.llvm.org/D122856

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041

show more ...

Support AArch64 PAC elf-core register read

This adds support for reading AArch64 Pointer Authentication regset
from elf-core file. Also includes a test-case for the same. Furthermore
there is also a

Support AArch64 PAC elf-core register read

This adds support for reading AArch64 Pointer Authentication regset
from elf-core file. Also includes a test-case for the same. Furthermore
there is also a slight refactoring of RegisterContextPOSIXCore_arm64
members and constructor. linux-aarch64-pac.core file is generated using
lldb/test/API/functionalities/postmortem/elf-core/main.c with following
clang arguments:
-march=armv8.5-a -mbranch-protection=pac-ret+leaf -nostdlib -static -g

Reviewed By: DavidSpickett

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

show more ...

[LLDB] Add support for Arm64/Linux dynamic register sets

This is patch adds support for adding dynamic register sets for
AArch64 dynamic features in LLDB. AArch64 has optional features like
SVE, Poi

[LLDB] Add support for Arm64/Linux dynamic register sets

This is patch adds support for adding dynamic register sets for
AArch64 dynamic features in LLDB. AArch64 has optional features like
SVE, Pointer Authentication and MTE which means LLDB needs to decide
at run time which registers it needs to pull in for the current
executable based on underlying support for a certain feature.

This patch makes necessary adjustments to make way for dynamic
register infos and dynamic register sets.

Reviewed By: labath

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

show more ...

[LLDB] Fix SVE reginfo for sequential offset in g packet

This moves in the direction of our effort to synchronize register descriptions
between LLDB and GDB xml description. We want to able to send

[LLDB] Fix SVE reginfo for sequential offset in g packet

This moves in the direction of our effort to synchronize register descriptions
between LLDB and GDB xml description. We want to able to send registers in a
way that their offset fields can be re-constructed based on register sizes
in the increasing order of register number.

In context to Arm64 SVE, FPCR and FPSR are same registers in FPU regset and
SVE regset. Previously FPSR/FPCR offset was set at the end of SVE data
because Linux ptrace data placed FPCR and FPSR at the end of SVE register set.

Considering interoperability with other stubs like QEMU and that g packets
should generate register data in increasing order of register numbers. We
have to move FPCR/FPSR offset up to its original location according to
register numbering scheme of ARM64 registers with SVE registers included.

Reviewed By: labath

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

show more ...

Convert SVE macros into c++ constants and inlines

This patch updates LLDB's in house version of SVE ptrace/sig macros by
converting them into constants and inlines. They are housed under sve
namespa

Convert SVE macros into c++ constants and inlines

This patch updates LLDB's in house version of SVE ptrace/sig macros by
converting them into constants and inlines. They are housed under sve
namespace and are used by process elf-core for reading SVE register data.

Reviewed By: labath

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

show more ...

Revert "Revert "AArch64 SVE register infos and core file support""

This reverts commit d9920e0199b48734ef305e69ecd5235fff72be25.

Revert "AArch64 SVE register infos and core file support"

This reverts commit 7e017de0ad62dfd3f373354fc47b0e39c0fef657.

AArch64 SVE register infos and core file support

Summary:
This patch adds support for AArch64 SVE register infos description and
core file register access.

AArch64 SVE is a an optional extension of

AArch64 SVE register infos and core file support

Summary:
This patch adds support for AArch64 SVE register infos description and
core file register access.

AArch64 SVE is a an optional extension of Arm v8.3-a architecture. It
has introduced 32 new vector registers Z, 16 predicate P registers and FFR
predicate register. These registers have fixed names but can dynamically
be configured to different size based on underlying OS configuration.

This patch adds register info struct that describes SVE register infos and
also provides RegisterContextPOSIXCore_arm64 routines to access SVE registers.

This patch also introduces a mechanism to configure SVE register sizes and
offsets at startup before exchanging register information across gdb-remote.

TestLinuxCore.py has been updated to include testing of SVE core files.

Reviewers: labath, clayborg, jankratochvil, jasonmolenda, rengolin

Reviewed By: labath

Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits

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

show more ...

Combine multiple defs of arm64 register sets

Summary:
This patch aims to combine similar arm64 register set definitions defined in NativeRegisterContextLinux_arm64 and RegisterContextPOSIX_arm64.
I

Combine multiple defs of arm64 register sets

Summary:
This patch aims to combine similar arm64 register set definitions defined in NativeRegisterContextLinux_arm64 and RegisterContextPOSIX_arm64.
I have implemented a register set interface out of RegisterInfoInterface class and moved arm64 register sets into RegisterInfosPOSIX_arm64 which is similar to Utility/RegisterContextLinux_* implemented by various other targets. This will help in managing register sets of new ARM64 architecture features in one place.

Built and tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabihf targets.

Reviewers: labath

Reviewed By: labath

Subscribers: mhorne, emaste, kristof.beyls, atanasyan, danielkiss, lldb-commits

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

show more ...

Fix LLDB elf core dump register access for ARM/AArch64

Summary:
This patch adds support to access AArch64 FP SIMD core dump registers and adds a test case to verify registers.

This patches fixes a

Fix LLDB elf core dump register access for ARM/AArch64

Summary:
This patch adds support to access AArch64 FP SIMD core dump registers and adds a test case to verify registers.

This patches fixes a bug where doing "register read --all" causes lldb to crash.

Reviewers: labath

Reviewed By: labath

Subscribers: kristof.beyls, danielkiss, lldb-commits

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

show more ...