aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Target/StackFrame.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-09-03[lldb] Mark scripted frames as synthetic instead of artificial (#153117)Med Ismail Bennani1-6/+8
This patch changes the way frames created from scripted affordances like Scripted Threads are displayed. Currently, they're marked artificial which is used usually for compiler generated frames. This patch changes that behaviour by introducing a new synthetic StackFrame kind and moves 'artificial' to be a distinct StackFrame attribut. On top of making these frames less confusing, this allows us to know when a frame was created from a scripted affordance. rdar://155949703 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2025-08-28Stateful variable-location annotations in Disassembler::PrintInstructions() ↵Abdullah Mohammad Amin1-13/+13
(follow-up to #147460) (#152887) **Context** Follow-up to [#147460](https://github.com/llvm/llvm-project/pull/147460), which added the ability to surface register-resident variable locations. This PR moves the annotation logic out of `Instruction::Dump()` and into `Disassembler::PrintInstructions()`, and adds lightweight state tracking so we only print changes at range starts and when variables go out of scope. --- ## What this does While iterating the instructions for a function, we maintain a “live variable map” keyed by `lldb::user_id_t` (the `Variable`’s ID) to remember each variable’s last emitted location string. For each instruction: - **New (or newly visible) variable** → print `name = <location>` once at the start of its DWARF location range, cache it. - **Location changed** (e.g., DWARF range switched to a different register/const) → print the updated mapping. - **Out of scope** (was tracked previously but not found for the current PC) → print `name = <undef>` and drop it. This produces **concise, stateful annotations** that highlight variable lifetime transitions without spamming every line. --- ## Why in `PrintInstructions()`? - Keeps `Instruction` stateless and avoids changing the `Instruction::Dump()` virtual API. - Makes it straightforward to diff state across instructions (`prev → current`) inside the single driver loop. --- ## How it works (high-level) 1. For the current PC, get in-scope variables via `StackFrame::GetInScopeVariableList(/*get_parent=*/true)`. 2. For each `Variable`, query `DWARFExpressionList::GetExpressionEntryAtAddress(func_load_addr, current_pc)` (added in #144238). 3. If the entry exists, call `DumpLocation(..., eDescriptionLevelBrief, abi)` to get a short, ABI-aware location string (e.g., `DW_OP_reg3 RBX → RBX`). 4. Compare against the last emitted location in the live map: - If not present → emit `name = <location>` and record it. - If different → emit updated mapping and record it. 5. After processing current in-scope variables, compute the set difference vs. the previous map and emit `name = <undef>` for any that disappeared. Internally: - We respect file↔load address translation already provided by `DWARFExpressionList`. - We reuse the ABI to map LLVM register numbers to arch register names. --- ## Example output (x86_64, simplified) ``` -> 0x55c6f5f6a140 <+0>: cmpl $0x2, %edi ; argc = RDI, argv = RSI 0x55c6f5f6a143 <+3>: jl 0x55c6f5f6a176 ; <+54> at d_original_example.c:6:3 0x55c6f5f6a145 <+5>: pushq %r15 0x55c6f5f6a147 <+7>: pushq %r14 0x55c6f5f6a149 <+9>: pushq %rbx 0x55c6f5f6a14a <+10>: movq %rsi, %rbx 0x55c6f5f6a14d <+13>: movl %edi, %r14d 0x55c6f5f6a150 <+16>: movl $0x1, %r15d ; argc = R14 0x55c6f5f6a156 <+22>: nopw %cs:(%rax,%rax) ; i = R15, argv = RBX 0x55c6f5f6a160 <+32>: movq (%rbx,%r15,8), %rdi 0x55c6f5f6a164 <+36>: callq 0x55c6f5f6a030 ; symbol stub for: puts 0x55c6f5f6a169 <+41>: incq %r15 0x55c6f5f6a16c <+44>: cmpq %r15, %r14 0x55c6f5f6a16f <+47>: jne 0x55c6f5f6a160 ; <+32> at d_original_example.c:5:10 0x55c6f5f6a171 <+49>: popq %rbx ; i = <undef> 0x55c6f5f6a172 <+50>: popq %r14 ; argv = RSI 0x55c6f5f6a174 <+52>: popq %r15 ; argc = RDI 0x55c6f5f6a176 <+54>: xorl %eax, %eax 0x55c6f5f6a178 <+56>: retq ``` Only transitions are shown: the start of a location, changes, and end-of-lifetime. --- ## Scope & limitations (by design) - Handles **simple locations** first (registers, const-in-register cases surfaced by `DumpLocation`). - **Memory/composite locations** are out of scope for this PR. - Annotations appear **only at range boundaries** (start/change/end) to minimize noise. - Output is **target-independent**; register names come from the target ABI. ## Implementation notes - All annotation printing now happens in `Disassembler::PrintInstructions()`. - Uses `std::unordered_map<lldb::user_id_t, std::string>` as the live map. - No persistent state across calls; the map is rebuilt while walking instruction by instruction. - **No changes** to the `Instruction` interface. --- ## Requested feedback - Placement and wording of the `<undef>` marker. - Whether we should optionally gate this behind a setting (currently always on when disassembling with an `ExecutionContext`). - Preference for immediate inclusion of tests vs. follow-up patch. --- Thanks for reviewing! Happy to adjust behavior/format based on feedback. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>
2025-08-11[lldb] Make StackID call Fix{Code,Data} pointers (#152796)Felipe de Azevedo Piovezan1-6/+10
In architectures where pointers may contain metadata, such as arm64e, it is important to ignore those bits when comparing two different StackIDs, as the metadata may not be the same even if the pointers are. This patch is a step towards allowing consumers of pointers to decide whether they want to keep or remove metadata, as opposed to discarding metadata at the moment pointers are created. See https://github.com/llvm/llvm-project/pull/150537. This was tested running the LLDB test suite on arm64e.
2025-07-01[LLDB] Update DIL to pass current 'frame var' tests. (#145055)cmtice1-0/+1
As a preliminary to making DIL the default implementation for 'frame var', ran check-lldb forcing 'frame var' to always use DIL, and discovered a few failing tests. This fixes most of them. The only remaining failing test is TestDAP_evaluate.py, which now passes a test case that the test says should fail (still investigating this). Changes in this PR: - Sets correct VariableSP, as well as returning ValueObjectSP (needed for several watchpoint tests). - Updates error messages, when looking up members, to match what the rest of LLDB expects. Also update appropriate DIL tests to expect the updated error messages. - Updates DIL parser to look for and accept "(anonymous namespace)::" at the front of a variable name.
2025-06-03[lldb] Fix data race in statusline format handling (#142489)Jonas Devlieghere1-2/+5
This fixes a data race between the main thread and the default event handler thread. The statusline format option value was protected by a mutex, but it was returned as a pointer, allowing one thread to access it while another was modifying it. Avoid the data race by returning format values by value instead of by pointer.
2025-05-23[LLDB] Add field member operators to DIL (#138093)cmtice1-2/+3
Add the arrow and period operators, allowing DIL to find and access member fields.
2025-04-29[LLDB] Add unary operators Dereference and AddressOf to DIL (#134428)Ilia Kuklin1-3/+3
2025-04-29[lldb] Make ValueObject::Dereference less aggressive (#137311)Pavel Labath1-9/+11
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-25[lldb-dap] Show assembly depending on `stop-disassembly-display` settings ↵Ely Ronnen1-6/+5
(#136494) Show assembly code when the source code for a frame is not available in the debugger machine Edit: this functionality will work only when using `stop-disassembly-display = no-source` in the settings Fix #136492 After the fix: [Screencast From 2025-04-20 18-00-30.webm](https://github.com/user-attachments/assets/1ce41715-cf4f-42a1-8f5c-6196b9d685dc)
2025-04-03[LLDB] Add DIL code for handling plain variable names. (#120971)cmtice1-4/+39
Add the Data Inspection Language (DIL) implementation pieces for handling plain local and global variable names. See https://discourse.llvm.org/t/rfc-data-inspection-language/69893 for information about DIL. This change includes the basic AST, Lexer, Parser and Evaluator pieces, as well as some tests.
2025-03-13[lldb] Use Function::GetAddressRange*s* in "frame diagnose" (#130949)Pavel Labath1-10/+6
No test because generating discontinous functions is tedious and there's nothing particularly interesting happening in here. As long as the analyzer stays within a single basic block. it doesn't really care whether the function is discontinous or not. I could create cases where the algorithm breaks when going across basic blocks, but that's more of inherent limitation of the algorithm (the inability to follow jumps "backwards") than something specific to discontinous functions. At this point, I'm more interested in cleaning up the last few remaining uses of the deprecated function that I'm about improving "frame diagnose".
2025-03-05[lldb] Upgrade CompilerType::GetBitSize to return llvm::Expected (#129601)Adrian Prantl1-5/+12
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-25[lldb] Fix TestDiagnoseDereferenceFunctionReturn on linux (#128512)Pavel Labath1-5/+6
The test was failing because it was looking up the immediate value from the call instruction as a load address, whereas in fact it was a file address. This worked on darwin because (with ASLR disabled) the two addresses are generally the same. On linux, this depends on the build mode, but with the default (PIE) build type, the two are never the same. The test also fails on a mac with ASLR enabled. This path fixes the code to look up the value as a file address.
2025-01-10[lldb] Add Function::GetAddress and redirect some uses (#115836)Pavel Labath1-2/+1
Many calls to Function::GetAddressRange() were not interested in the range itself. Instead they wanted to find the address of the function (its entry point) or the base address for relocation of function-scoped entities (technically, the two don't need to be the same, but there's isn't good reason for them not to be). This PR creates a separate function for retrieving this, and changes the existing (non-controversial) uses to call that instead.
2024-12-06[lldb] Fix typos in `StackFrame.cpp` (#118991)Ping Charoenwet1-4/+4
2024-11-20Rename GetLanguageInfo to GetLanguageSpecificData (#117012)Adrian Prantl1-2/+2
Unbeknownst to me the Swift LLDB branch already had an almost identical API with this name, so it makes sense to merge the two.
2024-11-20[lldb] Add an API to derive language-specific runtime information (#116904)Adrian Prantl1-0/+13
This is motivated by exposing some Swift language-specific flags through the API, in the example here it is used to communicate the Objective-C runtime version. This could also be a meaningful extension point to get information about "embedded: languages, such as extracting the C++ version in an Objective-C++ frame or something along those lines.
2024-11-20[lldb] Reword the "line 0" warning (#116827)Pavel Labath1-13/+3
We got a bug report that this message is confusing. In this particular case, the line zero was due to compiler tail merging (in optimized code). The main issue was the "no source code" part: in this case it's kind of incorrect because -- even though we can't really know that -- the address is arguably associated with *multiple* lines of source code. I've tried to make the new wording more neutral, and added a wink towards compiler optimizations. I left out the "compiler generated" part of the message because I couldn't find a way to squeeze that in nicely. I'm also not entirely sure what it was referring to -- if this was (just) function prologue/epilogue, then maybe leaving it out is fine, as we're not likely to stop there anyway (?) I also left out the function name, because: - for template functions it gets rather long - it's already present in the message, potentially twice (once in the "frame summary" line and once in the snippet of code we show for the function declaration) --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
2024-11-14[lldb/Target] Add null-check before dereferencing inlined_info (NFC) (#116300)Med Ismail Bennani1-2/+4
This patch is a follow-up to 9c7701fa78037af03be10ed168fd3c75a2ed1aef and adds extra-null checks before dereferencing the inlined_info pointer. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2024-11-14[lldb/API] Hoist some of SBFrame logic to lldb_private::StackFrame (NFC) ↵Med Ismail Bennani1-0/+51
(#116298) This patch moves some of the logic implemented in the SBFrame APIs to the lldb_private::StackFrame class so it can be re-used elsewhere. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2024-11-14[LLDB] Add framework for Data Inspection Language (DIL) work. (#115666)cmtice1-0/+23
Add the framework code for hooking up and calling the Data Inspection Language (DIL) implementation, as an alternate implementation for the 'frame variable' command. For now, this is an opt-in option, via a target setting 'target.experimental.use-DIL'. See https://discourse.llvm.org/t/rfc-data-inspection-language/69893 for more information about this project. This PR does not actually call any of the DIL code; instead the piece that will eventually call the DIL code (StackFrame::DILEvaluateVariableExpression) calls back into the original 'frame variable' implementation.
2024-11-13[lldb] Fix source display for artificial locations (#115876)Pavel Labath1-3/+3
When retrieving the location of the function declaration, we were dropping the file component on the floor, which resulted in an amusingly confusing situation were we displayed the file containing the implementation of the function, but used the line number of the declaration. This patch fixes that. It required a small refactor Function::GetStartLineSourceLineInfo to return a SupportFile (instead of just the file spec), which in turn necessitated changes in a couple of other places as well.
2024-11-11[lldb] Support overriding the disassembly CPU & features (#115382)Jonas Devlieghere1-6/+11
Add the ability to override the disassembly CPU and CPU features through a target setting (`target.disassembly-cpu` and `target.disassembly-features`) and a `disassemble` command option (`--cpu` and `--features`). This is especially relevant for architectures like RISC-V which relies heavily on CPU extensions. The majority of this patch is plumbing the options through. I recommend looking at DisassemblerLLVMC and the test for the observable change in behavior.
2024-10-24[lldb] Move ValueObject into its own library (NFC) (#113393)Jonas Devlieghere1-3/+3
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-10-10[lldb] Return an llvm::Error from GetFrameBaseValue (#111882)Jonas Devlieghere1-7/+6
This fixes the following assertion: "Cannot create Expected<T> from Error success value." The problem was that GetFrameBaseValue return false without updating the Status argument. This patch eliminates the opportunity for mistakes by returning an llvm:Error.
2024-09-05[lldb] Make deep copies of Status explicit (NFC) (#107170)Adrian Prantl1-1/+1
2024-09-05[lldb] Make conversions from llvm::Error explicit with Status::FromEr… ↵Adrian Prantl1-1/+1
(#107163) …ror() [NFC]
2024-08-30[lldb] Deal with SupportFiles in SourceManager (NFC) (#106740)Jonas Devlieghere1-1/+1
To support detecting MD5 checksum mismatches, deal with SupportFiles rather than a plain FileSpecs in the SourceManager.
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl1-40/+44
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.
2024-08-23Revert "Revert "[lldb] Extend frame recognizers to hide frames from ↵Adrian Prantl1-8/+18
backtraces (#104523)"" This reverts commit 547917aebd1e79a8929b53f0ddf3b5185ee4df74.
2024-08-22Revert "[lldb] Extend frame recognizers to hide frames from backtraces ↵Dmitri Gribenko1-18/+8
(#104523)" This reverts commit f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9. This commit introduces an msan violation. See the discussion on https://github.com/llvm/llvm-project/pull/104523.
2024-08-20[lldb] Extend frame recognizers to hide frames from backtraces (#104523)Adrian Prantl1-8/+18
Compilers and language runtimes often use helper functions that are fundamentally uninteresting when debugging anything but the compiler/runtime itself. This patch introduces a user-extensible mechanism that allows for these frames to be hidden from backtraces and automatically skipped over when navigating the stack with `up` and `down`. This does not affect the numbering of frames, so `f <N>` will still provide access to the hidden frames. The `bt` output will also print a hint that frames have been hidden. My primary motivation for this feature is to hide thunks in the Swift programming language, but I'm including an example recognizer for `std::function::operator()` that I wished for myself many times while debugging LLDB. rdar://126629381 Example output. (Yes, my proof-of-concept recognizer could hide even more frames if we had a method that returned the function name without the return type or I used something that isn't based off regex, but it's really only meant as an example). before: ``` (lldb) thread backtrace --filtered=false * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25 frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12 frame #3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12 frame #4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10 frame #5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12 frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10 frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10 frame #8: 0x0000000183cdf154 dyld`start + 2476 (lldb) ``` after ``` (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25 frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12 frame #6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10 frame #7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10 frame #8: 0x0000000183cdf154 dyld`start + 2476 Note: Some frames were hidden by frame recognizers ```
2024-06-05[lldb] Return an llvm::Expected from DWARFExpression::Evaluate (NFCI) (#94420)Jonas Devlieghere1-12/+7
Change the signature of `DWARFExpression::Evaluate` and `DWARFExpressionList::Evaluate` to return an `llvm::Expected` instead of a boolean. This eliminates the `Status` output parameter and generally improves error handling.
2024-04-29Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)Adrian Prantl1-13/+10
that separates out language and version. To avoid reinventing the wheel and introducing subtle incompatibilities, this API uses the table of languages and versiond defined by the upcoming DWARF 6 standard (https://dwarfstd.org/languages-v6.html). While the DWARF 6 spec is not finialized, the list of languages is broadly considered stable. The primary motivation for this is to allow the Swift language plugin to switch between language dialects between, e.g., Swift 5.9 and 6.0 with out introducing a ton of new language codes. On the main branch this change is considered NFC. Depends on https://github.com/llvm/llvm-project/pull/89980
2024-03-27[lldb][nfc] Delete unused variable (#86740)Felipe de Azevedo Piovezan1-1/+0
This was made unused by d9ec4b24a84addb8bd77b5d9dd990181351cf84c.
2024-03-21[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)Jonas Devlieghere1-1/+1
This is another step towards supporting DWARF5 checksums and inline source code in LLDB. This is a reland of #85468 but without the functional change of storing the support file from the line table (yet).
2024-03-19Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)Jonas Devlieghere1-1/+1
Reverts llvm/llvm-project#85468 because @slackito reports this broke stepping in one of their tests [1] and this patch was meant to be NFC. [1] https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120
2024-03-15[lldb] Store SupportFile in FileEntry (NFC) (#85468)Jonas Devlieghere1-1/+1
This is another step towards supporting DWARF5 checksums and inline source code in LLDB.
2024-03-08Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected ↵Adrian Prantl1-9/+10
(#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 Mayer1-10/+9
llvm::Expected (#84219)" This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.
2024-03-08Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected ↵Adrian Prantl1-9/+10
(#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.
2023-12-12[lldb] Correctly check and report error states in StackFrame.cpp (#74414)Pete Lawrence1-12/+10
This commits fixes a few subtle bugs where the method: 1. Declares a local `Status error` which eclipses the method's parameter `Status &error`. - The method then sets the error state to the local `error` and returns without ever touching the parameter `&error`. - This effectively traps the error state and its message from ever reaching the caller. - I also threw in a null pointer check in case the callee doesn't set its `Status` parameter but returns `0`/`nullptr`. 2. Declares a local `Status deref_error` (good), passes it to the `Dereference` method (also good), but then checks the status of the method's `Status &error` parameter (not good). - The fix checks `deref_error` instead and also checks for a `nullptr` return value. - There's a good opportunity here for a future PR that changes the `Dereference` method to fold an error state into the `ValueObject` return value's `m_error` instead of using a parameter. 3. Declares another local `Status error`, which it doesn't pass to a method (because there isn't a parameter for it), and then checks for an error condition that never happens. - The fix just checks the callee's return value, because that's all it has to go on. - This likely comes from a copy/paste from issue 1 above. rdar://119155810
2023-11-13[lldb-dap] Add an option to provide a format for stack frames (#71843)Walter Erquinigo1-8/+17
When this option gets enabled, descriptions of stack frames will be generated using the format provided in the launch configuration instead of simply calling `SBFrame::GetDisplayFunctionName`. This allows lldb-dap to show an output similar to the one in the CLI.
2023-07-05[lldb] Fix incorrect uses of LLDB_LOG_ERRORJonas Devlieghere1-1/+1
Fix incorrect uses of LLDB_LOG_ERROR. The macro doesn't automatically inject the error in the log message: it merely passes the error as the first argument to formatv and therefore must be referenced with {0}. Thanks to Nicholas Allegra for collecting a list of places where the macro was misused. rdar://111581655 Differential revision: https://reviews.llvm.org/D154530
2023-06-13[lldb] Default can_create to true in GetChildAtIndex (NFC)Dave Lee1-7/+6
Existing callers of `GetChildAtIndex` pass true for can_create. This change makes true the default value, callers don't have to pass an opaque true. See also D151966 for the same change to `GetChildMemberWithName`. Differential Revision: https://reviews.llvm.org/D152031
2023-06-13[lldb] Default can_create to true in GetChildMemberWithName (NFC)Dave Lee1-3/+3
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`. This change makes `true` the default value, callers don't have to pass an opaque true. Differential Revision: https://reviews.llvm.org/D151966
2023-05-22[lldb][NFCI] Change return type of Language::GetInstanceVariableNameAlex Langford1-2/+3
I don't think this needs to be a ConstString. Differential Revision: https://reviews.llvm.org/D150709
2023-03-08[lldb] Let 'v' command directly access ivars of _any_ self/thisDave Lee1-17/+14
The `v` (`frame variable`) command can directly access ivars/fields of `this` or `self`. Such as `v field`, instead of `v this->field`. This change relaxes the criteria for finding `this`/`self` variables. There are cases where a `this`/`self` variable does exist, but up to now the `v` command has not made use of it. The user would have to explicitly run `v this->field` or `self->_ivar` to access ivars. This change allows such cases to also work (without explicitly dereferencing `this`/`self`). A very common example in Objective-C (and Swift) is weakly capturing `self`: ``` __weak Type *weakSelf = self; void (^block)(void) = ^{ Type *self = weakSelf; // Re-establish strong reference. // `v _ivar` should work just as well as `v self->_ivar`. }; ``` In this case, `self` exists but `v` would not have used it. With this change, the fact that a variable named `self` exists is enough for it to be used. Differential Revision: https://reviews.llvm.org/D145276
2023-03-04[lldb] Remove unused portion of GetFunctionMethodInfo signature (NFC)Dave Lee1-5/+2
This applies to IsClassMethod as well.
2022-12-05[lldb] Make sure the value of `eSymbolContextVariable` is not conflicting ↵Argyrios Kyrtzidis1-1/+1
with `RESOLVED_FRAME_CODE_ADDR` Differential Revision: https://reviews.llvm.org/D139066