aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Commands/CommandObjectThread.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-09-04[lldb] Correct style of error messages (#156774)Jonas Devlieghere1-1/+1
The LLVM Style Guide says the following about error and warning messages [1]: > [T]o match error message styles commonly produced by other tools, > start the first sentence with a lowercase letter, and finish the last > sentence without a period, if it would end in one otherwise. I often provide this feedback during code review, but we still have a bunch of places where we have inconsistent error message, which bothers me as a user. This PR identifies a handful of those places and updates the messages to be consistent. [1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
2025-05-28[Support] [lldb] Fix thread jump #45326 (#135778)Ebuka Ezike1-1/+4
Fixes #45326 When you thread jump by calling `j +2` or `thread jump --by +2` the offset is not recognised. This commit fixes that. --------- Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
2025-02-28[lldb] Add ability to inspect backing threads with `thread info` (#129275)Felipe de Azevedo Piovezan1-0/+8
When OS plugins are present, it can be helpful to query information about the backing thread behind an OS thread, if it exists. There is no mechanism to do so prior to this commit. As a first step, this commit enhances `thread info` with a `--backing-thread` flag, causing the command to use the backing thread of the selected thread, if it exists.
2025-02-21[lldb] Fix "in function" detection in "thread until" (#123622)Pavel Labath1-38/+30
The implementation has an optimization which detects the range of line table entries covered by the function and then only searches for a matching line between them. This optimization was interfering with the logic for detecting whether a line belongs to the function because the first call to FindLineEntry was made with exact=false, which meant that if the function did not contain any exact matches, we would just pick the closest line number in that range, even if it was very far away. This patch fixes that by first attempting an inexact search across the entire line table, and then use the (potentially inexact) result of that for searching within the function. This makes the optimization a less effective, but I don't think we can differentiate between a line that belongs to the function (but doesn't have any code) and a line outside the function without that. The patch also avoids the use of (deprecated) Function::GetAddressRange by iterating over the GetAddressRanges result to find the full range of line entries for the function.
2024-10-24[lldb] Move ValueObject into its own library (NFC) (#113393)Jonas Devlieghere1-1/+1
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-08[lldb] Change SymbolContext::GetAddressRangeFromHereToEndLine to return ↵AbdAlRahman Gad1-5/+5
Expected (NFC) (#110718) Signed-off-by: AbdAlRahman Gad <abdobngad@gmail.com> Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>
2024-10-02[lldb] Unify implementation of CommandReturnObject::SetError(NFC) (#110707)Adrian Prantl1-3/+3
This is a cleanup that moves the API towards value semantics.
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl1-21/+25
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-4/+15
backtraces (#104523)"" This reverts commit 547917aebd1e79a8929b53f0ddf3b5185ee4df74.
2024-08-22Revert "[lldb] Extend frame recognizers to hide frames from backtraces ↵Dmitri Gribenko1-15/+4
(#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-4/+15
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-08-05[lldb] Delete StepScope enum whose values are ignored. (#101981)sedymrak1-13/+8
StepScope enum is a type whose values are passed around, but they are ultimately ignored. --------- Co-authored-by: Matej Košík <matej.kosik@codasip.com>
2024-07-31[lldb] Unify the way we get the Target in CommandObject (#101208)Jonas Devlieghere1-1/+1
Currently, CommandObjects are obtaining a target in a variety of ways. Often the command incorrectly operates on the selected target. As an example, when a breakpoint command is running, the current target is passed into the command but the target that hit the breakpoint is not the selected target. In other places we use the CommandObject's execution context, which is frozen during the execution of the command, and comes with its own limitations. Finally, we often want to fall back to the dummy target if no real target is available. Instead of having to guess how to get the target, this patch introduces one helper function in CommandObject to get the most relevant target. In order of priority, that's the target from the command object's execution context, from the interpreter's execution context, the selected target or the dummy target. rdar://110846511
2024-07-03Add the ability for Script based commands to specify their "repeat command" ↵jimingham1-1/+1
(#94823) Among other things, returning an empty string as the repeat command disables auto-repeat, which can be useful for state-changing commands. There's one remaining refinement to this setup, which is that for parsed script commands, it should be possible to change an option value, or add a new option value that wasn't originally specified, then ask lldb "make this back into a command string". That would make doing fancy things with repeat commands easier. That capability isn't present in the lldb_private side either, however. So that's for a next iteration. I haven't added this to the docs on adding commands yet. I wanted to make sure this was an acceptable approach before I spend the time to do that.
2024-06-20Convert ValueObject::Dump() to return llvm::Error() (NFCish)Adrian Prantl1-4/+10
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-11[lldb] Fix declaration of thread argument in ↵Dave Lee1-1/+1
CommandObjectThreadStepWithTypeAndScope (#95146) `thread step-in` (and other step commands) take a `<thread-index>`, not a `<thread-id>`.
2024-05-21[lldb] Add the word "backtrace" to bt help string (#92618)Dave Lee1-2/+2
We noticed that `apropos backtrace` did not return the `bt` alias. This change adds the word "backtrace" to the help for `bt`. It also updates `thread backtrace` to keep the language used roughly in sync.
2024-05-16[lldb] Use operator==(StringRef, StringRef) instead of StringRef::equals ↵Kazu Hirata1-2/+2
(NFC) (#92476) Note that StringRef::equals has been deprecated in favor of operator==(StringRef, StringRef).
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-01[lldb] Fix -Wformat after #83602Fangrui Song1-2/+2
2024-03-01[lldb] Fix `thread backtrace --count` (#83602)Jonas Devlieghere1-12/+21
The help output for `thread backtrace` specifies that you can pass -1 to `--count` to display all the frames. ``` -c <count> ( --count <count> ) How many frames to display (-1 for all) ``` However, that doesn't work: ``` (lldb) thread backtrace --count -1 error: invalid integer value for option 'c' ``` The problem is that we store the option value as an unsigned and the code to parse the string correctly rejects it. There's two ways to fix this: 1. Make `m_count` a signed value so that it accepts negative values and appease the parser. The function that prints the frames takes an unsigned so a negative value will just become a really large positive value, which is what the current implementation relies on. 2. Keep `m_count` unsigned and instead use 0 the magic value to show all frames. I don't really see a point in not showing any frames at all, plus that's already broken (`error: error displaying backtrace for thread: "0x0001"`). This patch implements (2) and at the same time improve the error reporting so that we print the invalid value when we cannot parse it. rdar://123881767
2024-02-27Start to clean up the process of defining command arguments. (#83097)jimingham1-82/+8
Partly, there's just a lot of unnecessary boiler plate. It's also possible to define combinations of arguments that make no sense (e.g. eArgRepeatPlus followed by eArgRepeatPlain...) but these are never checked since we just push_back directly into the argument definitions. This commit is step 1 of this cleanup - do the obvious stuff. In it, all the simple homogenous argument lists and the breakpoint/watchpoint ID/Range types, are set with common functions. This is an NFC change, it just centralizes boiler plate. There's no checking yet because you can't get a single argument wrong. The end goal is that all argument definition goes through functions and m_arguments is hidden so that you can't define inconsistent argument sets.
2024-02-20Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)jimingham1-12/+1
This is a follow-on to: https://github.com/llvm/llvm-project/pull/82085 The completer for register names was missing from the argument table. I somehow missed that the only register completer test was x86_64, so that test broke. I added the completer in to the right slot in the argument table, and added a small completions test that just uses the alias register names. If we end up having a platform that doesn't define register names, we'll have to skip this test there, but it should add a sniff test for register completion that will run most everywhere.
2024-02-19Revert "Centralize the handling of completion for simple argument lists. ↵Shubham Sandeep Rastogi1-1/+12
(#82085)" This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5. Reverted because of greendragon failure: ******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ******************** Script:
2024-02-19Centralize the handling of completion for simple argument lists. (#82085)jimingham1-12/+1
Most commands were adding argument completion handling by themselves, resulting in a lot of unnecessary boilerplate. In many cases, this could be done generically given the argument definition and the entries in the g_argument_table. I'm going to address this in a couple passes. In this first pass, I added handling of commands that have only one argument list, with one argument type, either single or repeated, and changed all the commands that are of this sort (and don't have other bits of business in their completers.) I also added some missing connections between arg types and completions to the table, and added a RemoteFilename and RemotePath to use in places where we were using the Remote completers. Those arguments used to say they were "files" but they were in fact remote files. I also added a module arg type to use where we were using the module completer. In that case, we should call the argument module.
2023-12-16[lldb] Use StringRef::{starts,ends}_with (NFC)Kazu Hirata1-3/+3
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-14Add option to pass thread ID to thread select command (#73596)Michael Christensen1-15/+81
We'd like a way to select the current thread by its thread ID (rather than its internal LLDB thread index). This PR adds a `-t` option (`--thread_id` long option) that tells the `thread select` command to interpret the `<thread-index>` argument as a thread ID. Here's an example of it working: ``` michristensen@devbig356 llvm/llvm-project (thread-select-tid) » ../Debug/bin/lldb ~/scratch/cpp/threading/a.out (lldb) target create "/home/michristensen/scratch/cpp/threading/a.out" Current executable set to '/home/michristensen/scratch/cpp/threading/a.out' (x86_64). (lldb) b 18 Breakpoint 1: where = a.out`main + 80 at main.cpp:18:12, address = 0x0000000000000850 (lldb) run Process 215715 launched: '/home/michristensen/scratch/cpp/threading/a.out' (x86_64) This is a thread, i=1 This is a thread, i=2 This is a thread, i=3 This is a thread, i=4 This is a thread, i=5 Process 215715 stopped * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x0000555555400850 a.out`main at main.cpp:18:12 15 for (int i = 0; i < 5; i++) { 16 pthread_create(&thread_ids[i], NULL, foo, NULL); 17 } -> 18 for (int i = 0; i < 5; i++) { 19 pthread_join(thread_ids[i], NULL); 20 } 21 return 0; (lldb) thread select 2 * thread #2, name = 'a.out' frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72 libc.so.6`__nanosleep: -> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000 0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130> 0x7ffff68f9920 <+80>: movl %edx, %edi 0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp) (lldb) thread info thread #2: tid = 216047, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out' (lldb) thread list Process 215715 stopped thread #1: tid = 215715, 0x0000555555400850 a.out`main at main.cpp:18:12, name = 'a.out', stop reason = breakpoint 1.1 * thread #2: tid = 216047, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out' thread #3: tid = 216048, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out' thread #4: tid = 216049, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out' thread #5: tid = 216050, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out' thread #6: tid = 216051, 0x00007ffff68f9918 libc.so.6`__nanosleep + 72, name = 'a.out' (lldb) thread select 215715 error: invalid thread #215715. (lldb) thread select -t 215715 * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x0000555555400850 a.out`main at main.cpp:18:12 15 for (int i = 0; i < 5; i++) { 16 pthread_create(&thread_ids[i], NULL, foo, NULL); 17 } -> 18 for (int i = 0; i < 5; i++) { 19 pthread_join(thread_ids[i], NULL); 20 } 21 return 0; (lldb) thread select -t 216051 * thread #6, name = 'a.out' frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72 libc.so.6`__nanosleep: -> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000 0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130> 0x7ffff68f9920 <+80>: movl %edx, %edi 0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp) (lldb) thread select 3 * thread #3, name = 'a.out' frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72 libc.so.6`__nanosleep: -> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000 0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130> 0x7ffff68f9920 <+80>: movl %edx, %edi 0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp) (lldb) thread select -t 216048 * thread #3, name = 'a.out' frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72 libc.so.6`__nanosleep: -> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000 0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130> 0x7ffff68f9920 <+80>: movl %edx, %edi 0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp) (lldb) thread select --thread_id 216048 * thread #3, name = 'a.out' frame #0: 0x00007ffff68f9918 libc.so.6`__nanosleep + 72 libc.so.6`__nanosleep: -> 0x7ffff68f9918 <+72>: cmpq $-0x1000, %rax ; imm = 0xF000 0x7ffff68f991e <+78>: ja 0x7ffff68f9952 ; <+130> 0x7ffff68f9920 <+80>: movl %edx, %edi 0x7ffff68f9922 <+82>: movl %eax, 0xc(%rsp) (lldb) help thread select Change the currently selected thread. Syntax: thread select <cmd-options> <thread-index> Command Options Usage: thread select [-t] <thread-index> -t ( --thread_id ) Provide a thread ID instead of a thread index. This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the command options and the beginning of the arguments. (lldb) c Process 215715 resuming Process 215715 exited with status = 0 (0x00000000) ```
2023-10-30[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` ↵Pete Lawrence1-77/+63
(not `bool`) (#69991) [lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return `void` instead of ~~`bool`~~ Justifications: - The code doesn't ultimately apply the `true`/`false` return values. - The methods already pass around a `CommandReturnObject`, typically with a `result` parameter. - Each command return object already contains: - A more precise status - The error code(s) that apply to that status Part 1 refactors the `CommandObject::Execute(...)` method. - See [https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989) rdar://117378957
2023-07-06Refine the reporting mechanism for interruption.Jim Ingham1-2/+5
Also, make it possible for new Targets which haven't been added to the TargetList yet to check for interruption, and add a few more places in building modules where we can check for interruption. Differential Revision: https://reviews.llvm.org/D154542
2023-06-06[lldb/Commands] Add support to auto-completion for user commandsMed Ismail Bennani1-18/+18
This patch should allow the user to set specific auto-completion type for their custom commands. To do so, we had to hoist the `CompletionType` enum so the user can access it and add a new completion type flag to the CommandScriptAdd Command Object. So now, the user can specify which completion type will be used with their custom command, when they register it. This also makes the `crashlog` custom commands use disk-file completion type, to browse through the user file system and load the report. Differential Revision: https://reviews.llvm.org/D152011 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-05-06[lldb] Replace None with std::nullopt in comments (NFC)Kazu Hirata1-1/+1
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-04-21Make sure SelectMostRelevantFrame happens only when returning to the user.Jim Ingham1-3/+5
This is a user facing action, it is meant to focus the user's attention on something other than the 0th frame when you stop somewhere where that's helpful. For instance, stopping in pthread_kill after an assert will select the assert frame. This is not something you want to have happen internally in lldb, both because internally you really don't want the selected frame changing out from under you, and because the recognizers can do arbitrary work, and that can cause deadlocks or other unexpected behavior. However, it's not something that the current code does explicitly after a stop has been delivered, it's expected to happen implicitly as part of stopping. I changing this to call SMRF explicitly after a user stop, but that got pretty ugly quickly. So I added a bool to control whether to run this and audited all the current uses to determine whether we're returning to the user or not. Differential Revision: https://reviews.llvm.org/D148863
2023-03-15Add a Debugger interruption mechanism in conjunction with theJim Ingham1-1/+1
Command Interpreter mechanism. Differential Revision: https://reviews.llvm.org/D145136
2023-01-10Move from llvm::makeArrayRef to ArrayRef deduction guides - last partserge-sans-paille1-10/+10
This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files. Differential Revision: https://reviews.llvm.org/D141298
2023-01-07[lldb] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata1-9/+9
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-07[lldb] Add #include <optional> (NFC)Kazu Hirata1-0/+1
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-19Revert "[lldb] Remove redundant .c_str() and .get() calls"Muhammad Omair Javaid1-1/+1
This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd. This has broken all LLDB buildbots: https://lab.llvm.org/buildbot/#/builders/68/builds/44990 https://lab.llvm.org/buildbot/#/builders/96/builds/33160
2022-12-18[lldb] Remove redundant .c_str() and .get() callsFangrui Song1-1/+1
Removing .c_str() has a semantics difference, but the use scenarios likely do not matter as we don't have NUL in the strings.
2022-12-04[lldb] Use std::nullopt instead of None (NFC)Kazu Hirata1-8/+8
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-03[lldb/Commands] Add newline for extended backtrace thread (NFCI)Med Ismail Bennani1-0/+1
This adds a new line between the real thread and the extended backtrace thread when it's available. This should improve readability for the user. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-10-19[lldb][trace] Fix some minor bugs in the call treeWalter Erquinigo1-2/+4
- We weren't truncating the output files - We weren't considering the case in which we couldn't disassembly an instruction.
2022-10-18[lldb][trace] Add a basic function call dump [3] - Add a JSON dumperWalter Erquinigo1-4/+3
The JSON dumper is very minimalistic. It pretty much only shows the delimiting instruction IDs of every segment, so that further queries to the SBCursor can be used to make sense of the data. It's main purpose is to be serialized somewhat cheaply. I also renamed untracedSegment to untracedPrefixSegment, in case in the future we add an untracedSuffixSegment. In any case, this new name is more explicit, which I like. Differential Revision: https://reviews.llvm.org/D136034
2022-10-18[lldb][trace] Add a basic function call dump [2] - Implement the ↵Walter Erquinigo1-10/+28
reconstruction algorithm This diff implements the reconstruction algorithm for the call tree and add tests. See TraceDumper.h for documentation and explanations. One important detail is that the tree objects are in TraceDumper, even though Trace.h is a better home. I'm leaving that as future work. Another detail is that this code is as slow as dumping the entire symolicated trace, which is not that bad tbh. The reason is that we use symbols throughout the algorithm and we are not being careful about memory and speed. This is also another area for future improvement. Lastly, I made sure that incomplete traces work, i.e. you start tracing very deep in the stack or failures randomly appear in the trace. Differential Revision: https://reviews.llvm.org/D135917
2022-10-18[lldb][trace] Add a basic function call dumpdump [1] - Add the command ↵Walter Erquinigo1-21/+111
scaffolding The command is thread trace dump function-calls and as minimum will require printing to a file in json and non-json format I added a test Differential Revision: https://reviews.llvm.org/D135521
2022-10-15[lldb] Fix a warningKazu Hirata1-1/+1
This patch fixes: lldb/source/Commands/CommandObjectThread.cpp:66:61: warning: comparison of unsigned expression in ‘< 0’ is always false [-Wtype-limits]
2022-08-17[LLDB][NFC] Fix optons parsing and misc. reliability in CommandObjectThreadSlava Gurevich1-7/+5
* Fix broken option parsing in SetOptionValue() Differential Revision: https://reviews.llvm.org/D131983
2022-08-16Revert "[LLDB][NFC] Fix optons parsing and misc. reliability in ↵Stella Stamenova1-21/+10
CommandObjectThread" This very much non-NFC change broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/22557 This reverts commit 461b410159426fdc6da77e0fb653737e04e0ebe9.
2022-08-16[LLDB][NFC] Fix optons parsing and misc. reliability in CommandObjectThreadSlava Gurevich1-10/+21
* Improve reliability by checking return results for calls to FindLineEntryByAddress() * Fix broken option parsing in SetOptionValue() Differential Revision: https://reviews.llvm.org/D131983