`GetRegisterInfo` hardcodes to use `RegisterInfoPOSIX_riscv64` instead
of checking the triple to determine whether to use
`RegisterInfoPOSIX_riscv64` or `RegisterInfoPOSIX_riscv32`.
Someone put up a [PR](https://github.com/llvm/llvm-project/pull/175262)
for this, but seems to have removed their account and the associated PR
with it.
Fixes#175092
A function prologue can begin with a pre-index STR instruction for a
floating-point register. To construct an unwind plan from assembly
correctly, the instruction emulator must support such instructions.
This patch fixes 2 fundamental problems in emulating `FLW`, `FSW`, `FLD`
and `FSD` instructions.
1. Instructions immediate wasn't sign extended
2. Store instructions always wrote for 64 bits to memory
Also this patch fixes 2 lldb tests for RISC-V: TestThreadJump.py and
TestBreakpointHitCount.py
In RISC-V, the same instruction is used for both signed and unsigned
additions.
Signed integer overflow is undefined behavior in C++, but signed integer
overflow is defined behavior when using ADDI in RISC-V.
As we are emulating the RISC-V behavior we should be using uint.
This fix the failure with ubsan introduced by #159842:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp:807:40:
runtime error: signed integer overflow: -9223372036854775808 + -16
cannot be represented in type 'int64_t' (aka 'long')
Initial PR was reverted due failing test since the buildbots don't
include the RISCV backend.
---------
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
**Added emulator unwinding support for RISCV files.**
Emulated Instructions:
ADD (addi sp, sp, imm)
STORE (sd ra, offset(sp))
LOAD (ld ra, offset(sp)).
We had to overwrite SetInstructions() since UnwindAssemblyInstEmulation
calls EvaluateInstruction() directly after calling SetInstruction(), but
it never calls ReadInstruction(). This means that the m_decoded member
variable in the instruction emulator is never properly initialized. By
overriding SetInstruction(), we decode the instruction bytes and set
m_decoded directly. This ensures that subsequent emulation (including
unwinding) operates on the correct instruction.
We also had to change the the OpCode GetOpcodeBytes function since
recent changes made it so GetOpcodeBytes will return None for type
eType16_32Tuples (an alternative and longer way, would've been to type
check during the overwritten SetInstruction() and call a DataExtractor
with .GetU16(&offset) to set the inst_data.
Added a test - TestSimpleRiscvFunction (took inspiration from:
[link](https://github.com/llvm/llvm-project/blob/main/lldb/unittests/UnwindAssembly/ARM64/TestArm64InstEmulation.cpp))
[----------] 1 test from TestRiscvInstEmulation
[ RUN ] TestRiscvInstEmulation.TestSimpleRiscvFunction
[ OK ] TestRiscvInstEmulation.TestSimpleRiscvFunction (1 ms)
[----------] 1 test from TestRiscvInstEmulation (1 ms total)
[----------] Global test environment tear-down
[==========] 63 tests from 5 test suites ran. (11 ms total)
[ PASSED ] 63 tests.
---------
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
This reverts commit 600976f4bfb06526c283dcc4efc4801792f08ca5.
The test was crashing trying to access any element of the GPR struct.
(gdb) disas
Dump of assembler code for function _ZN7testing8internal11CmpHelperEQIyyEENS_15AssertionResultEPKcS4_RKT_RKT0_:
0x00450afc <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0x00450b00 <+4>: sub sp, sp, #60 ; 0x3c
0x00450b04 <+8>: ldr r5, [sp, #96] ; 0x60
=> 0x00450b08 <+12>: ldm r3, {r4, r7}
0x00450b0c <+16>: ldm r5, {r6, r9}
0x00450b10 <+20>: eor r7, r7, r9
0x00450b14 <+24>: eor r6, r4, r6
0x00450b18 <+28>: orrs r7, r6, r7
(gdb) p/x r3
$3 = 0x3e300f6e
"However, load and store multiple instructions (LDM and STM) and load and store double-word (LDRD or STRD) must be aligned to at least a word boundary."
https://developer.arm.com/documentation/den0013/d/Porting/Alignment
>>> 0x3e300f6e % 4
2
Program received signal SIGBUS, Bus error.
0x00450b08 in testing::AssertionResult testing::internal::CmpHelperEQ<unsigned long long, unsigned long long>(char const*, char const*, unsigned long long const&, unsigned long long const&) ()
The struct is packed with 1 byte alignment, but it needs to start at an aligned address for us
to ldm from it. So I've done that with alignas.
Also fixed some compiler warnings in the test itself.
The `EmulateInstructionARM64::EvaluateInstruction()` method used
`uint32_t` to store the PC value, causing addresses greater than 2^32 to
be truncated.
As for now, the issue does not affect the mainline because the method is
never called with both `eEmulateInstructionOptionAutoAdvancePC` and
`eEmulateInstructionOptionIgnoreConditions` options set. However, it can
trigger on a downstream that uses software stepping.
lldb-server had limited support for single-stepping through the lr/sc
atomic sequence. This patch enhances that support for all possible
atomic sequences.
The previous version contained an incorrect regex pattern in the test,
causing the riscv-specific test to run on other platforms. This reland
fixes the regex (see lldb/test/API/riscv/step/TestSoftwareStep.py)
lldb-server had limited support for single-stepping through the lr/sc
atomic sequence. This patch enhances that support for all possible
atomic sequences.
Some inter-plugin dependencies are okay, others are not. Yet others not,
but we're sort of stuck with them. The idea is to be able to prevent
backsliding while making sure that acceptable dependencies are..
accepted. For context, see
https://github.com/llvm/llvm-project/pull/139170 and the attached
changes to the documentation.
If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.
This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.
For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.
The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.
The PR adds the support optionally enabled/disabled FP-registers to LLDB
`RegisterInfoPOSIX_riscv64`. This situation might take place for RISC-V
builds having no FP-registers, like RV64IMAC or RV64IMACV.
To aim this, patch adds `opt_regsets` flags mechanism. It re-works
RegisterInfo class to work with flexibly allocated (depending on
`opt_regsets` flag) `m_register_sets` and `m_register_infos` vectors
instead of statically defined structures. The registration of regsets is
being arranged by `m_per_regset_regnum_range` map.
The patch flows are spread to `NativeRegisterContextLinux_riscv64` and
`RegisterContextCorePOSIX_riscv64` classes, that were tested on:
- x86_64 host working with coredumps
- RV64GC and RV64IMAC targets working with coredumps and natively in
run-time with binaries
`EmulateInstructionRISCV` is out of scope of this patch, and its
behavior did not change, using maximum set of registers.
According testcase built for RV64IMAC (no-FPR) was added to
`TestLinuxCore.py`.
This patch adds an interface GetLastInstrSize to get information about
the size of last tried to be decoded instruction and uses it to set
software breakpoint if the memory can be decoded as instruction.
RISC-V architecture instruction format specifies the length of
instruction in first bits, so we can set a breakpoint for these cases.
This is needed as RISCV have a lot of extensions, that are not supported
by `EmulateInstructionRISCV`.
…unction (#91321)"
This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was
reverted due to a test failure on aarch64/windows. The failure was
caused by a combination of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang
targeting other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `<same>` unwind rules
is recursive
- the test binary creates a very long chain of fp-less function frames
(it manages to fit about 22k frames before it blows its stack)
Together, these things have caused lldb to recreate the same deep
recursion when unwinding through this, and blow its own stack as well.
Since lldb frames are larger, about 4k frames like this was sufficient
to trigger the stack overflow.
This version of the patch works around this problem by increasing the
frame size of the test binary, thereby causing it to blow its stack
sooner. This doesn't fix the issue -- the same problem can occur with a
real binary -- but it's not very likely, as it requires an infinite
recursion in a simple (so it doesn't use the frame pointer) function
with a very small frame (so you can fit a lot of them on the stack).
A more principled fix would be to make lldb's lookup code non-recursive,
but I believe that's out of scope for this patch.
The original patch description follows:
A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.
To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = <same>`
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`<same>` rule.
- allows the `<same>` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).
The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.
This reverts commit fd1bd53ba5a06f344698a55578f6a5d79c457e30.
TestInterruptBacktrace was broken on AArch64/Windows as a result of this change.
See lldb-aarch64-windows buildbot here:
https://lab.llvm.org/buildbot/#/builders/219/builds/11261
A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.
To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = <same>`
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`<same>` rule.
- allows the `<same>` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).
The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.
`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.
