summaryrefslogtreecommitdiff
path: root/lldb/source/DataFormatters
AgeCommit message (Collapse)Author
2025-08-15[lldb] Print ValueObject when GetObjectDescription fails (#152417)Dave Lee
This fixes a few bugs, effectively through a fallback to `p` when `po` fails. The motivating bug this fixes is when an error within the compiler causes `po` to fail. Previously when that happened, only its value (typically an object's address) was printed – and problematically, no compiler diagnostics were shown. With this change, compiler diagnostics are shown, _and_ the object is fully printed (ie `p`). Another bug this fixes is when `po` is used on a type that doesn't provide an object description (such as a struct). Again, the normal `ValueObject` printing is used. Additionally, this also improves how lldb handles an object description method that fails in some way. Now an error will be shown (it wasn't before), and the value will be printed normally.
2025-07-31[lldb] Add support for displaying `__float128` variables (#98369)beetrees
2025-07-25[lldb] Use std::make_shared where possible (NFC) (#150714)Jonas Devlieghere
This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction).
2025-07-18[lldb] Correct spacing of = {...} when depth limit is hit (#149480)David Spickett
In some places it was printing "= {...}" and some "={...}" with no space. I think the space looks nicer so do that in both cases.
2025-07-07[lldb][Formatters] Use container summary helper for libstdc++ formatters ↵Michael Buch
(#147140) This re-uses the `LibcxxContainerSummaryProvider` for the libstdc++ formatters. There's a couple of containers that aren't making use of it for libstdc++. This patch will make it easier to review when adding those in the future.
2025-07-04[lldb][DataFormatter] Format libstdc++ unique_ptr like we do libc++ (#146909)Michael Buch
The only difference is that with libc++ the summary string contains the derefernced pointer value. With libstdc++ we currently display the pointer itself, which seems redundant. E.g., ``` (std::unique_ptr<int>) iup = 0x55555556d2b0 { pointer = 0x000055555556d2b0 } (std::unique_ptr<std::basic_string<char> >) sup = 0x55555556d2d0 { pointer = "foobar" } ``` This patch moves the logic into a common helper that's shared between the libc++ and libstdc++ formatters. After this patch we can combine the libc++ and libstdc++ API tests (see https://github.com/llvm/llvm-project/pull/146740).
2025-06-11[lldb] Show coro_frame in `std::coroutine_handle` pretty printer (#141516)Adrian Vogelsgesang
This commit adjusts the pretty printer for `std::coroutine_handle` based on recent personal experiences with debugging C++20 coroutines: 1. It adds the `coro_frame` member. This member exposes the complete coroutine frame contents, including the suspension point id and all internal variables which the compiler decided to persist into the coroutine frame. While this data is highly compiler-specific, inspecting it can help identify the internal state of suspended coroutines. 2. It includes the `promise` and `coro_frame` members, even if devirtualization failed and we could not infer the promise type / the coro_frame type. Having them available as `void*` pointers can still be useful to identify, e.g., which two coroutine handles have the same frame / promise pointers.
2025-06-10[lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S (#142587)Pavel Labath
Replace (questionable) header globs with an explicit argument supported by llvm_add_library.
2025-06-04[lldb/cmake] Implicitly pass arguments to llvm_add_library (#142583)Pavel Labath
If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources).
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-28[lldb][Formatters] Add --pointer-match-depth option to `type summary add` ↵Zequan Wu
command. (#138209) Currently, the type `T`'s summary formatter will be matched for `T`, `T*`, `T**` and so on. This is unexpected in many data formatters. Such unhandled cases could cause the data formatter to crash. An example would be the lldb's built-in data formatter for `std::optional`: ``` $ cat main.cpp #include <optional> int main() { std::optional<int> o_null; auto po_null = &o_null; auto ppo_null = &po_null; auto pppo_null = &ppo_null; return 0; } $ clang++ -g main.cpp && lldb -o "b 8" -o "r" -o "v pppo_null" [lldb crash] ``` This change adds an options `--pointer-match-depth` to `type summary add` command to allow users to specify how many layer of pointers can be dereferenced at most when matching a summary formatter of type `T`, as Jim suggested [here](https://github.com/llvm/llvm-project/pull/124048/#issuecomment-2611164133). By default, this option has value 1 which means summary formatter for `T` could also be used for `T*` but not `T**` nor beyond. This option is no-op when `--skip-pointers` is set as well. I didn't add such option for `type synthetic add`, `type format add`, `type filter add`, because it useful for those command. Instead, they all have the pointer match depth of 1. When printing a type `T*`, lldb never print the children of `T` even if there is a synthetic formatter registered for `T`.
2025-05-25[lldb] Use llvm::find_if (NFC) (#141385)Kazu Hirata
2025-05-08[lldb][DataFormatters] Change ExtractIndexFromString to return std::optional ↵Charles Zablit
(#138297) This PR is in continuation of https://github.com/llvm/llvm-project/pull/136693.
2025-05-04[lldb] Remove unused local variables (NFC) (#138457)Kazu Hirata
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-03-15[lldb] Update dwim-print to show expanded objc instances (#117500)Dave Lee
When printing an ObjC object, which is a pointer, lldb has handled it the same way it treats any other pointer – printing only class name and pointer address. The object is not expanded, its children are not shown. This change updates `dwim-print` to print objc pointers by expanding (ie dereferencing), with the assumption that it's what the user wants. Note that this is currently possible using the `--ptr-depth`/`-P` flag. With this change, when `dwim-print` prints root level objc objects, it's the same effect as using `--ptr-depth 1`.
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-21[lldb] Fix GCC's `-Wreturn-type` warnings (#127974)foxtran
This patch fixes `-Wreturn-type` warnings which happens if LLVM is built with GCC compiler (14.1 is used for detecting) Warnings: ``` llvm-project/lldb/source/ValueObject/DILLexer.cpp: In static member function ‘static llvm::StringRef lldb_private::dil::Token::GetTokenName(Kind)’: llvm-project/lldb/source/ValueObject/DILLexer.cpp:33:1: warning: control reaches end of non-void function [-Wreturn-type] 33 | } | ^ ``` and: ``` llvm-project/lldb/source/DataFormatters/TypeSummary.cpp: In member function ‘virtual std::string lldb_private::TypeSummaryImpl::GetSummaryKindName()’: llvm-project/lldb/source/DataFormatters/TypeSummary.cpp:62:1: warning: control reaches end of non-void function [-Wreturn-type] 62 | } | ^ ``` Technically, it is a bug in Clang (see #115345), however, UBSan with Clang should detect these places, therefore it would be nice to provide a return statement for all possible inputs (even invalid).
2025-02-17[lldb] Provide default impl for MightHaveChildren (NFC) (#119977)Dave Lee
The vast majority of `SyntheticChildrenFrontEnd` subclasses provide children, and as such implement `MightHaveChildren` with a constant value of `true`. This change makes `true` the default value. With this change, `MightHaveChildren` only needs to be implemented by synthetic providers that can return `false`, which is only 3 subclasses.
2025-01-14[lldb][NFC] Make the target's SectionLoadList private. (#113278)Greg Clayton
Lots of code around LLDB was directly accessing the target's section load list. This NFC patch makes the section load list private so the Target class can access it, but everyone else now uses accessor functions. This allows us to control the resolving of addresses and will allow for functionality in LLDB which can lazily resolve addresses in JIT plug-ins with a future patch.
2025-01-03[lldb] Add a return opcode to the formatter bytecode (#121602)Adrian Prantl
In LLVM we love our early exists and this opcode allows for simpler code generation.
2024-12-13[lldb] Support zero-padding in formatter sections (#119934)Adrian Prantl
2024-12-11[lldb] Disallow left shifts of negative values in the interpreter (#119620)Adrian Prantl
This trips UBSAN and probably isn't partiuclarly useful either.
2024-12-10[lldb] Eliminate dead code (NFC)Adrian Prantl
2024-12-10[lldb] Add explicit type conversionAdrian Prantl
2024-12-10Reland: [lldb] Implement a formatter bytecode interpreter in C++Adrian Prantl
Compared to the python version, this also does type checking and error handling, so it's slightly longer, however, it's still comfortably under 500 lines. Relanding with more explicit type conversions.
2024-12-11Revert "[lldb] Add cast to fix compile error on 32-bit platforms"Sylvestre Ledru
This reverts commit f6012a209dca6b1866d00e6b4f96279469884320. Revert "[lldb] Add cast to fix compile error on 32-but platforms" This reverts commit d300337e93da4ed96b044557e4b0a30001967cf0. Revert "[lldb] Improve log message to include missing strings" This reverts commit 0be33484853557bc0fd9dfb94e0b6c15dda136ce. Revert "[lldb] Add comment" This reverts commit e2bb47443d2e5c022c7851dd6029e3869fc8835c. Revert "[lldb] Implement a formatter bytecode interpreter in C++" This reverts commit 9a9c1d4a6155a96ce9be494cec7e25731d36b33e.
2024-12-10[lldb] Add cast to fix compile error on 32-bit platformsAdrian Prantl
2024-12-10[lldb] Add cast to fix compile error on 32-but platformsAdrian Prantl
2024-12-10[lldb] Improve log message to include missing stringsAdrian Prantl
2024-12-10[lldb] Implement a formatter bytecode interpreter in C++Adrian Prantl
Compared to the python version, this also does type checking and error handling, so it's slightly longer, however, it's still comfortably under 500 lines.
2024-12-02[lldb] Simplify DumpValueObjectOptions::PointerDepth (NFC) (#117504)Dave Lee
`Mode::Always` and `Mode::Default` are handled identically. `Mode::Never` is the same as having a count of 0.
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%" '{}' \; ```
2024-09-10[LLDB][Data Formatters] Calculate average and total time for summary ↵Jacob Lalonde
providers within lldb (#102708) This PR adds a statistics provider cache, which allows an individual target to keep a rolling tally of it's total time and number of invocations for a given summary provider. This information is then available in statistics dump to help slow summary providers, and gleam more into insight into LLDB's time use.
2024-09-05[lldb] Make conversions from llvm::Error explicit with Status::FromEr… ↵Adrian Prantl
(#107163) …ror() [NFC]
2024-06-20Refactor GetObjectDescription() to return llvm::Expected (NFC)Adrian Prantl
This is de facto an NFC change for Objective-C but will benefit the Swift language plugin.
2024-06-20Convert ValueObject::Dump() to return llvm::Error() (NFCish)Adrian Prantl
This change by itself has no measurable effect on the LLDB testsuite. I'm making it in preparation for threading through more errors in the Swift language plugin.
2024-06-03[lldb] Avoid (unlimited) GetNumChildren calls when printing values (#93946)Pavel Labath
For some data formatters, even getting the number of children can be an expensive operations (e.g., needing to walk a linked list to determine the number of elements). This is then wasted work when we know we will be printing only small number of them. This patch replaces the calls to GetNumChildren (at least those on the "frame var" path) with the calls to the capped version, passing the value of `max-children-count` setting (plus one)
2024-05-31[lldb] FormatManager::GetPossibleMatches assumes all ValueObjects have ↵jimingham
targets. (#93880) But one made in a situation where that's impossible might only have an error, and no symbol context, so that's not necessarily true. Check for the target's validity before using it. Fixes issue #93313
2024-04-12[lldb] fix dead lock in TypeCategoryMap.cpp (#87540)Vincent Belliard
FormatManager::GetCategoryForLanguage and FormatManager::GetCategory(can_create = true) can be called concurrently and they both take the TypeCategory::m_map_mutex and the FormatManager::m_language_categories_mutex but in reverse order. On one thread, GetCategoryForLanguage takes m_language_categories_mutex and then ends calling TypeCategoryMap::Get which takes m_map_mutex On another thread GetCategory calls TypeCategoryMap::Add which takes m_map_mutex and then calls FormatManager::Changed() which takes m_language_categories_mutex If both threads are running concurrently, we have a dead lock. The patch releases the m_map_mutex before calling Changed which avoids the dead lock. --------- Co-authored-by: Vincent Belliard <v-bulle@github.com>
2024-03-11Report back errors in GetNumChildren() (#84265)Adrian Prantl
This is a proof-of-concept patch that illustrates how to use the Expected return values to surface rich error messages all the way up to the ValueObjectPrinter. This is the final patch in the series that includes https://github.com/llvm/llvm-project/pull/83501 and https://github.com/llvm/llvm-project/pull/84219
2024-03-08Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected ↵Adrian Prantl
(#84219) Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected This is an NFC change that does not yet add any error handling or change any code to return any errors. This is the second big change in the patch series started with https://github.com/llvm/llvm-project/pull/83501 A follow-up PR will wire up error handling.
2024-03-08Revert "Change GetNumChildren()/CalculateNumChildren() methods return ↵Florian Mayer
llvm::Expected (#84219)" This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.
2024-03-08Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected ↵Adrian Prantl
(#84219) Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected This is an NFC change that does not yet add any error handling or change any code to return any errors. This is the second big change in the patch series started with https://github.com/llvm/llvm-project/pull/83501 A follow-up PR will wire up error handling.
2024-03-07Change GetChildAtIndex to take a uint32_tAdrian Prantl
2024-03-07Change the return type of SyntheticFrontend::CalculateNumChildren to int32_tAdrian Prantl
This way it is consistent with ValueObject and TypeSystem.
2024-02-12Make ValueObjectPrinter's handling of its ValueObject pointers more ↵jimingham
principled (NFC) (#81314) I get a small but fairly steady stream of crash reports which I can only explain by ValueObjectPrinter trying to access its m_valobj field, and finding it NULL. I have never been able to reproduce any of these, and the reports show a state too long after the fact to know what went wrong. I've read through this section of lldb a bunch of times trying to figure out how this could happen, but haven't ever found anything actually wrong that could cause this. OTOH, ValueObjectPrinter is somewhat sloppy about how it handles the ValueObject it is printing. a) lldb allows you to make a ValueObjectPrinter with a Null incoming ValueObject. However, there's no affordance to set the ValueObject in the Printer after the fact, and it doesn't really make sense to do that. So I change the ValueObjectPrinter API's to take a ValueObject reference, rather than a pointer. All the places that make ValueObjectPrinters already check the non-null status of their ValueObject's before making the ValueObjectPrinter, so sadly, I didn't find the bug, but this will enforce the intent. b) The next step in printing the ValueObject is deciding which of the associated DynamicValue/SyntheticValue we are actually printing (based on the use_dynamic and use_synthetic settings in the original ValueObject. This was put in a pointer by GetMostSpecializedValue, but most of the printer code just accessed the pointer, and it was hard to reason out whether we were guaranteed to always call this before using m_valobj. So far as I could see we always do (sigh, didn't find the bug there either) but this was way too hard to reason about. In fact, we figure out once which ValueObject we're going to print and don't change that through the life of the printer. So I changed this to both set the "most specialized value" in the constructor, and then to always access it through GetMostSpecializedValue(). That makes it easier to reason about the use of this ValueObject as well. This is an NFC change, all it does is make the code easier to reason about.
2024-02-08[lldb] Refactor GetFormatFromCString to always check for partial matches ↵Dave Lee
(NFC) (#81018) Refactors logic in `ParseInternal` that was previously calling `GetFormatFromCString` twice, once with `partial_match_ok` set to false, and the second time set to true. With this change, lldb formats (ie `%@`, `%S`, etc) are checked first. If a format is not one of those, then `GetFormatFromCString` is called once, and now always checks for partial matches.
2024-02-08[lldb][TypeSynthetic][NFC] Make SyntheticChildrenFrontend::Update() return ↵Michael Buch
an enum (#80167) This patch changes the return value of `SyntheticChildrenFrontend::Update` to a scoped enum that aims to describe what the return value means.
2024-02-04[lldb] Remove unnecessary FormatCache::GetEntry (NFC) (#80603)Dave Lee
The implementation of `FormatCache::Entry &FormatCache::GetEntry(ConstString)` is effectively a duplication of `std::map::operator[]`. This change deletes `GetEntry` and replaces its use with `operator[]`.