[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][AArch64] Add SME2's ZT0 register (#70205)

SME2 is documented as part of the main SME supplement:
https://developer.arm.com/documentation/ddi0616/latest/

The one change for debug is this n

[lldb][AArch64] Add SME2's ZT0 register (#70205)

SME2 is documented as part of the main SME supplement:
https://developer.arm.com/documentation/ddi0616/latest/

The one change for debug is this new ZT0 register. This register
contains data to be used with new table lookup instructions.
It's size is always 512 bits (not scalable) and can be
interpreted in many different ways depending on the instructions
that use it.

The kernel has implemented this as a new register set containing
this single register. It always returns register data (with no header,
unlike ZA which does have a header).

https://docs.kernel.org/arch/arm64/sme.html

ZT0 is only active when ZA is active (when SVCR.ZA is 1). In the
inactive state the kernel returns 0s for its contents. Therefore
lldb doesn't need to create 0s like it does for ZA.

However, we will skip restoring the value of ZT0 if we know that
ZA is inactive. As writing to an inactive ZT0 sets SVCR.ZA to 1,
which is not desireable as it would activate ZA also. Whether
SVCR.ZA is set will be determined only by the ZA data we restore.

Due to this, I've added a new save/restore kind SME2. This is easier
than accounting for the variable length ZA in the SME data. We'll only
save an SME2 data block if ZA is active. If it's not we can get fresh
0s back from the kernel for ZT0 anyway so there's nothing for us to
restore.

This new register will only show up if the system has SME2 therefore
the SME set presented to the user may change, and I've had to account
for that in in a few places.

I've referred to it internally as simply "ZT" as the kernel does in
NT_ARM_ZT, but the architecture refers to the specific register as "ZT0"
so that's what you'll see in lldb.

```
(lldb) register read -s 6
Scalable Matrix Extension Registers:
svcr = 0x0000000000000000
svg = 0x0000000000000004
za = {0x00 <...> 0x00}
zt0 = {0x00 <...> 0x00}
```

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 ...

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] [Process/elf-core] Fix reading NetBSD/i386 core dumps

Add support for extracting basic data from NetBSD/i386 core dumps.
FPU registers are not supported at the moment.

Differential Revision:

[lldb] [Process/elf-core] Fix reading NetBSD/i386 core dumps

Add support for extracting basic data from NetBSD/i386 core dumps.
FPU registers are not supported at the moment.

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

show more ...

[lldb] [Process/elf-core] Fix reading FPRs from FreeBSD/i386 cores

The FreeBSD coredumps from i386 systems contain only FSAVE-style
NT_FPREGSET. Since we do not really support reading that kind of

[lldb] [Process/elf-core] Fix reading FPRs from FreeBSD/i386 cores

The FreeBSD coredumps from i386 systems contain only FSAVE-style
NT_FPREGSET. Since we do not really support reading that kind of data
anymore, just use NT_X86_XSTATE to get FXSAVE-style data when available.

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

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 ...

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 ...

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

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

show more ...

ProcessElfCore: Remove linux and freebsd NT_*** constants

These are already defined in llvm/BinaryFormat/ELF.h. Leaving the NetBSD
and OpenBSD constants as-is, as they have no llvm counterparts.

ll

ProcessElfCore: Remove linux and freebsd NT_*** constants

These are already defined in llvm/BinaryFormat/ELF.h. Leaving the NetBSD
and OpenBSD constants as-is, as they have no llvm counterparts.

llvm-svn: 368168

show more ...

[lldb] [Process/elf-core] Support aarch64 NetBSD core dumps

Include support for NetBSD core dumps from evbarm/aarch64 system,
and matching test cases for them.

Based on earlier work by Kamil Rytaro

[lldb] [Process/elf-core] Support aarch64 NetBSD core dumps

Include support for NetBSD core dumps from evbarm/aarch64 system,
and matching test cases for them.

Based on earlier work by Kamil Rytarowski.

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

llvm-svn: 357399

show more ...

[lldb] [Process] Add proper support for NetBSD core files with threads

Improve the support for processing NetBSD cores. Fix reading process
identifier, thread information and associating the termin

[lldb] [Process] Add proper support for NetBSD core files with threads

Improve the support for processing NetBSD cores. Fix reading process
identifier, thread information and associating the terminating signal
with the correct thread.

Includes test cases for single-threaded program receiving SIGSEGV,
and two dual-threaded programs: one where thread receives the signal,
and the other one when the whole process is signalled.

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

llvm-svn: 355736

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

elf-core: Convert remaining register context to use register set maps

In https://reviews.llvm.org/D39681, we started using a map instead
passing a long list of register sets to the ppc64le register

elf-core: Convert remaining register context to use register set maps

In https://reviews.llvm.org/D39681, we started using a map instead
passing a long list of register sets to the ppc64le register context.
However, existing register contexts were still using the old method.

This converts the remaining register contexts to use this approach.
While doing that, I've had to modify the approach a bit:
- the general purpose register set is still kept as a separate field,
because this one is always present, and it's parsing is somewhat
different than that of other register sets.
- since the same register sets have different IDs on different operating
systems, but we use the same register context class to represent
different register sets, I've needed to add a layer of indirection to
translate os-specific constants (e.g. NETBSD::NT_AMD64_FPREGS) into more
generic terms (e.g. floating point register set).

While slightly more complicated, this setup allows for better separation
of concerns. The parsing code in ProcessElfCore can focus on parsing
OS-specific core file notes, and can completely ignore
architecture-specific register sets (by just storing any unrecognised
notes in a map). These notes will then be passed on to the
architecture-specific register context, which can just deal with
architecture specifics, because the OS-specific note types are hidden in
a register set description map.

This way, adding an register set, which is already supported on other
OSes, to a new OS, should in most cases be as simple as adding a new
entry into the register set description map.

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

llvm-svn: 319162

show more ...