aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Interpreter/CommandInterpreter.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-09-13Be more careful to maintain quoting information when parsing commands.Jim Ingham1-14/+48
This is particularly a problem for alias construction, where you might want to have a backtick surrounded option in the alias. Before this patch: command alias expression -Z \`argc\` -- argv for instance would be rendered as: expression -Z argc -- argv and would fail to work. Differential Revision: https://reviews.llvm.org/D133045
2022-09-08[lldb] Use std::size instead of llvm::array_lengthofJoe Loser1-1/+1
LLVM contains a helpful function for getting the size of a C-style array: `llvm::array_lengthof`. This is useful prior to C++17, but not as helpful for C++17 or later: `std::size` already has support for C-style arrays. Change call sites to use `std::size` instead. Differential Revision: https://reviews.llvm.org/D133501
2022-06-20Don't use Optional::hasValue (NFC)Kazu Hirata1-1/+1
2022-05-20[lldb] Fix spurious assertion in PrintCommandOutputJonas Devlieghere1-8/+4
When the string passed to PrintCommandOutput doesn't end with a newline, `written` will exceed `size` and result in an lldbassert. After 8e776bb660dda6c51ce7ca6cea641db1f47aa9cf we don't really need written anymore and we can check whether `str` is empty instead. This patch simplifies the code and removes the assert that's no longer relevant. Differential revision: https://reviews.llvm.org/D126081
2022-05-03[lldb] Add setting for max depth of value object printing (NFC)Dave Lee1-1/+2
This adds a setting (`target.max-children-depth`) that will provide a default value for the `--depth` flag used by `expression` and `frame variable`. The new setting uses the same default that's currently fixed in source: `UINT32_MAX`. This provides two purposes: 1. Allowing downstream forks to provide a customized default. 2. Allowing users to set their own default. Following `target.max-children-count`, a warning is emitted when the max depth is reached. The warning lets users know which flags or settings they can customize. This warning is shown only when the limit is the default value. rdar://87466495 Differential Revision: https://reviews.llvm.org/D123954
2022-04-26Don't push null ExecutionContext on CommandInterp exectx stackJason Molenda1-3/+9
The driver can push a null ExecutionContext on to this stack, and later calls to SBCommandInterpreter::HandleCommand which don't specify an ExecutionContext can pull an entry from the stack, resulting in settings that aren't applied. Differential Revision: https://reviews.llvm.org/D111209 rdar://81489207
2022-04-05Fix a mistyping introduced with the new container command.Jim Ingham1-1/+1
I also added a call to help in the test which was crashing before the test, and not after.
2022-03-31Add a setting to not require --overwrite to overwrite commands.Jim Ingham1-0/+6
Protecting against accidental overwriting of commands is good, but having to pass a flag to overwrite the command when developing your commands is pretty annoying. This adds a setting to defeat the protection so you can do this once at the start of your session and not have to worry about it again. Differential Revision: https://reviews.llvm.org/D122680
2022-03-23[lldb] Remove lldbassert from CommandInterpreter::PrintCommandOutputJonas Devlieghere1-13/+7
The assertion checks that the command output doesn't contain any null bytes. I'm not sure if the intention was to make sure the string wasn't shorter than the reported length or if this was a way to catch us accidentally writing an (unformatted) null byte. The consensus is that we don't want to have embedded nulls in the command output, but that this isn't the right place to enforce that. Differential revision: https://reviews.llvm.org/D122025
2022-03-15Re-land "[lldb] Synchronize output through the IOHandler"Jonas Devlieghere1-10/+20
Add synchronization to the IOHandler to prevent multiple threads from writing concurrently to the output or error stream. A scenario where this could happen is when a thread (the default event thread for example) is using the debugger's asynchronous stream. We would delegate this operation to the IOHandler which might be running on another thread. Until this patch there was nothing to synchronize the two at the IOHandler level. Differential revision: https://reviews.llvm.org/D121500
2022-03-15Revert "[lldb] Synchronize output through the IOHandler"Jonas Devlieghere1-20/+10
This reverts commit 242c574dc03e4b90e992cc8d07436efc3954727f because it breaks the following tests on the bots: - TestGuiExpandThreadsTree.py - TestBreakpointCallbackCommandSource.py
2022-03-15[lldb] Synchronize output through the IOHandlerJonas Devlieghere1-10/+20
Add synchronization to the IOHandler to prevent multiple threads from writing concurrently to the output or error stream. A scenario where this could happen is when a thread (the default event thread for example) is using the debugger's asynchronous stream. We would delegate this operation to the IOHandler which might be running on another thread. Until this patch there was nothing to synchronize the two at the IOHandler level. Differential revision: https://reviews.llvm.org/D121500
2022-03-04[LLDB] Flush stream at the end of PrintCommandOutputZequan Wu1-0/+1
On Windows, lldb doesn't print any error message until exit. This fixes it. Differential Revision: https://reviews.llvm.org/D120961
2022-02-25[lldb] Fix check for TARGET_OS_IPHONEJonas Devlieghere1-1/+5
Instead of checking whether TARGET_OS_IPHONE is set to 1, the current code just check the existence of TARGET_OS_IPHONE, which either always succeeds or always fails, depending on whether you have TargetConditionals.h included.
2022-02-18[lldb] Add support for a "global" lldbinit filePavel Labath1-0/+15
This patch adds introduces a new kind of an lldbinit file. Unlike the lldbinit in the home directory (useful for customizing lldb to the needs of a particular user), or the cwd lldbinit file (useful for project-specific settings), this file can be used to customize an entire lldb installation to a particular environment. The feature is enabled at build time, by setting the LLDB_GLOBAL_INIT_DIRECTORY variable to a path to a directory which should contain an "lldbinit" file. Lldb will then load the file at startup, if it exists, and if automatic init loading has not been disabled. Relative paths will be resolved (at runtime) relative to the location of the lldb library (liblldb or LLDB.framework). The system-wide lldbinit file will be loaded first, before any $HOME/.lldbinit and $CWD/.lldbinit files are processed, so that those can override any system-wide settings. More information can be found on the RFC thread at <https://discourse.llvm.org/t/rfc-system-wide-lldbinit/59933>. Differential Revision: https://reviews.llvm.org/D119831
2022-02-16[lldb/API] Add a way to check if the CommandInterpreter is interactiveMed Ismail Bennani1-0/+4
This patch adds the ability for the user to check if the command interpreter's IOHandler is interactive. Differential Revision: https://reviews.llvm.org/D119499 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-02-14Add a repeat command option for "thread backtrace --count N".Jim Ingham1-5/+10
This way if you have a long stack, you can issue "thread backtrace --count 10" and then subsequent <Return>-s will page you through the stack. This took a little more effort than just adding the repeat command, since the GetRepeatCommand API was returning a "const char *". That meant the command had to keep the repeat string alive, which is inconvenient. The original API returned either a nullptr, or a const char *, so I changed the private API to return an llvm::Optional<std::string>. Most of the patch is propagating that change. Also, there was a little thinko in fetching the repeat command. We don't fetch repeat commands for commands that aren't being added to history, which is in general reasonable. And we don't add repeat commands to the history - also reasonable. But we do want the repeat command to be able to generate the NEXT repeat command. So I adjusted the logic in HandleCommand to work that way. Differential Revision: https://reviews.llvm.org/D119046
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath1-0/+1
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.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath1-3/+3
2022-01-26Revert "Rename llvm::array_lengthof into llvm::size to match std::size from ↵Benjamin Kramer1-1/+1
C++17" This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2. - It conflicts with the existing llvm::size in STLExtras, which will now never be called. - Calling it without llvm:: breaks C++17 compat
2022-01-26Rename llvm::array_lengthof into llvm::size to match std::size from C++17serge-sans-paille1-1/+1
As a conquence move llvm::array_lengthof from STLExtras.h to STLForwardCompat.h (which is included by STLExtras.h so no build breakage expected).
2022-01-09[lldb] Compute fully qualified command names in FindCommandsForAproposDave Lee1-11/+14
Fixes incomplete command names in `apropos` results. The full command names given by `apropos` have come from command name string literals given to `CommandObject` constructors. For most commands, this has been accurate, but some commands have incorrect strings. This results in `apropos` output that doesn't tell the user the full command name they might want learn more about. These strings can be fixed. There's a seperate issue that can't be fixed as easily: plugin commands. With the way they're implemented, plugin commands have to exclude the root command from their command name string. To illustrate, the `language objc` subcommand has to set its command name string to "objc", which results in apropos printing results as `objc ...` instead of `language objc ...`. To fix both of these issues, this commit changes `FindCommandsForApropos` to derive the fully qualified command name using the keys of subcommand maps. Differential Revision: https://reviews.llvm.org/D116491 (cherry picked from commit b3bfd595a548cd85b12e4e83729436cb73b26f29)
2022-01-06Revert "[lldb] Compute fully qualified command names in FindCommandsForApropos"Dave Lee1-14/+11
This reverts commit b3bfd595a548cd85b12e4e83729436cb73b26f29.
2022-01-06[lldb] Compute fully qualified command names in FindCommandsForAproposDave Lee1-11/+14
Fixes incomplete command names in `apropos` results. The full command names given by `apropos` have come from command name string literals given to `CommandObject` constructors. For most commands, this has been accurate, but some commands have incorrect strings. This results in `apropos` output that doesn't tell the user the full command name they might want learn more about. These strings can be fixed. There's a seperate issue that can't be fixed as easily: plugin commands. With the way they're implemented, plugin commands have to exclude the root command from their command name string. To illustrate, the `language objc` subcommand has to set its command name string to "objc", which results in apropos printing results as `objc ...` instead of `language objc ...`. To fix both of these issues, this commit changes `FindCommandsForApropos` to derive the fully qualified command name using the keys of subcommand maps. Differential Revision: https://reviews.llvm.org/D116491
2022-01-05[lldb] Create a property to store the REPL languageJonas Devlieghere1-8/+10
Until the introduction of the C++ REPL, there was always a single REPL language. Several places relied on this assumption through repl_languages.GetSingularLanguage. Now that this is no longer the case, we need a way to specify a selected/preferred REPL language. This patch does that with the help of a debugger property, taking inspiration from how we store the scripting language. Differential revision: https://reviews.llvm.org/D116697
2021-12-24Remove redundant return and continue statements (NFC)Kazu Hirata1-3/+0
Identified with readability-redundant-control-flow.
2021-11-22Revert "[lldb] Load the fblldb module automatically"Walter Erquinigo1-14/+0
This reverts commit 2e6a0a8b81d7be948491ce39d241695dc1385429. It was pushed by mistake..
2021-11-22[lldb] Load the fblldb module automaticallyWalter Erquinigo1-0/+14
Summary: ``` // Facebook only: // We want to load automatically the fblldb python module as soon as lldb or // lldb-vscode start. This will ensure that logging and formatters are enabled // by default. // // As we want to have a mechanism for not triggering this by default, if the // user is starting lldb disabling .lldbinit support, then we also don't load // this module. This is equivalent to appending this line to all .lldbinit // files. // // We don't have the fblldb module on windows, so we don't include it for that // build. ``` Test Plan: the fbsymbols module is loaded automatically ``` ./bin/lldb (lldb) help fbsymbols Facebook {mini,core}dump utility. Expects 'raw' input (see 'help raw-input'.) ``` Reviewers: wanyi Reviewed By: wanyi Subscribers: mnovakovic, serhiyr, phabricatorlinter Differential Revision: https://phabricator.intern.facebook.com/D29372804 Tags: accept2ship Signature: 29372804:1624567770:07836e50e576bd809124ed80a6bc01082190e48f [lldb] Load fblldbinit instead of fblldb Summary: Once accepted, it'll merge it with the existing commit in our branch so that we keep the commit list as short as possible. Test Plan: https://www.internalfb.com/diff/D30293094 Reviewers: aadsm, wanyi Reviewed By: aadsm Subscribers: mnovakovic, serhiyr Differential Revision: https://phabricator.intern.facebook.com/D30293211 Tags: accept2ship Signature: 30293211:1628880953:423e2e543cade107df69da0ebf458e581e54ae3a
2021-10-19[lldb] improve the help strings for gdb-remote and kdp-remoteLawrence D'Anna1-5/+8
The help string can be more helpful by explaining these are aliases for 'process connect' Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D111965
2021-10-19Remove unneeded variable num_found.Jim Ingham1-5/+3
2021-10-18Add a "command container" hierarchy to allow users to add container nodes.Jim Ingham1-25/+203
The point is to allow users with a related set of script based commands to organize their commands in a hierarchy in the command set, rather than having to have only top-level commands. Differential Revision: https://reviews.llvm.org/D110298
2021-10-08[lldb] Remove shared_ptr from some global Properties objectsPavel Labath1-8/+2
they're unnecessary, make the code longer, and their removal actually ensures proper initialization in multithreaded scenarios.
2021-08-09[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compatMichał Górny1-2/+2
Modify OpenOptions enum to open the future path into synchronizing vFile:open bits with GDB. Currently, LLDB and GDB use different flag models effectively making it impossible to match bits. Notably, LLDB uses two bits to indicate read and write status, and uses union of both for read/write. GDB uses a value of 0 for read-only, 1 for write-only and 2 for read/write. In order to future-proof the code for the GDB variant: 1. Add a distinct eOpenOptionReadWrite constant to be used instead of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required. 2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly and eOpenOptionWriteOnly respectively, to make it clear that they do not mean to be combined and require update to all call sites. 3. Use the intersection of all three flags when matching against the three possible values. This commit does not change the actual bits used by LLDB. Differential Revision: https://reviews.llvm.org/D106984
2021-06-29[lldb/Interpreter] Fix session-save-on-quit when using ^DMed Ismail Bennani1-0/+1
Previously, when `interpreter.save-session-on-quit` was enabled, lldb would save the session transcript only when running the `quit` command. This patch changes that so the transcripts are saved when the debugger object is destroyed if the setting is enabled. rdar://72902650 Differential Revision: https://reviews.llvm.org/D105038 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-06-29[lldb/Interpreter] Add setting to set session transcript save directoryMed Ismail Bennani1-3/+19
This patch introduces a new interpreter setting `interpreter.save-session-directory` so the user can specify a directory where the session transcripts will be saved. If not set, the session transcript are saved on a temporary file. rdar://72902842 Differential Revision: https://reviews.llvm.org/D105030 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-06-25[lldb] Rename StringRef _lower() method calls to _insensitive()Martin Storsjö1-1/+1
2021-06-17[lldb] Remove redundant calls to set eReturnStatusFailedDavid Spickett1-15/+0
Since https://reviews.llvm.org/D103701 AppendError<...> sets this for you. This change includes all of the non-command uses. Some uses remain where it's either tricky to reason about the logic, or they aren't paired with AppendError calls. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D104379
2021-06-08[lldb] Don't print script output twice in HandleCommandJonas Devlieghere1-0/+1
When executing a script command in HandleCommand(s) we currently print its output twice You can see this issue in action when adding a breakpoint command: (lldb) b main Breakpoint 1: where = main.out`main + 13 at main.cpp:2:3, address = 0x0000000100003fad (lldb) break command add 1 -o "script print(\"Hey!\")" (lldb) r Process 76041 launched: '/tmp/main.out' (x86_64) Hey! (lldb) script print("Hey!") Hey! Process 76041 stopped The issue is caused by HandleCommands using a temporary CommandReturnObject and one of the commands (`script` in this case) setting an immediate output stream. This causes the result to be printed twice: once directly to the immediate output stream and once when printing the result of HandleCommands. This patch fixes the issue by introducing a new option to suppress immediate output for temporary CommandReturnObjects. Differential revision: https://reviews.llvm.org/D103349
2021-06-01[various] Remove or use variables which are unused but set.Michael Benfield1-4/+0
This is in preparation for the -Wunused-but-set-variable warning. Differential Revision: https://reviews.llvm.org/D102942
2021-05-26[lldb][NFC] Use C++ versions of the deprecated C standard library headersRaphael Isemann1-1/+1
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D103084
2021-05-18[lldb][NFC] Remove all uses of StringRef::withNullAsEmpty in LLDBRaphael Isemann1-6/+6
A long time ago LLDB wanted to start using StringRef instead of C-Strings/ConstString but was blocked by the fact that the StringRef constructor that takes a C-string was asserting that the C-string isn't a nullptr. To workaround this, D24697 introduced a special function called `withNullAsEmpty` and that's what LLDB (and only LLDB) started to use to build StringRefs from C-strings. A bit later it seems that `withNullAsEmpty` was declared too awkward to use and instead the assert in the StringRef constructor got removed (see D24904). The rest of LLDB was then converted to StringRef by just calling the now perfectly usable implicit constructor. However, all the calls to `withNullAsEmpty` just remained and are now just strange artefacts in the code base that just look out of place. It's also curiously a LLDB-exclusive function and no other project ever called it since it's introduction half a decade ago. This patch removes all uses of `withNullAsEmpty`. The follow up will be to remove the function from StringRef. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D102597
2021-03-30[trace][intel-pt] Implement trace start and trace stopWalter Erquinigo1-1/+3
This implements the interactive trace start and stop methods. This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now. There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are: - New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive. - Implementation of the "process trace start|stop" and "thread trace start|stop" commands. - Implementaiton of an API in Trace.h to interact with live traces. - Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache. - Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced. - Added tests I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff. Differential Revision: https://reviews.llvm.org/D91679
2021-03-05[lldb/Interpreter] Add `interpreter.repeat-previous-command` settingMed Ismail Bennani1-0/+11
This patch introduces a new interpreter setting to prevent LLDB from re-executing the previous command when passing an empty command. This can be very useful when performing actions that requires a long time to complete. To preserve the original behaviour, the setting defaults to `true`. rdar://74983516 Differential Revision: https://reviews.llvm.org/D97999 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-02-28[lldb/Interpreter][NFC] Remove explicit default initialization of members ↵Tatyana Krasnukha1-3/+2
and base classes According to clang-tidy's readability-redundant-member-init.
2021-02-11[lldb] Fix 'r' and 'run' aliases on Apple SiliconJonas Devlieghere1-7/+3
The 'r' and 'run' aliases were different based on the target architecture. I suspect the intention was to disable shell expansion on embedded devices. This fixes TestCustomShell.test on AS.
2021-02-08[LLDB] Fix `Wunused-result` warningFrederik Gossen1-1/+3
2021-02-08Reland "[lldb] Make CommandInterpreter's execution context the same as ↵Tatyana Krasnukha1-67/+70
debugger's one"
2020-12-23[lldb] Refactor and simplify GetCommandSPExact interfaceJonas Devlieghere1-70/+69
GetCommandSPExact is called exaclty once with include_aliases set to true, so make it a default argument. Use early returns to simplify the implementation.
2020-12-22[lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)Jonas Devlieghere1-7/+3
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly repetitive creation of scoped timers in LLDB. It's similar to the LLDB_LOG(F) macro. Differential revision: https://reviews.llvm.org/D93663
2020-12-17Revert "[lldb] Make CommandInterpreter's execution context the same as ↵Pavel Labath1-68/+68
debugger's one." This reverts commit a01b26fb51c710a3a8ef88cc83b0701461f5b9ab, because it breaks the "finish" command in some way -- the command does not terminate after it steps out, but continues running the target. The exact blast radius is not clear, but it at least affects the usage of the "finish" command in TestGuiBasicDebug.py. The error is *not* gui-related, as the same issue can be reproduced by running the same steps outside of the gui. There is some kind of a race going on, as the test fails only 20% of the time on the buildbot.
generated by cgit v1.1 at 2025-10-02 15:37:13 +0000