aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Lua
AgeCommit message (Collapse)AuthorFilesLines
2025-04-01[lldb] Update ScriptInterpreterLua::LoadScriptingModuleJonas Devlieghere2-2/+3
Update the ScriptInterpreterLua::LoadScriptingModule signature after the TargetSP argument was added in #133290.
2025-02-19[lldb] Synchronize the debuggers output & error streamsJonas Devlieghere1-6/+18
This patch improves the synchronization of the debugger's output and error streams using two new abstractions: `LockableStreamFile` and `LockedStreamFile`. - `LockableStreamFile` is a wrapper around a `StreamFile` and a mutex. Client cannot use the `StreamFile` without calling `Lock`, which returns a `LockedStreamFile`. - `LockedStreamFile` is an RAII object that locks the stream for the duration of its existence. As long as you hold on to the returned object you are permitted to write to the stream. The destruction of the object automatically flush the output stream.
2025-02-19[lldb] Make GetOutputStreamSP and GetErrorStreamSP protected (#127682)Jonas Devlieghere1-2/+2
This makes GetOutputStreamSP and GetErrorStreamSP protected members of Debugger. Users who want to print to the debugger's stream should use GetAsyncOutputStreamSP and GetAsyncErrorStreamSP instead and the few remaining stragglers have been migrated.
2025-02-12[lldb] Remove Debugger::Get{Output,Error}Stream (NFC) (#126821)Jonas Devlieghere1-2/+2
Remove Debugger::GetOutputStream and Debugger::GetErrorStream in preparation for replacing both with a new variant that needs to be locked and hence can't be handed out like we do right now. The patch replaces most uses with GetAsyncOutputStream and GetAsyncErrorStream respectively. There methods return new StreamSP objects that automatically get flushed on destruction. See #126630 for more details.
2024-09-07[lldb] Update ScriptInterpreterLua for Status changes (NFC)Jonas Devlieghere1-10/+10
The Status constructor that takes an error has been removed in favor of Status::FromError.
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl1-2/+3
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.
2023-08-09[lldb] Sink StreamFile into lldbHostAlex Langford1-1/+1
StreamFile subclasses Stream (from lldbUtility) and is backed by a File (from lldbHost). It does not depend on anything from lldbCore or any of its sibling libraries, so I think it makes sense for this to live in lldbHost instead. Differential Revision: https://reviews.llvm.org/D157460
2023-05-15[lldb] Fix lua build after 27b6a4e63afeAlex Langford2-10/+17
This applies the same trick for Lua that I did for python in 27b6a4e63afe. Differential Revision: https://reviews.llvm.org/D150624
2023-05-02[lldb] Minor cleanups at callsites of FileSpec::GetFileNameExtensionAlex Langford1-3/+2
FileSpec::GetFileNameExtension returns a StringRef. In some cases we are calling it and then storing the result in a local. To prevent cases where we store the StringRef, mutate the Filespec, and then try to use the stored StringRef afterwards, I've audited the callsites and made adjustments to mitigate: Either marking the FileSpec it comes from as const (to avoid mutations) or by not storing the StringRef in a local if it makes sense not to. Differential Revision: https://reviews.llvm.org/D149671
2023-04-26[lldb] Change return type of FileSpec::GetFileNameExtensionAlex Langford1-1/+1
These don't really need to be in ConstStrings. It's nice that comparing ConstStrings is fast (just a pointer comparison) but the cost of creating the ConstString usually already includes the cost of doing a StringRef comparison anyway, so this is just extra work and extra memory consumption for basically no benefit. Differential Revision: https://reviews.llvm.org/D149300
2023-03-02[lldb/Interpreter] Fix build failures in ScriptInterpreterLuaMed Ismail Bennani2-5/+9
This patch should fix the build failures in the Lua ScriptedInterpreter introduced by 9a9fce1fed6d. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2023-03-02Revert "[lldb/Interpreter] Fix build failures in ScriptInterpreterLua"Med Ismail Bennani2-7/+5
This reverts commit 6de18eb050a66544cc38210024860366b84faf35.
2023-03-02[lldb/Interpreter] Fix build failures in ScriptInterpreterLuaMed Ismail Bennani2-5/+7
This patch should fix the build failures in the Lua ScriptedInterpreter introduced by 9a9fce1fed6d. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2023-02-28[lldb] Remove const qualifier on bool argument passed by valueMed Ismail Bennani1-1/+1
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2023-02-28[lldb] Fix {break,watch}point command function stopping behaviourMed Ismail Bennani1-1/+2
In order to run a {break,watch}point command, lldb can resolve to the script interpreter to run an arbitrary piece of code or call into a user-provided function. To do so, we will generate a wrapping function, where we first copy lldb's internal dictionary keys into the interpreter's global dictionary, copied inline the user code before resetting the global dictionary to its previous state. However, {break,watch}point commands can optionally return a value that would tell lldb whether we should stop or not. This feature was only implemented for breakpoint commands and since we inlined the user code directly into the wrapping function, introducing an early return, that caused lldb to let the interpreter global dictionary tinted with the internal dictionary keys. This patch fixes that issue while also adding the stopping behaviour to watchpoint commands. To do so, this patch refactors the {break,watch}point command creation method, to let the lldb wrapper function generator know if the user code is a function call or a arbitrary expression. Then the wrapper generator, if the user input was a function call, the wrapper function will call the user function and save the return value into a variable. If the user input was an arbitrary expression, the wrapper will inline it into a nested function, call the nested function and save the return value into the same variable. After resetting the interpreter global dictionary to its previous state, the generated wrapper function will return the varible containing the return value. rdar://105461140 Differential Revision: https://reviews.llvm.org/D144688 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-09-19[lldb] Remove LLDB reproducersJonas Devlieghere1-2/+2
This patch removes the remaining reproducer code. The SBReproducer class remains for ABI stability but is just an empty shell. This completes the removal process outlined on the mailing list [1]. [1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
2022-03-03[lldb] Fix the build after 8b3b66ea63d6Jonas Devlieghere1-1/+0
Remove remaining calls to FileSystem::Collect.
2021-12-13[lldb] Clarify StructuredDataImpl ownershipPavel Labath2-8/+3
StructuredDataImpl ownership semantics is unclear at best. Various structures were holding a non-owning pointer to it, with a comment that the object is owned somewhere else. From what I was able to gather that "somewhere else" was the SBStructuredData object, but I am not sure that all created object eventually made its way there. (It wouldn't matter even if they did, as we are leaking most of our SBStructuredData objects.) Since StructuredDataImpl is just a collection of two (shared) pointers, there's really no point in elaborate lifetime management, so this patch replaces all StructuredDataImpl pointers with actual objects or unique_ptrs to it. This makes it much easier to resolve SBStructuredData leaks in a follow-up patch. Differential Revision: https://reviews.llvm.org/D114791
2021-12-06[lldb/lua] Add a file that should have been a part of a52af6d3Pavel Labath1-0/+27
2021-12-06[lldb] Remove extern "C" from lldb-swig-lua interfacePavel Labath1-24/+1
This is the lua equivalent of 9a14adeae0.
2021-11-10[lldb] make it easier to find LLDB's pythonLawrence D'Anna2-0/+8
It is surprisingly difficult to write a simple python script that can reliably `import lldb` without failing, or crashing. I'm currently resorting to convolutions like this: def find_lldb(may_reexec=False): if prefix := os.environ.get('LLDB_PYTHON_PREFIX'): if os.path.realpath(prefix) != os.path.realpath(sys.prefix): raise Exception("cannot import lldb.\n" f" sys.prefix should be: {prefix}\n" f" but it is: {sys.prefix}") else: line1, line2 = subprocess.run( ['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'], encoding='utf8', stdout=subprocess.PIPE, check=True).stdout.strip().splitlines() assert line1.strip() == '(lldb) script print(sys.prefix)' prefix = line2.strip() os.environ['LLDB_PYTHON_PREFIX'] = prefix if sys.prefix != prefix: if not may_reexec: raise Exception( "cannot import lldb.\n" + f" This python, at {sys.prefix}\n" f" does not math LLDB's python at {prefix}") os.environ['LLDB_PYTHON_PREFIX'] = prefix python_exe = os.path.join(prefix, 'bin', 'python3') os.execl(python_exe, python_exe, *sys.argv) lldb_path = subprocess.run(['lldb', '-P'], check=True, stdout=subprocess.PIPE, encoding='utf8').stdout.strip() sys.path = [lldb_path] + sys.path This patch aims to replace all that with: #!/usr/bin/env lldb-python import lldb ... ... by adding the following features: * new command line option: --print-script-interpreter-info. This prints language-specific information about the script interpreter in JSON format. * new tool (unix only): lldb-python which finds python and exec's it. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D112973
2021-10-28[lldb] Remove ConstString from Process, ScriptInterpreter and StructuredData ↵Pavel Labath2-11/+4
plugin names
2021-10-18[lldb] Return StringRef from PluginInterface::GetPluginNamePavel Labath2-5/+3
There is no reason why this function should be returning a ConstString. While modifying these files, I also fixed several instances where GetPluginName and GetPluginNameStatic were returning different strings. I am not changing the return type of GetPluginNameStatic in this patch, as that would necessitate additional changes, and this patch is big enough as it is. Differential Revision: https://reviews.llvm.org/D111877
2021-10-12[lldb/lua] Force Lua version to be 5.3Siger Yang1-2/+0
Due to CMake cache, find_package in FindLuaAndSwig.cmake will be ignored. This commit adds EXACT and REQUIRED flags to it and removes find_package in Lua ScriptInterpreter. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela, JDevlieghere Differential Revision: https://reviews.llvm.org/D108515
2021-09-13[lldb] Remove PluginInterface::GetPluginVersionPavel Labath2-4/+0
In all these years, we haven't found a use for this function (it has zero callers). Lets just remove the boilerplate. Differential Revision: https://reviews.llvm.org/D109600
2021-09-03Revert "[lldb/lua] Force Lua version to be 5.3"Siger Yang1-0/+2
This commit causes buildbot failures if SWIG is available but Lua is not present. This reverts commit 7bb42dc6b114f57200abfebaaa01160914be6bba.
2021-09-03[lldb/lua] Force Lua version to be 5.3Siger Yang1-2/+0
Due to CMake cache, find_package in FindLuaAndSwig.cmake will be ignored. This commit adds EXACT and REQUIRED flags to it and removes find_package in Lua ScriptInterpreter. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela, JDevlieghere Differential Revision: https://reviews.llvm.org/D108515
2021-07-09[lldb] Add the ability to silently import scripted commandsJonas Devlieghere2-3/+5
Add the ability to silence command script import. The motivation for this change is being able to add command script import -s lldb.macosx.crashlog to your ~/.lldbinit without it printing the following message at the beginning of every debug session. "malloc_info", "ptr_refs", "cstr_refs", "find_variable", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help. In addition to forwarding the silent option to LoadScriptingModule, this also changes ScriptInterpreterPythonImpl::ExecuteOneLineWithReturn and ScriptInterpreterPythonImpl::ExecuteMultipleLines to honor the enable IO option in ExecuteScriptOptions, which until now was ignored. Note that IO is only enabled (or disabled) at the start of a session, and for this particular use case, that's done when taking the Python lock in LoadScriptingModule, which means that the changes to these two functions are not strictly necessary, but (IMO) desirable nonetheless. Differential revision: https://reviews.llvm.org/D105327
2021-07-07[lldb/lua] Add scripted watchpoints for LuaSiger Yang4-5/+121
Add support for Lua scripted watchpoints, with basic tests. Differential Revision: https://reviews.llvm.org/D105034
2021-07-02[lldb] Replace default bodies of special member functions with = default;Jonas Devlieghere1-1/+1
Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041
2021-06-15Convert functions that were returning BreakpointOption * to BreakpointOption &.Jim Ingham2-13/+16
This is an NFC cleanup. Many of the API's that returned BreakpointOptions always returned valid ones. Internally the BreakpointLocations usually have null BreakpointOptions, since they use their owner's options until an option is set specifically on the location. So the original code used pointers & unique_ptr everywhere for consistency. But that made the code hard to reason about from the outside. This patch changes the code so that everywhere an API is guaranteed to return a non-null BreakpointOption, it returns it as a reference to make that clear. It also changes the Breakpoint to hold a BreakpointOption member where it previously had a UP. Since we were always filling the UP in the Breakpoint constructor, having the UP wasn't helping anything. Differential Revision: https://reviews.llvm.org/D104162
2021-01-25[lldb/Lua] add support for Lua function breakpointPedro Tammela4-10/+50
Adds support for running a Lua function when a breakpoint is hit. Example: breakpoint command add -s lua -F abc The above runs the Lua function 'abc' passing 2 arguments. 'frame', 'bp_loc' and 'extra_args'. A third parameter 'extra_args' is only present when there is structured data declared in the command line. Example: breakpoint command add -s lua -F abc -k foo -v bar Differential Revision: https://reviews.llvm.org/D93649
2021-01-07[lldb/Lua] add support for multiline scripted breakpointsPedro Tammela4-8/+108
1 - Partial Statements The interpreter loop runs every line it receives, so partial Lua statements are not being handled properly. This is a problem for multiline breakpoint scripts since the interpreter loop, for this particular case, is just an abstraction to a partially parsed function body declaration. This patch addresses this issue and as a side effect improves the general Lua interpreter loop as well. It's now possible to write partial statements in the 'script' command. Example: (lldb) script >>> do ..> local a = 123 ..> print(a) ..> end 123 The technique implemented is the same as the one employed by Lua's own REPL implementation. Partial statements always errors out with the '<eof>' tag in the error message. 2 - CheckSyntax in Lua.h In order to support (1), we need an API for just checking the syntax of string buffers. 3 - Multiline scripted breakpoints Finally, with all the base features implemented this feature is straightforward. The interpreter loop behaves exactly the same, the difference is that it will aggregate all Lua statements into the body of the breakpoint function. An explicit 'quit' statement is needed to exit the interpreter loop. Example: (lldb) breakpoint command add -s lua Enter your Lua command(s). Type 'quit' to end. The commands are compiled as the body of the following Lua function function (frame, bp_loc, ...) end ..> print(456) ..> a = 123 ..> quit Differential Revision: https://reviews.llvm.org/D93481
2020-12-22[lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)Jonas Devlieghere1-2/+1
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-07[LLDB] fix error message for one-line breakpoint scriptsPedro Tammela1-1/+1
LLDB is ignoring compilation errors for one-line breakpoint scripts. This patch fixes the issues and now the error message of the ScriptInterpreter is shown to the user. I had to remove a new-line character for the Lua interpreter since it was duplicated. Differential Revision: https://reviews.llvm.org/D92729
2020-11-30[LLDB/Lua] add support for one-liner breakpoint callbackPedro Tammela4-0/+117
These callbacks are set using the following: breakpoint command add -s lua -o "print('hello world!')" The user supplied script is executed as: function (frame, bp_loc, ...) <body> end So the local variables 'frame', 'bp_loc' and vararg are all accessible. Any global variables declared will persist in the Lua interpreter. A user should never hold 'frame' and 'bp_loc' in a global variable as these userdatas are context dependent. Differential Revision: https://reviews.llvm.org/D91508
2020-11-05[LLDB-lua] modify Lua's 'print' to respect 'io.stdout'Pedro Tammela2-10/+30
This patch changes the implementation of Lua's `print()` function to respect `io.stdout`. The original implementation uses `lua_writestring()` internally, which is hardcoded to `stdout`. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D90787
2020-11-03[LLDB][NFC] treat Lua error codes in a more explicit mannerPedro Tammela1-2/+2
This patch is a minor suggestion to not rely on the fact that the `LUA_OK` macro is 0. This assumption could change in future versions of the C API. Differential Revision: https://reviews.llvm.org/D90556
2020-11-02[LLDB/Lua] call lua_close() on Lua dtorPedro Tammela1-1/+1
This patch calls `lua_close()` on Lua dtor. This guarantees that the Lua GC finalizers are honored, aside from the usual internal clean up. It also guarantees a call to the `__close` metamethod of any active to-be-closed variable in Lua 5.4. Since the previous `luaL_openlibs()` was a noop, because the standard library is cached internally, I've removed it. Differential Revision: https://reviews.llvm.org/D90557
2020-10-27[lldb] Support Python imports relative the to the current file being sourcedJonas Devlieghere2-5/+5
Make it possible to use a relative path in command script import to the location of the file being sourced. This allows the user to put Python scripts next to LLDB command files and importing them without having to specify an absolute path. To enable this behavior pass `-c` to `command script import`. The argument can only be used when sourcing the command from a file. rdar://68310384 Differential revision: https://reviews.llvm.org/D89334
2020-06-25[lldb/Lua] Redirect Lua stdout/stderr to the CommandReturnObjectJonas Devlieghere1-0/+32
Redirect the output of stdout and stderr to the CommandReturnObject for one line commands. Differential revision: https://reviews.llvm.org/D82412
2020-06-23[lldb/Lua] Fix typo: s/stdout/stderr/Jonas Devlieghere1-1/+1
This wasn't caught by the existing test, but will be covered by the extended test that's part of D82412.
2020-06-23[lldb/Lua] Use the debugger's output and error file for Lua's I/O library.Jonas Devlieghere3-0/+36
Add support for changing the stdout and stderr file in Lua's I/O library and hook it up with the debugger's output and error file respectively for the interactive Lua interpreter. https://reviews.llvm.org/D82273
2020-06-22[lldb/Lua] Recognize "quit" as a way to exit the script interpreter.Jonas Devlieghere1-0/+5
Add a way to quit the interactive script interpreter from a shell tests. Currently, the only way (that I know) to exit the interactive Lua interpreter is to send a EOF with CTRL-D. I noticed that the embedded Python script interpreter accepts quit (while the regular python interpreter doesn't). I've added a special case to the Lua interpreter to do the same. Differential revision: https://reviews.llvm.org/D82272
2020-06-20[lldb/Lua] Remove redundant variable (NFC)Jonas Devlieghere1-6/+3
2020-06-15[lldb/Lua] Fix override/virtual in ScriptInterpreterLua (NFC)Jonas Devlieghere2-2/+2
2020-03-24[lldb/Reproducers] Collect files imported by command script importJonas Devlieghere1-0/+1
Files imported by the script interpreter aren't opened by LLDB so they don't end up in the reproducer. The solution is to explicitly add them to the FileCollector. Differential revision: https://reviews.llvm.org/D76626
2020-02-14[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)Jonas Devlieghere1-1/+1
Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to avoid name conflict.
2020-02-10[LLDB] Fix GCC warnings about extra semicolons. NFC.Martin Storsjö1-1/+1
2020-02-07[lldb/Plugins] Use external functions to (de)initialize pluginsJonas Devlieghere1-0/+2
This is a step towards making the initialize and terminate calls be generated by CMake, which in turn is towards making it possible to disable plugins at configuration time. Differential revision: https://reviews.llvm.org/D74245