summaryrefslogtreecommitdiff
path: root/lldb/source/ValueObject/ValueObject.cpp
AgeCommit message (Collapse)Author
2025-06-02[lldb] Refactor away UB in SBValue::GetLoadAddress (#141799)Pavel Labath
The problem was in calling GetLoadAddress on a value in the error state, where `ValueObject::GetLoadAddress` could end up accessing the uninitialized "address type" by-ref return value from `GetAddressOf`. This probably happened because each function expected the other to initialize it. We can guarantee initialization by turning this into a proper return value. I've added a test, but it only (reliably) crashes if lldb is built with ubsan.
2025-05-29[LLDB] [NFC] - Remove duplicate #include headers from the files of lldb dir ↵Akash Agrawal
& few other files (#141478) A few files of lldb dir & few other files had duplicate headers included. This patch removes those redundancies. --------- Co-authored-by: Akash Agrawal <akashag@qti.qualcomm.com>
2025-05-20[lldb][core] Fix getting summary of a variable pointing to r/o memory (#139196)Igor Kudrin
Motivation example: ``` > lldb -c altmain2.core ... (lldb) var F (const char *) F = 0x0804a000 "" ``` The variable `F` points to a read-only memory page not dumped to the core file, so `Process::ReadMemory()` cannot read the data. The patch switches to `Target::ReadMemory()`, which can read data both from the process memory and the application binary.
2025-05-12[lldb] Restore ObjC incomplete type dereferencing fix (#139567)Ilia Kuklin
Attempt an ObjC incomplete type fix even if `GetDereferencedType` returns an error.
2025-05-12[lldb][TypeSystemClang] Allow arrays to be dereferenced in C/C++. (#135843)Ilia Kuklin
Add a function `GetDereferencedType` to `CompilerType` and allow `TypeSystemClang` to dereference arrays.
2025-05-05[LLDB] Fix `ValueObject::AddressOf()` return value (#137688)Ilia Kuklin
`ValueObject::AddressOf()` used to return address as a value which has it's own address, allowing to do `value.AddressOf().AddressOf()`. This patch makes the return address a simple const value.
2025-04-30[lldb] Upgrade `GetIndexOfChildWithName` to use `llvm::Expected` (#136693)Charles Zablit
This patch replaces the use of `UINT32_MAX` as the error return value of `GetIndexOfChildWithName` with `llvm::Expected`. # Tasks to do in another PR 1. Replace `CalculateNumChildrenIgnoringErrors` with `CalculateNumChildren`. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358). 2. Update `lldb_private::formatters::ExtractIndexFromString` to use `llvm::Expected`. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536). 3. Create a new class which carries both user and internal errors. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608).
2025-04-29[lldb] Make ValueObject::Dereference less aggressive (#137311)Pavel Labath
The function was always trying to dereference both the synthetic and non-synthetic view of the object. This is wrong as the caller should be able to determine which view of the object it wants to access, as is done e.g. for child member access. This patch removes the nonsynthetic->synthetic fallback, which is the more surprising path, and fixes the callers to try both versions of the object (when appropriate). I also snuck in simplification of the member access code path because it was possible to use the same helper function for that, and I wanted to be sure I understand the logic correctly. I've left the synthetic->nonsynthetic fallback in place. I think we may want to keep that one as we often have synthetic child providers for pointer types. They usually don't provide an explicit dereference operation but I think users would expect that a dereference operation on those objects would work. What we may want to do is to try the *synthetic* operation first in this case, so that the nonsynthetic case is really a fallback. --------- Co-authored-by: Ilia Kuklin <kuklin.iy@mail.ru>
2025-04-16[lldb][DataFormatter] Surface CalculateNumChildren errors in std::vector ↵Michael Buch
summary (#135944) When the data-formatters happen to break (e.g., due to layout changes in libc++), there's no clear indicator of them failing from a user's perspective. E.g., for `std::vector`s we would just show: ``` (std::vector<int>) v = size=0 {} ``` which is highly misleading, especially if `v.size()` returns a non-zero size. This patch surfaces the various errors that could occur when calculating the number of children of a vector. rdar://146964266
2025-03-05[lldb] Upgrade CompilerType::GetBitSize to return llvm::Expected (#129601)Adrian Prantl
This patch pushes the error handling boundary for the GetBitSize() methods from Runtime into the Type and CompilerType APIs. This makes it easier to diagnose problems thanks to more meaningful error messages being available. GetBitSize() is often the first thing LLDB asks about a type, so this method is particularly important for a better user experience. rdar://145667239
2025-02-07[lldb][NFC] Replace GetLocalBufferSize() with GetLocalBuffer() (#126333)Augusto Noronha
2025-02-06[lldb] Make ValueObjectDynamicValue::UpdateValue() point to a host b… ↵Augusto Noronha
(#125143) …uffer ValueObjectDynamicValue::UpdateValue() assumes that the dynamic type found by GetDynamicTypeAndAddress() would return an address in the inferior. This commit makes it so it can deal with being passed a host address instead. This is needed downstream by the Swift fork. rdar://143357274
2024-12-04[LLDB] Fix error returns in CastToBasicType and CastToEnumType in ↵cmtice
ValueObject. (#117401) Update the error returns in ValueObject::CastToBasicType and ValueObject::CastToEnumType to create new errors and return a ValueObjectConstResult with the error, rather tnan updating the error in (and returning) the input ValueObject.
2024-11-12[lldb] Support true/false in ValueObject::SetValueFromCString (#115780)Jonas Devlieghere
Support "true" and "false" (and "YES" and "NO" in Objective-C) in ValueObject::SetValueFromCString. Fixes #112597
2024-11-05Revert "Fix pointer to reference type (#113596)" (#114831)Pavel Labath
This reverts commit 25909b811a7ddc983d042b15cb54ec271a673d63 due to unresolved questions about the behavior of "frame var" and ValueObject in the presence of references (see the original patch for discussion).
2024-10-24[lldb] Move ValueObject into its own library (NFC) (#113393)Jonas Devlieghere
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%" '{}' \; ```