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.
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
LLDB's logging infrastructure supports prepending log messages with the name of the file and function that generates the log (see help log enable). Therefore it's unnecessary to include the current __FUNCTION__ in the log message itself. This patch removes __FUNCTION__ from log messages in the Host library. Differential revision: https://reviews.llvm.org/D151762
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
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.
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
Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041