RVV stands for "RISC-V V Extension", which adds 32 vector registers, and seven unprivileged CSRs (vstart, vxsat, vxrm, vcsr, vtype, vl, vlenb) to a base scalar RISC-V ISA.
The base vector extension is intended to provide general support for data-parallel execution within the 32-bit instruction encoding space, with later vector extensions supporting richer functionality for certain domains.
Reviewed By: DavidSpickett, kito-cheng
Differential Revision: https://reviews.llvm.org/D141898
It seems like these were copied from the single-step code and not
updated to match the new flags.
Differential revision: https://reviews.llvm.org/D141816
In RegisterInfos_loongarch64.h, r22 is defined twice. Having an extra array
member causes problems reading and writing registers defined after r22. So,
for r22, keep the alias fp, delete the s9 alias.
The PC register is incorrectly accessed when the step command is executed.
The step command behavior is incorrect.
This test reflects this problem:
```
loongson@linux:~$ cat test.c
#include <stdio.h>
int func(int a) {
return a + 1;
}
int main(int argc, char const *argv[]) {
func(10);
return 0;
}
loongson@linux:~$ clang -g test.c -o test
```
Without this patch:
```
loongson@linux:~$ llvm-project/llvm/build/bin/lldb test
(lldb) target create "test"
Current executable set to '/home/loongson/test' (loongarch64).
(lldb) b main
Breakpoint 1: where = test`main + 40 at test.c:8:3, address = 0x0000000120000668
(lldb) r
Process 278049 launched: '/home/loongson/test' (loongarch64)
Process 278049 stopped
* thread #1, name = 'test', stop reason = breakpoint 1.1
frame #0: 0x0000000120000668 test`main(argc=1, argv=0x00007fffffff72a8) at test.c:8:3
5 }
6
7 int main(int argc, char const *argv[]) {
-> 8 func(10);
9 return 0;
10 }
11
(lldb) s
Process 278049 stopped
* thread #1, name = 'test', stop reason = step in
frame #0: 0x0000000120000670 test`main(argc=1, argv=0x00007fffffff72a8) at test.c:9:3
6
7 int main(int argc, char const *argv[]) {
8 func(10);
-> 9 return 0;
10 }
```
With this patch:
```
loongson@linux:~$ llvm-project/llvm/build/bin/lldb test
(lldb) target create "test"
Current executable set to '/home/loongson/test' (loongarch64).
(lldb) b main
Breakpoint 1: where = test`main + 40 at test.c:8:3, address = 0x0000000120000668
(lldb) r
Process 278632 launched: '/home/loongson/test' (loongarch64)
Process 278632 stopped
* thread #1, name = 'test', stop reason = breakpoint 1.1
frame #0: 0x0000000120000668 test`main(argc=1, argv=0x00007fffffff72a8) at test.c:8:3
5 }
6
7 int main(int argc, char const *argv[]) {
-> 8 func(10);
9 return 0;
10 }
11
(lldb) s
Process 278632 stopped
* thread #1, name = 'test', stop reason = step in
frame #0: 0x0000000120000624 test`func(a=10) at test.c:4:10
1 #include <stdio.h>
2
3 int func(int a) {
-> 4 return a + 1;
5 }
```
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D140615
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
Hardware single stepping is not currently supported by the linux kernel.
In order to support single step debugging, add EmulateInstructionLoongArch
to implement the software Single Stepping. This patch only support the
simplest single step execution of non-jump instructions.
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D139158
Hardware single stepping is not currently supported by the linux kernel.
In order to support single step debugging, add EmulateInstructionLoongArch
to implement the software Single Stepping. This patch only support the
simplest single step execution of non-jump instructions.
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D139158
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Use the same register layout as Linux kernel, implement the
related read and write operations.
Reviewed By: SixWeining, xen0n, DavidSpickett
Differential Revision: https://reviews.llvm.org/D138407
Allow users to access FPR registers by names or ABI names.
PS: This patch should be merged after D137508
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D137761
This patch uses RISCV ABI register name as `alt_name` in `RegisterInfo` in `lldb-private-types.h`
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D137508
When a process gets restarted TypeSystem objects associated with it
may get deleted, and any CompilerType objects holding on to a
reference to that type system are a use-after-free in waiting. Because
of the SBAPI, we don't have tight control over where CompilerTypes go
and when they are used. This is particularly a problem in the Swift
plugin, where the scratch TypeSystem can be restarted while the
process is still running. The Swift plugin has a lock to prevent
abuse, but where there's a lock there can be bugs.
This patch changes CompilerType to store a std::weak_ptr<TypeSystem>.
Most of the std::weak_ptr<TypeSystem>* uglyness is hidden by
introducing a wrapper class CompilerType::WrappedTypeSystem that has a
dyn_cast_or_null() method. The only sites that need to know about the
weak pointer implementation detail are the ones that deal with
creating TypeSystems.
rdar://101505232
Differential Revision: https://reviews.llvm.org/D136650
Add as little code as possible to allow compiling lldb on LoongArch.
Actual functionality will be implemented later.
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D136578
Familiar story, callers are either checking upfront that the pointer
wasn't null or not checking at all. SetValueFromData itself didn't
check either.
So make the parameter a ref and fixup the few places where a nullptr
check seems needed.
Depends on D135668
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D135670
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead.
Differential Revision: https://reviews.llvm.org/D133501
Using GetTargetArchitecture() instead of m_target_arch, and set m_target_arch to private.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D132353
Suppress coverity false positives.
This diff contains comments only, including the hints for Coverity static code inspection
to suppress the warning originating at the next line after the comment.
Differential Revision: https://reviews.llvm.org/D131998
Add:
- `EmulateInstructionRISCV`, which can be used for riscv32 and riscv64.
- Add unittests for EmulateInstructionRISCV.
Note: Compressed instructions set (RVC) was still not supported in this patch.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131759
Some architectures do not have a flag register (like riscv).
In this case, we should set it to `baton.m_register_values.end()` to avoid nullptr exception.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131945
This patch improve exception reporting when loading a crash report in a
scripted process. Now, we parse the `exception` dictionary from the
crash report use it the create a higher fidelity `MachException` stop info.
This patch also updates the test to reflect that change.
rdar://97096486
Differential Revision: https://reviews.llvm.org/D131086
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is based on the minimal extract of D128250.
What is implemented:
- Use the same register layout as Linux kernel and mock read/write for `x0` register (the always zero register).
- Refactor some duplicate code, and delete unused register definitions.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D130342
We don't want the DEFINE_ macros or the array registers
being clang formatted.
RegisterInfos_arm64.h was missing the off annotation and
RegisterInfos_arm64_sve.h needed the off moving to before
the macro definitions.
Jason noted that the stop message we print for a memory high water mark
notification (EXC_RESOURCE) could be clearer. Currently, the stop
reason looks like this:
* thread #3, queue = 'com.apple.CFNetwork.LoaderQ', stop reason =
EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=14 MB, unused=0x0)
It's hard to read the message because the exception and the type
(EXC_RESOURCE RESOURCE_TYPE_MEMORY) blend together. Additionally, the
"observed=0x0" should not be printed for memory limit exceptions.
I wanted to continue to include the resource type from
<kern/exc_resource.h> while also explaining what it actually is. I used
the wording from the comments in the header. With this path, the stop
reason now looks like this:
* thread #5, stop reason = EXC_RESOURCE (RESOURCE_TYPE_MEMORY: high
watermark memory limit exceeded) (limit=14 MB)
rdar://40466897
Differential revision: https://reviews.llvm.org/D131130
The kernel was rejecting sizeof(struct GPR) as it was not a multiple of
8. Add a padding field to fix that.
One also wonders whether "cpsr" is right register name for aarch64.
Currently, lldb-server was opening the executable file to determine the
process architecture (to differentiate between 32 and 64 bit
architecture flavours). This isn't a particularly trustworthy source of
information (the file could have been changed since the process was
started) and it is not always available (file could be deleted or
otherwise inaccessible).
Unfortunately, ptrace does not give us a direct API to access the
process architecture, but we can still infer it via some of its
responses -- given that the general purpose register set of 64-bit
applications is larger [citation needed] than the GPR set of 32-bit
ones, we can just ask for the application GPR set and check its size.
This is what this patch does.
Differential Revision: https://reviews.llvm.org/D130985
Fixing potential int overflow and uninitialized variables.
These were found by Coverity static code inspection.
Differential Revision: https://reviews.llvm.org/D130795
82d4f39f342165a92eaa1fe74488158942cf27b4 marked an unused
var of mine (thanks Dmitri Gribenko!). Which reminded me lldb has
a macro just for that purpose.
This is the first part of support for reading MTE tags from Linux
core files. The format is documented here:
https://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html#core-dump-support
This patch adds a method to unpack from the format the core
file uses, which is different to the one chosen for GDB packets.
MemoryTagManagerAArch64MTE is not tied one OS so another OS
might choose a different format in future. However, infrastructure
to handle that would go untested until then so I've chosen not to
attempt to handle that.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D129487
Fix modernize-use-override warnings. Because this check is listed in
LLDB's top level .clang-tidy configuration, the check is enabled by
default and the resulting warnings show up in my editor.
I've audited the modified lines. This is not a blind change.
Move them to the only source file that included RegisterInfos_arm64.h
that actually used these variables.
This silences warnings like these:
In file included from lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp:42:
lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h:790:35: warning: ‘g_register_infos_mte’ defined but not used [-Wunused-variable]
790 | static lldb_private::RegisterInfo g_register_infos_mte[] = {
| ^~~~~~~~~~~~~~~~~~~~
lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h:787:35: warning: ‘g_register_infos_pauth’ defined but not used [-Wunused-variable]
787 | static lldb_private::RegisterInfo g_register_infos_pauth[] = {
| ^~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D123206
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
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
