|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
82de8df2 |
| 25-Nov-2021 |
Pavel Labath <[email protected]> |
[lldb] Clarify StructuredDataImpl ownership
StructuredDataImpl ownership semantics is unclear at best. Various structures were holding a non-owning pointer to it, with a comment that the object is o
[lldb] Clarify StructuredDataImpl ownership
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
show more ...
|
| #
a52af6d3 |
| 06-Dec-2021 |
Pavel Labath <[email protected]> |
[lldb] Remove extern "C" from lldb-swig-lua interface
This is the lua equivalent of 9a14adeae0.
|
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
e81ba283 |
| 04-Jul-2021 |
Siger Yang <[email protected]> |
[lldb/lua] Add scripted watchpoints for Lua
Add support for Lua scripted watchpoints, with basic tests.
Differential Revision: https://reviews.llvm.org/D105034
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
532e4203 |
| 21-Dec-2020 |
Pedro Tammela <[email protected]> |
[lldb/Lua] add support for Lua function breakpoint
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 functio
[lldb/Lua] add support for Lua function breakpoint
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
show more ...
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
d853bd7a |
| 16-Dec-2020 |
Pedro Tammela <[email protected]> |
[lldb/Lua] add support for multiline scripted breakpoints
1 - Partial Statements
The interpreter loop runs every line it receives, so partial Lua statements are not being handled properly. This is
[lldb/Lua] add support for multiline scripted breakpoints
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
show more ...
|
| #
280ae107 |
| 06-Dec-2020 |
Pedro Tammela <[email protected]> |
[LLDB] fix error message for one-line breakpoint scripts
LLDB is ignoring compilation errors for one-line breakpoint scripts. This patch fixes the issues and now the error message of the ScriptInter
[LLDB] fix error message for one-line breakpoint scripts
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
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
a0d7406a |
| 15-Nov-2020 |
Pedro Tammela <[email protected]> |
[LLDB/Lua] add support for one-liner breakpoint callback
These callbacks are set using the following: breakpoint command add -s lua -o "print('hello world!')"
The user supplied script is execute
[LLDB/Lua] add support for one-liner breakpoint callback
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
show more ...
|
| #
ca175710 |
| 05-Nov-2020 |
Pedro Tammela <[email protected]> |
[LLDB-lua] modify Lua's 'print' to respect 'io.stdout'
This patch changes the implementation of Lua's `print()` function to respect `io.stdout`.
The original implementation uses `lua_writestring()`
[LLDB-lua] modify Lua's 'print' to respect 'io.stdout'
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
show more ...
|
| #
4b9fa3b7 |
| 01-Nov-2020 |
Pedro Tammela <[email protected]> |
[LLDB][NFC] treat Lua error codes in a more explicit manner
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
[LLDB][NFC] treat Lua error codes in a more explicit manner
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
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
be494adb |
| 23-Jun-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Lua] Fix typo: s/stdout/stderr/
This wasn't caught by the existing test, but will be covered by the extended test that's part of D82412.
|
| #
fa1b4a96 |
| 23-Jun-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Lua] Use the debugger's output and error file for Lua's I/O library.
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 erro
[lldb/Lua] Use the debugger's output and error file for Lua's I/O library.
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
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init |
|
| #
572b9f46 |
| 10-Jan-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Lua] Support loading Lua modules
Implements the command script import command for Lua.
Differential revision: https://reviews.llvm.org/D71825
|
| #
45c971f7 |
| 09-Jan-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Lua] Make lldb.debugger et al available to Lua
The Python script interpreter makes the current debugger, target, process, thread and frame available to interactive scripting sessions through c
[lldb/Lua] Make lldb.debugger et al available to Lua
The Python script interpreter makes the current debugger, target, process, thread and frame available to interactive scripting sessions through convenience variables. This patch does the same for Lua.
Differential revision: https://reviews.llvm.org/D71801
show more ...
|
| #
4164be72 |
| 21-Dec-2019 |
Jonas Devlieghere <[email protected]> |
[Lldb/Lua] Persist Lua state across script interpreter calls.
Don't create a new lua state on every operation. Share a single state across the lifetime of the script interpreter. Add simple locking
[Lldb/Lua] Persist Lua state across script interpreter calls.
Don't create a new lua state on every operation. Share a single state across the lifetime of the script interpreter. Add simple locking to prevent two threads from modifying the state concurrently.
show more ...
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3 |
|
| #
28613242 |
| 08-Dec-2019 |
Jonas Devlieghere <[email protected]> |
[lldb/Lua] Implement a Simple Lua Script Interpreter Prototype
This implements a very elementary Lua script interpreter. It supports running a single command as well as running interactively. It use
[lldb/Lua] Implement a Simple Lua Script Interpreter Prototype
This implements a very elementary Lua script interpreter. It supports running a single command as well as running interactively. It uses editline if available. It's still missing a bunch of stuff though. Some things that I intentionally ingored for now are that I/O isn't properly hooked up (so every print goes to stdout) and the non-editline support which is not handling a bunch of corner cases. The latter is a matter of reusing existing code in the Python interpreter.
Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71234
show more ...
|