While fixing bugs in the x86_64 LC_THREAD parser in ObjectFileMachO, I noticed that the other LC_THREAD parsers are all less clear than they should be. To recap, a Mach-O LC_THREAD load command has a byte size for the entire payload. Within the payload, there will be one or more register sets provided. A register set starts with a UInt32 "flavor", the type of register set defined in the system headers, and a UInt32 "count", the number of UInt32 words of memory for this register set. After one register set, there may be additional sets. A parser can skip an unknown register set flavor by using the count field to get to the next register set. When the total byte size of the LC_THREAD load command has been parsed, it is completed. This patch fixes the riscv/arm/arm64 LC_THREAD parsers to use the total byte size as the exit condition, and to skip past unrecognized register sets, instead of stopping parsing. Instead of fixing the i386 corefile support, I removed it. The last macOS that supported 32-bit Intel code was macOS 10.14 in 2018. I also removed i386 KDP support, 32-bit intel kernel debugging hasn't been supported for even longer than that. It would be preferable to do these things separately, but I couldn't bring myself to update the i386 LC_THREAD parser, and it required very few changes to remove this support entirely.
GetUnwinder now returns a reference instead of a pointer.
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
Summary: One of the conclusions of the discussion on D49740 was that SafeMachO is better off in the Host module (as that's the only place which should include mach/machine.h, which is what this header is working around). Also, Utility, which is the only module which cannot include Host, should not be doing anything with object file formats. This patch implements that move, and also removes any unneded includes of that file. I've verified that MacOS still compiles after this. Reviewers: jingham, zturner, teemperor Subscribers: fedor.sergeev, lldb-commits Differential Revision: https://reviews.llvm.org/D50383 llvm-svn: 342050
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
Summary: This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495 The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it. Reviewers: asmith, zturner, aleksandr.urakov Reviewed By: aleksandr.urakov Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits Differential Revision: https://reviews.llvm.org/D49111 llvm-svn: 336732