In this PR we are proposing to change LLDB codebase so that LLDB is able to print values of integer registers that have more than 64-bits (even if the number of bits is not equal to 128). --------- Co-authored-by: Matej Košík <matej.kosik@codasip.com> Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This patch deprecates an APInt constructor that has been soft-deprecated via comments since: commit 7a16288157efc5fb85fbe3b8b4c37071da7609a6 Author: Jeffrey Yasskin <jyasskin@google.com> Date: Mon Jul 18 21:45:40 2011 +0000 This patch updates a small number of remaining uses.
Fix the `RegisterValue::SetValueFromData` method so that it works also
for 128-bit registers that contain integers.
Without this change, the `RegisterValue::SetValueFromData` method does
not work correctly
for 128-bit registers that contain (signed or unsigned) integers.
---
Steps to reproduce the problem:
(1)
Create a program that writes a 128-bit number to a 128-bit registers
`xmm0`. E.g.:
```
#include <stdint.h>
int main() {
__asm__ volatile (
"pinsrq $0, %[lo], %%xmm0\n\t" // insert low 64 bits
"pinsrq $1, %[hi], %%xmm0" // insert high 64 bits
:
: [lo]"r"(0x7766554433221100),
[hi]"r"(0xffeeddccbbaa9988)
);
return 0;
}
```
(2)
Compile this program with LLVM compiler:
```
$ $YOUR/clang -g -o main main.c
```
(3)
Modify LLDB so that when it will be reading value from the `xmm0`
register, instead of assuming that it is vector register, it will treat
it as if it contain an integer. This can be achieved e.g. this way:
```
diff --git a/lldb/source/Utility/RegisterValue.cpp b/lldb/source/Utility/RegisterValue.cpp
index 0e99451c3b70..a4b51db3e56d 100644
--- a/lldb/source/Utility/RegisterValue.cpp
+++ b/lldb/source/Utility/RegisterValue.cpp
@@ -188,6 +188,7 @@ Status RegisterValue::SetValueFromData(const RegisterInfo ®_info,
break;
case eEncodingUint:
case eEncodingSint:
+ case eEncodingVector:
if (reg_info.byte_size == 1)
SetUInt8(src.GetMaxU32(&src_offset, src_len));
else if (reg_info.byte_size <= 2)
@@ -217,23 +218,6 @@ Status RegisterValue::SetValueFromData(const RegisterInfo ®_info,
else if (reg_info.byte_size == sizeof(long double))
SetLongDouble(src.GetLongDouble(&src_offset));
break;
- case eEncodingVector: {
- m_type = eTypeBytes;
- assert(reg_info.byte_size <= kMaxRegisterByteSize);
- buffer.bytes.resize(reg_info.byte_size);
- buffer.byte_order = src.GetByteOrder();
- if (src.CopyByteOrderedData(
- src_offset, // offset within "src" to start extracting data
- src_len, // src length
- buffer.bytes.data(), // dst buffer
- buffer.bytes.size(), // dst length
- buffer.byte_order) == 0) // dst byte order
- {
- error = Status::FromErrorStringWithFormat(
- "failed to copy data for register write of %s", reg_info.name);
- return error;
- }
- }
}
if (m_type == eTypeInvalid)
```
(4)
Rebuild the LLDB.
(5)
Observe what happens how LLDB will print the content of this register
after it was initialized with 128-bit value.
```
$YOUR/lldb --source ./main
(lldb) target create main
Current executable set to '.../main' (x86_64).
(lldb) breakpoint set --file main.c --line 11
Breakpoint 1: where = main`main + 45 at main.c:11:3, address = 0x000000000000164d
(lldb) settings set stop-line-count-before 20
(lldb) process launch
Process 2568735 launched: '.../main' (x86_64)
Process 2568735 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
frame #0: 0x000055555555564d main`main at main.c:11:3
1 #include <stdint.h>
2
3 int main() {
4 __asm__ volatile (
5 "pinsrq $0, %[lo], %%xmm0\n\t" // insert low 64 bits
6 "pinsrq $1, %[hi], %%xmm0" // insert high 64 bits
7 :
8 : [lo]"r"(0x7766554433221100),
9 [hi]"r"(0xffeeddccbbaa9988)
10 );
-> 11 return 0;
12 }
(lldb) register read --format hex xmm0
xmm0 = 0x7766554433221100ffeeddccbbaa9988
```
You can see that the upper and lower 64-bit wide halves are swapped.
---------
Co-authored-by: Matej Košík <matej.kosik@codasip.com>
This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ` ResultTy DoFoo(Status& error) ` to ` llvm::Expected<ResultTy> DoFoo() ` How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly ` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) ` plus the occasional manual cleanup.
Size was clearly not correct here. This call has been here since the initial reformat of all of lldb so it has likely always been incorrect. (although registers don't typically have an endian, they are just values, in the remote protocol register data is in target endian) This might have been a problem for Neon registers on big endian AArch64, but only if the debug server describes them as integers. lldb-server does not, they've always been vectors which doesn't take this code path. Not adding a test because the way I've mocked up a big endian target in the past is using s390x as the architecture. This apparently has some form of vector extension that may be 128 bit but lldb doesn't support it.
Differential Revision: https://reviews.llvm.org/D155030
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
No one was pasing nullptr here. Depends on D135670 Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D135671
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
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