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.
This patch implements the thread local storage support for linux (https://github.com/llvm/llvm-project/issues/28766). TLS feature is originally only implemented for Mac. With my previous patch to enable `fs_base` register for Linux (https://reviews.llvm.org/D155256), now it is feasible to implement this feature for Linux. The major changes are: * Track the main module's link address during launch * Fetch thread pointer from `fs_base` register * Create register alias for thread pointer * Read pthread metadata from target memory instead of process so that it works for coredump With the patch the failing test is passing now. Note: I am only enabling this test for Mac and Linux because I do not have machine to test for FreeBSD/NetBSD. --------- Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
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
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
The previous version of the patch did not update the definitions in conditionally compiled code. This patch includes changes to ARC and windows targets. Original commit message was: These were added to support some mips registers on linux, but linux mips support has now been removed due. They are still referenced in the freebds mips implementation, but the completeness of that implementation is also unknown. All other architectures just set these fields to zero, which is a cause of significant bloat in our register info definitions. Arm also has registers with variable sizes, but they were implemented in a more gdb-compatible fashion and don't use this feature. Differential Revision: https://reviews.llvm.org/D110914
This reverts commit 00e704bf080ffeeb9e334fb3ab71594f9aa50969. This commit should should have updated llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other architectures.
These were added to support some mips registers on linux, but linux mips support has now been removed due. They are still referenced in the freebds mips implementation, but the completeness of that implementation is also unknown. All other architectures just set these fields to zero, which is a cause of significant bloat in our register info definitions. Arm also has registers with variable sizes, but they were implemented in a more gdb-compatible fashion and don't use this feature. Differential Revision: https://reviews.llvm.org/D110914
Update GetRegisterInfoByName() methods to support getting registers by a generic name independently of alt_name entries in the register context. This makes it possible to use generic names when interacting with gdbserver (that does not supply alt_names). It also makes it possible to remove some of the duplicated information from register context declarations and/or use alt_names for another purpose. Differential Revision: https://reviews.llvm.org/D108554