|
Revision tags: 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, working, 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, 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 <sigeryeung@gmail.com> |
[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 <pctammela@gmail.com> |
[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 <pctammela@gmail.com> |
[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 ...
|
|
Revision tags: llvmorg-11.0.1-rc1 |
|
| #
a0d7406a |
| 15-Nov-2020 |
Pedro Tammela <pctammela@gmail.com> |
[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 <pctammela@gmail.com> |
[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 ...
|
| #
4d7d6f27 |
| 01-Nov-2020 |
Pedro Tammela <pctammela@gmail.com> |
[LLDB/Lua] call lua_close() on Lua dtor
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 guarante
[LLDB/Lua] call lua_close() on Lua dtor
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
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 |
|
| #
fa1b4a96 |
| 23-Jun-2020 |
Jonas Devlieghere <jonas@devlieghere.com> |
[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 <jonas@devlieghere.com> |
[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 <jonas@devlieghere.com> |
[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 <jonas@devlieghere.com> |
[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 |
|
| #
bf03e17c |
| 08-Dec-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[Lldb/Lua] Generate Lua Bindings
This patch uses SWIG to generate the Lua bindings for the SB API. It
covers most of the API, but some methods require a type map similar to
Python.
Discussion on th
[Lldb/Lua] Generate Lua Bindings
This patch uses SWIG to generate the Lua bindings for the SB API. It
covers most of the API, but some methods require a type map similar to
Python.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71235
show more ...
|
| #
28613242 |
| 08-Dec-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[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 ...
|