ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.
The header includes were updated with the following command:
```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```
lldb has two RegisterLocation classes that do slightly different things. UnwindPlan::Row::RegisterLocation (new: AbstractRegisterLocation) has a description of how to find a register's value or location, not specific to a particular stopping point. It may say that at a given offset into a function, the caller's register has been spilled to stack memory at CFA minus an offset. Or it may say that the caller's register is at a DWARF exprssion. UnwindLLDB::RegisterLocation (new: ConcreteRegisterLocation) is a specific address where the register is currently stored, or the register it has been copied into, or its value at this point in the current function execution. When lldb stops in a function, it interprets the AbstractRegisterLocation's instructions using the register context and stack memory, to create the ConcreteRegisterLocation at this point in time for this stack frame. I'm not thrilled with AbstractRegisterLocation and ConcreteRegisterLocation, but it's better than the same name and it will be easier to update them if someone suggests a better pair.
[lldb] Add SBProcess methods for get/set/use address masks (#83095) I'm reviving a patch from phabracator, https://reviews.llvm.org/D155905 which was approved but I wasn't thrilled with all the API I was adding to SBProcess for all of the address mask types / memory regions. In this update, I added enums to control type address mask type (code, data, any) and address space specifiers (low, high, all) with defaulted arguments for the most common case. I originally landed this via https://github.com/llvm/llvm-project/pull/83095 but it failed on CIs outside of arm64 Darwin so I had to debug it on more environments and update the patch. This patch is also fixing a bug in the "addressable bits to address mask" calculation I added in AddressableBits::SetProcessMasks. If lldb were told that 64 bits are valid for addressing, this method would overflow the calculation and set an invalid mask. Added tests to check this specific bug while I was adding these APIs. This patch changes the value of "no mask set" from 0 to LLDB_INVALID_ADDRESS_MASK, which is UINT64_MAX. A mask of all 1's means "no bits are used for addressing" which is an impossible mask, whereas a mask of 0 means "all bits are used for addressing" which is possible. I added a base class implementation of ABI::FixCodeAddress and ABI::FixDataAddress that will apply the Process mask values if they are set to a value other than LLDB_INVALID_ADDRESS_MASK. I updated all the callers/users of the Mask methods which were handling a value of 0 to mean invalid mask to use LLDB_INVALID_ADDRESS_MASK. I added code to the all AArch64 ABI Fix* methods to apply the Highmem masks if they have been set. These will not be set on a Linux environment, but in TestAddressMasks.py I test the highmem masks feature for any AArch64 target, so all AArch64 ABI plugins must handle it. rdar://123530562
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.
Call ABI::AugmentRegisterInfo() once with a vector of all defined registers rather than calling it for every individual register. Move and rename RemoteRegisterInfo from gdb-remote to DynamicRegisterInfo::Register, and use this class when augmenting registers. Differential Revision: https://reviews.llvm.org/D111142
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage. https://reviews.llvm.org/D96537
This class and it's surroundings contain a lot of shady code, but as far as I can tell all of that code is unreachable (there is no code actually setting the value to eValueTypeVector). According to history this class was introduced in 2012 in r167033/0665a0f09. At that time, the code seemed to serve some purpose, and it had two entry points (in Value::SetContext and ClangExpressionDeclMap::LookupDecl). The first entry point was deleted in D17897 and the second one in r179842/44342735. The stated purpose of the patch introducing this class was to fix TestRegisters.py, and "expr $xmm0" in particular. Both of these things function perfectly well these days without this class.
RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for that is that `DynamicRegisterInfo::GetRegisterInfo` and `RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by name by only comparing the C string pointer values instead of the underlying strings. This only works if both C strings involved in the comparison come from a ConstString. If one of the two C strings doesn't come from a ConstString the comparison won't work (and most likely will silently fail). I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that both strings come from a ConstString. Apparently not all ABI plugins are generating their register names via ConstString, so this code is now not just silently failing but also asserting. In D88375 we did a shady fix for the MIPS plugins by just copying the ConstString setup code to that plugin, but we still need to fix ABISysV_arc, ABISysV_ppc and ABISysV_ppc64 plugins. I would say we just fix the remaining plugins by removing the whole requirement to have the register names coming from ConstStrings. I really doubt that we actually save any time with the whole ConstString search trick (searching ~50 strings that have <4 characters doesn't sound more expensive than calling the really expensive ConstString constructor + comparing the same amount of pointer values). Also whatever small percentage of LLDB's runtime is actually spend in this function is anyway not worth the complexity of this approach. This patch just removes all this and just does a normal string comparison. Reviewed By: JDevlieghere, labath Differential Revision: https://reviews.llvm.org/D88490