[lldb] Revert scripting template list patches (#100673)

Reverts https://github.com/llvm/llvm-project/pull/97273 since it broke
the windows bot:

https://lab.llvm.org/buildbot/#/builders/141/build

[lldb] Revert scripting template list patches (#100673)

Reverts https://github.com/llvm/llvm-project/pull/97273 since it broke
the windows bot:

https://lab.llvm.org/buildbot/#/builders/141/builds/1025/steps/4/logs/stdio

show more ...

[lldb/Plugins] Fix build failure on windows following 2914a4b88837

This patch tries to fix the following build failure on windows:

https://lab.llvm.org/buildbot/#/builders/141/builds/1083

This sta

[lldb/Plugins] Fix build failure on windows following 2914a4b88837

This patch tries to fix the following build failure on windows:

https://lab.llvm.org/buildbot/#/builders/141/builds/1083

This started happening following 2914a4b88837, and it seems to be caused
by some special `#include` ordering for the lldb-python header on Windows.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

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] make it easier to find LLDB's python

It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing. I'm
currently resorting to co

[lldb] make it easier to find LLDB's python

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

show more ...

[lldb] Remove ConstString from Process, ScriptInterpreter and StructuredData plugin names

[lldb/Plugins] Introduce Scripted Interface Factory

This patch splits the previous `ScriptedProcessPythonInterface` into
multiple specific classes:

1. The `ScriptedInterface` abstract class that ca

[lldb/Plugins] Introduce Scripted Interface Factory

This patch splits the previous `ScriptedProcessPythonInterface` into
multiple specific classes:

1. The `ScriptedInterface` abstract class that carries the interface
instance object and its virtual pure abstract creation method.

2. The `ScriptedPythonInterface` that holds a generic `Dispatch` method that
can be used by various interfaces to call python methods and also keeps a
reference to the Python Script Interpreter instance.

3. The `ScriptedProcessInterface` that describes the base Scripted
Process model with all the methods used in the underlying script.

All these components are used to refactor the `ScriptedProcessPythonInterface`
class, making it more modular.

This patch is also a requirement for the upcoming work on `ScriptedThread`.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

This patch adds a ScriptedProcess interface to the ScriptInterpreter and
more specifically, to the ScriptInterpreterPython.

This

[lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

This patch adds a ScriptedProcess interface to the ScriptInterpreter and
more specifically, to the ScriptInterpreterPython.

This interface will be used in the C++ `ScriptProcess` Process Plugin to
call the script methods.

At the moment, not all methods are implemented, they will upstreamed in
upcoming patches.

This patch also adds helper methods to the ScriptInterpreter to
convert `SBAPI` Types (SBData & SBError) to `lldb_private` types
(DataExtractor & Status).

rdar://65508855

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb] Revert ScriptedProcess patches

This patch reverts the following commits:
- 5a9c34918bb1526b7e8c29aa5e4fb8d8e27e27b4
- 46796762afe76496ec4dd900f64d0cf4cdc30e99
- 2cff3dec1171188ce04ab1a4373cc1

[lldb] Revert ScriptedProcess patches

This patch reverts the following commits:
- 5a9c34918bb1526b7e8c29aa5e4fb8d8e27e27b4
- 46796762afe76496ec4dd900f64d0cf4cdc30e99
- 2cff3dec1171188ce04ab1a4373cc1885ab97be1
- 182f0d1a34419445bb19d67581d6ac1afc98b7fa
- d62a53aaf1d38a55d1affbd3a30d564a4e9d3171

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

This patch adds a ScriptedProcess interface to the ScriptInterpreter and
more specifically, to the ScriptInterpreterPython.

This

[lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

This patch adds a ScriptedProcess interface to the ScriptInterpreter and
more specifically, to the ScriptInterpreterPython.

This interface will be used in the C++ `ScriptProcess` Process Plugin to
call the script methods.

At the moment, not all methods are implemented, they will upstreamed in
upcoming patches.

This patch also adds helper methods to the ScriptInterpreter to
convert `SBAPI` Types (SBData & SBError) to `lldb_private` types
(DataExtractor & Status).

rdar://65508855

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb] Fix shared library directory computation on windows

Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to r

[lldb] Fix shared library directory computation on windows

Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to reside
in liblldb. This works great for C++ programs, but there's a catch.

When (lib)lldb is used from python (like in our test suite), this dladdr
call will return a path to the _lldb.so (or such) file in the python
directory. To compensate for this, we have code which attempts to
resolve this symlink, to ensure we get the canonical location. However,
here's the second catch.

On windows, this file is not a symlink (but a copy), so this logic
fails. Since most of our other paths are derived from the liblldb
location, all of these paths will be wrong, when running the test suite.
One effect of this was the failure to find lldb-server in D96202.

To fix this issue, I add some windows-specific code to locate the
liblldb directory. Since it cannot rely on symlinks, it works by
manually walking the directory tree -- essentially doing the opposite of
what we do when computing the python directory.

To avoid python leaking back into the host code, I implement this with
the help of a callback which can be passed to HostInfo::Initialize in
order to assist with the directory location. The callback lives inside
the python plugin.

I also strenghten the existing path test to ensure the returned path is
the right one.

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

show more ...

[lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON

This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

Differential revision: https://reviews.llv

[lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON

This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

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

show more ...

[lldb/Host] Use Host/Config.h entries instead of a global define.

As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A g

[lldb/Host] Use Host/Config.h entries instead of a global define.

As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..

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

show more ...

Add the ability to pass extra args to a Python breakpoint callback.

For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is prett

Add the ability to pass extra args to a Python breakpoint callback.

For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no
way to write a generic "stop when my caller is..." function, and then specify the caller when you add the
command to a breakpoint.

With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in
the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right
signature) when the breakpoint is hit. Then in lldb, you can say:

(lldb) break com add -F caller_is -k caller_name -v Foo

More generally this will allow us to write reusable Python breakpoint commands.

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

show more ...

[lldb] Unifying lldb python path

Based on mgorny@'s D67890

There are 3 places where python site-package path is calculated
independently:

1. finishSwigPythonLLDB.py where files are written to site

[lldb] Unifying lldb python path

Based on mgorny@'s D67890

There are 3 places where python site-package path is calculated
independently:

1. finishSwigPythonLLDB.py where files are written to site-packages.

2. lldb/scripts/CMakeLists.txt where site-packages are installed.

3. ScriptInterpreterPython.cpp where site-packages are added to
PYTHONPATH.

This change creates the path once and use it everywhere. So that they
will not go out of sync.

Also it provides a chance for cross compiling users to specify the right
path for site-packages.

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 373991

show more ...

[ScriptInterpreter] Pass the debugger instead of the command interpreter

As discussed in D61090, there's no good reason for the script
interpreter to depend on the command interpreter. When looking

[ScriptInterpreter] Pass the debugger instead of the command interpreter

As discussed in D61090, there's no good reason for the script
interpreter to depend on the command interpreter. When looking at the
code, it becomes clear that we mostly use the command interpreter as a
way to access the debugger. Hence, it makes more sense to just pass that
to the script interpreter directly.

This is part 1 out of 2. I have another patch in the pipeline that
changes the ownership of the script interpreter to the debugger as well,
but I didn't get around to finish that today.

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

llvm-svn: 359330

show more ...

[Python] Remove Python include from ScriptInterpreterPython.h

This patch limits the scope of the python header to the implementation
of the python script interpreter plugin. ScriptInterpreterPython

[Python] Remove Python include from ScriptInterpreterPython.h

This patch limits the scope of the python header to the implementation
of the python script interpreter plugin. ScriptInterpreterPython is now
an abstract interface that doesn't expose any Python specific types, and
is implemented by the ScriptInterpreterPythonImpl.

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

llvm-svn: 357307

show more ...

[ScriptInterpreterPython] Remove unused field (NFC)

The m_lldb_module was initialized but not used.

llvm-svn: 357292

[Python] Remove dynamic indirection

Now that the Python plugin relies on the SWIG symbols, we no longer need
to dynamically resolve these functions.

llvm-svn: 357034

[ScriptInterpreterPython] Make SWIG callback private (NFC)

With the initialization taking place inside the Python script
interpreter, these function no longer need to be public. The exception
is the

[ScriptInterpreterPython] Make SWIG callback private (NFC)

With the initialization taking place inside the Python script
interpreter, these function no longer need to be public. The exception
is the g_swig_init_callback which is used from the RAII object.

llvm-svn: 356944

show more ...

[ScriptInterpreterPython] Move SWIG initialization into the Python plugin (NFC)

Abstract initialization of the Python SWIG support in the Python plugin.

llvm-svn: 356942

[ScriptInterpreterPython] Remove dead code.

llvm-svn: 356487

Quiet command regex instructions during batch execution

Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninent

Quiet command regex instructions during batch execution

Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.

For example:

command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...

I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.

However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.

Reviewers: clayborg, jingham

Reviewed By: clayborg

Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits

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

llvm-svn: 355793

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdate

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626

show more ...

[lldb] Introduce StackFrameRecognizer [take 3]

This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about s

[lldb] Introduce StackFrameRecognizer [take 3]

This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).

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

llvm-svn: 345693

show more ...