[lldb] Fix lua build after 27b6a4e63afe

This applies the same trick for Lua that I did for python in
27b6a4e63afe.

Differential Revision: https://reviews.llvm.org/D150624

[lldb] Minor cleanups at callsites of FileSpec::GetFileNameExtension

FileSpec::GetFileNameExtension returns a StringRef. In some cases we
are calling it and then storing the result in a local. To pr

[lldb] Minor cleanups at callsites of FileSpec::GetFileNameExtension

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

show more ...

[lldb] Change return type of FileSpec::GetFileNameExtension

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
c

[lldb] Change return type of FileSpec::GetFileNameExtension

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

show more ...

[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 ...

[lldb] Remove extern "C" from lldb-swig-lua interface

This is the lua equivalent of 9a14adeae0.

[lldb/lua] Add scripted watchpoints for Lua

Add support for Lua scripted watchpoints, with basic tests.

Differential Revision: https://reviews.llvm.org/D105034

[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 ...

[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 ...

[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 ...

[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 ...

[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 ...

[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 ...

[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.

[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 ...

[lldb/Lua] Support loading Lua modules

Implements the command script import command for Lua.

Differential revision: https://reviews.llvm.org/D71825

[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 ...

[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 ...

[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 ...