`Instruction::TestEmulation` takes a `Stream *` and checks it for validity.
However, this is unnecessary as we can always ensure that we never pass
`nullptr` for the `Stream` argument. The only use of
`Instruction::TestEmulation` currently is `SBInstruction::TestEmulation`
which gets the `Stream` from an `SBStream`, and `SBStream::ref` can
return a `Stream &` guaranteed.
Differential Revision: https://reviews.llvm.org/D154757
Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we support is Arm's scalable vectors (SVE) which can be up to 256 bytes long.
This means for most operations aside from SVE, we're wasting 192 bytes
of it. Which is ok given that we don't have to pay the cost of a heap
alocation and 256 bytes isn't all that much overall.
With the introduction of the Arm Scalable Matrix extension there is a new
array storage register, ZA. This register is essentially a square made up of
SVE vectors. Therefore ZA could be up to 64kb in size.
https://developer.arm.com/documentation/ddi0616/latest/
"The Effective Streaming SVE vector length, SVL, is a power of two in the range 128 to 2048 bits inclusive."
"The ZA storage is architectural register state consisting of a two-dimensional ZA array of [SVLB × SVLB] bytes."
99% of operations will never touch ZA and making every stack frame 64kb+ just
for that slim chance is a bad idea.
Instead I'm switching register handling to use SmallVector with a stack allocation
size of kTypicalRegisterByteSize. kMaxRegisterByteSize will be used in places
where we can't predict the size of register we're reading (in the GDB remote client).
The result is that the 99% of small register operations can use the stack
as before and the actual ZA operations will move to the heap as needed.
I tested this by first working out -wframe-larger-than values for all the
libraries using the arrays previously. With this change I was able to increase
kMaxRegisterByteSize to 256*256 without hitting those limits. With the
exception of the GDB server which needs to use a max size buffer.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D153626
Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's no
value, instead of being unable to distinguish between the absence of a
value and the value happening the match the fail value. When a fail
value is required, std::optional::value_or() provides the same
functionality.
llvm has a structure for maps where the key's type is a string. Using
that also means that the keys for OptionValueDictionary don't stick
around forever in ConstString's StringPool (even after they are gone).
The only thing we lose here is ordering: iterating over the map where the keys
are ConstStrings guarantees that we iterate in alphabetical order.
StringMap makes no guarantees about the ordering when you iterate over
the entire map.
Differential Revision: https://reviews.llvm.org/D149482
This structure is supposed to be trivial, so we cannot simply do
"= nullptr;" on the new member. Doing that means you are non trivial,
regardless of whether you emulate the previously implied constructor somehow.
The next option is to update every use of brace initialisation.
Given that this is some hundreds of lines, this change just adds a dummy
pointer that is set to nullptr. Subsequent changes will actually use that
to point to register flags information.
Note: This change is not clang-format-ted because it changes a bunch of
areas that are not themselves formatted. It would just add noise.
Reviewed By: jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D145568
Add floating-point branch Instructions for EmulateInstructionLoongArch and
add relevant unit tests.
Without this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.45s
Passed: 1044
```
With this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.20s
Passed: 1048
```
Reviewed By: SixWeining, MaskRay, DavidSpickett
Differential Revision: https://reviews.llvm.org/D140759
RVC is the RISC-V standard compressed instruction-set extension, named "C", which reduces static and dynamic code size by adding short 16-bit instruction encodings for common operations, and RVCD is the compressed "D extension".
And "D extension" is a double-precision floating-point instruction-set extension, which adds double-precision floating-point computational instructions compliant with the IEEE 754-2008 arithmetic standard.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D140961
Add unit tests For EmulateInstructionLoongArch existing branch instruction.
Add 19 test cases in total.
Without this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.55s
Passed: 1025
```
With this patch:
```
$ ninja check-lldb-unit
[0/1] Running lldb unit test suite
Testing Time: 10.45s
Passed: 1044
```
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D140386
This is a code optimization patch that does not include feature additions
or deletions.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D140616
This patch fixes:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp:1378:16:
warning: control reaches end of non-void function [-Wreturn-type]
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
std::optional::value() has undesired exception checking semantics and is
unavailable in some older Xcode. The call sites block std::optional migration.
Add conditional and unconditional branch instructions for loongarch64.
Note that this does not include floating-point branch instructions, that will come in a later patch.
Reviewed By: SixWeining, DavidSpickett
Differential Revision: https://reviews.llvm.org/D139833
This patch fixes:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp:1402:18:
error: default label in switch which covers all enumeration values
[-Werror,-Wcovered-switch-default]
RVD extension is a double-precision floating-point instruction-set extension, which adds double-precision floating-point computational instructions compliant with the IEEE 754-2008 arithmetic standard.
This patch:
- Reuse most of the functions in the "F extension" to impl the"D extension"
- corresponding unittests.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D140032
The `EmulateInstructionRISCV` uses a lot of types and functions in `llvm` and `lldb`, this change is to make the code look cleaner.
PS: This patch should be merged before D140032.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D140092
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
Some headers in LLDB work only when considered as textual inclusion, but not if one attempts to use them on their own or with a different context.
- python-typemaps.h: uses Python definitions without using "Python.h".
- RISCVCInstructions.h uses RISC-V register enums without including the enums header.
- RISCVInstructions.h includes EmulateInstructionRISCV.h, but is unnecessary since we forward-declare EmulateInstructionRISCV anyway. Including the header is problematic because EmulateInstructionRISCV.h uses DecodeResult which isn't defined until later in RISCVInstructions.h.
This makes LLDB build cleanly with the "parse_headers" feature [1]. I'm not sure what the analagous CMake option is.
[1] I didn't find public documentation but @MaskRay wrote this up: https://maskray.me/blog/2022-09-25-layering-check-with-clang#parse_headers
Reviewed By: labath, MaskRay
Differential Revision: https://reviews.llvm.org/D138310
This patch fixes:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp:105:18:
warning: comparison of unsigned expression in ‘>= 0’ is always true
[-Wtype-limits]
Making it easier to understand and harder to misuse.
This only applies to the ReadRegister(const RegisterInfo ®_info) variant.
Depends on D135671
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D135672
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
Most of the paths to this never passed nullptr intentionally. Those
that possibly could have were assuming it was not null elsehwere,
so would have crashed.
I've added asserts in those cases.
At least one case was relying on GetAsMemoryData to return an error
when it was given nullptr. So I've hoisted that error setting code
out into the caller.
Depends on D134963
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134965
WriteRegister and WriteRegisterUnsigned were never pased nullptr,
and only one of them appeared to handle it. Switch to ref to make
the intent clear.
Depends on D134962
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134963
ReadRegister and ReadRegisterAsUnsigned are always passed valid pointers,
so the parameter should be a ref to make the intent clear.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D134962
