[lldb] Introduce OperatingSystem{,Python}Interface and make use it

This patch aims to consolidate the OperatingSystem scripting affordance
by introducing a stable interface that conforms to the
Scri

[lldb] Introduce OperatingSystem{,Python}Interface and make use it

This patch aims to consolidate the OperatingSystem scripting affordance
by introducing a stable interface that conforms to the
Scripted{,Python}Interface.

This unify the way we call into python methods from lldb while
also improving its capabilities by allowing us to pass lldb_private
objects are arguments.

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

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

show more ...

[lldb] Move ScriptInterpreter Interfaces to subdirectory (NFC)

As we're consolidating and streamlining the various scripting
affordances of lldb, we keep creating new interface files.

This patch g

[lldb] Move ScriptInterpreter Interfaces to subdirectory (NFC)

As we're consolidating and streamlining the various scripting
affordances of lldb, we keep creating new interface files.

This patch groups all the current interface files into a separate sub
directory called `Interfaces` both in the core `Interpreter` directory
and the `ScriptInterpreter` plugin directory.

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

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

show more ...

[lldb] Fix build after d5a62b78b8ae

I renamed something but forgot to update the uses of it. Minor thinko.

[lldb][NFCI] Remove unneccessary allocation in ScriptInterpreterPythonImpl::GetSyntheticTypeName (#66724)

Instead of copying memory out of the PythonString (via a std::string)
and then using that t

[lldb][NFCI] Remove unneccessary allocation in ScriptInterpreterPythonImpl::GetSyntheticTypeName (#66724)

Instead of copying memory out of the PythonString (via a std::string)
and then using that to create a ConstString, it would make more sense to
just create the ConstString from the original StringRef in the first
place.

show more ...

[lldb] Remove outdated comment and radar link (NFC)

The comment and radar referenced PyThreadState_Get which is no longer
used there and instead has been replaced to a call to
PyThreadState_GetDict

[lldb] Remove outdated comment and radar link (NFC)

The comment and radar referenced PyThreadState_Get which is no longer
used there and instead has been replaced to a call to
PyThreadState_GetDict which has different semantics. Unlike
PyThreadState_Get, it can return NULL and it is okay to call this
function when no current thread state is available.

show more ...

[lldb] Convert script native types to StructuredData counterpart

This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.

To

[lldb] Convert script native types to StructuredData counterpart

This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.

To do so, this patch changes the `ScriptedObject` struture that holds
the pointer to the script object as well as the originating script
interpreter language. It also exposes that to the SB API via a new class
called `SBScriptObject`.

This structure allows the debugger to parse the script object and
convert it to a StructuredData object. If the type is not compatible
with the StructuredData types, we will store its pointer in a
`StructuredData::Generic` object.

This patch also adds some SWIG typemaps that checks the input argument to
ensure it's either an SBStructuredData object, in which case it just
passes it throught, or a python object that is NOT another SB type, to
provide some guardrails for the user.

rdar://111467140

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

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

show more ...

[lldb][NFCI] Change type of SBDebugger::m_instance_name

This doesn't need to be in the ConstString StringPool. There's little
benefit to having these be unique, and we don't need fast comparisons on

[lldb][NFCI] Change type of SBDebugger::m_instance_name

This doesn't need to be in the ConstString StringPool. There's little
benefit to having these be unique, and we don't need fast comparisons on
them.

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

show more ...

[lldb] Mark most SBAPI methods involving private types as protected or private

Many SB classes have public constructors or methods involving types that
are private. Some are more obvious (e.g. conta

[lldb] Mark most SBAPI methods involving private types as protected or private

Many SB classes have public constructors or methods involving types that
are private. Some are more obvious (e.g. containing lldb_private in the
name) than others (lldb::FooSP is usually std::shared_pointer<lldb_private::Foo>).

This commit explicitly does not address FileSP, so I'm leaving that one
alone for now.

Some of these were for other SB classes to use and should have been made
protected/private with a friend class entry added. Some of these were
public for some of the swig python helpers to use. I put all of those
functions into a class and made them static methods. The relevant SB
classes mark that class as a friend so they can access those
private/protected members.

I've also removed an outdated SBStructuredData test (can you guess which
constructor it was using?) and updated the other relevant tests.

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

show more ...

Allow scripted thread plans to modify the thread stop description when
they are completed.

[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] Remove const qualifier on bool argument passed by value

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

[lldb] Fix {break,watch}point command function stopping behaviour

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 i

[lldb] Fix {break,watch}point command function stopping behaviour

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>

show more ...

[lldb] Remove pydoc import during script interpreter init

The Python script interpreter imports `pydoc` during initialization, but this can be
slow in some cases, and doesn't seem to be necessary an

[lldb] Remove pydoc import during script interpreter init

The Python script interpreter imports `pydoc` during initialization, but this can be
slow in some cases, and doesn't seem to be necessary any more.

This can be slow because pydoc may execute shell commands (for example `xcrun` on
macOS). The shell commands may have variable performance, depending on their caches and
search space.

The 2012 bug report for the original commit (f71a8399997bfdc1ddeeb30c6a8897554a11c382)
says the following:

> "script help" in lldb pipes the help documentation through less(1) but there's some
> problem with the key handling and often the keys you'd use to move in less (space to
> move down a page, 'q' to quit) are not received by less (they're going to lldb
> instead)

This was resolved at the time by overriding `pydoc`'s pager to be the `plainpager`
function.

I have manually tested `script help(lldb.SBDebugger)` and found no issues with the
pager, including using "space" for paging, "/" for searching, and "q" for quitting.

The presumption is that lldb and/or Python have improved I/O handling that eliminates
the original problem.

The original bug report gave an ~/.lldbinit workaround:

```
script import pydoc; pydoc.pager = pydoc.plainpager
```

Note that calling Python's `help()` will import `pydoc`, but this will only happen for
users who use `help()` from the `script` command.

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

show more ...

Report a useful error when someone passes an incorrect python class name.

[lldb/Plugins] Fix method dispatch bug when using multiple scripted processes

This patch should address a bug when a user have multiple scripted
processes in the same debugging session.

In order fo

[lldb/Plugins] Fix method dispatch bug when using multiple scripted processes

This patch should address a bug when a user have multiple scripted
processes in the same debugging session.

In order for the scripted process plugin to be able to call into the
scripted object instance methods to fetch the necessary data to
reconstruct its state, the scripted process plugin calls into a
scripted process interface, that has a reference to the created script
object instance.

However, prior to this patch, we only had a single instance of the
scripted process interface, living the script interpreter. So every time
a new scripted process plugin was created, it would overwrite the script
object instance that was held by the single scripted process interface
in the script interpreter.

That would cause all the method calls made to the scripted process
interface to be dispatched by the last instanciated script object
instance, which is wrong.

In order to prevent that, this patch moves the scripted process
interface reference to be help by the scripted process plugin itself.

rdar://104882562

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

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

show more ...

[lldb/Interpreter] Introduce ScriptedPlatform{,Python}Interface

This patch introduces both the ScriptedPlatformInterface and the
ScriptedPlatformPythonInterface. As the name suggests, these calls wi

[lldb/Interpreter] Introduce ScriptedPlatform{,Python}Interface

This patch introduces both the ScriptedPlatformInterface and the
ScriptedPlatformPythonInterface. As the name suggests, these calls will
be used to call into the Scripted Platform python implementation from
the C++ Scripted Platform plugin instance.

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

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

show more ...

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Switch the "command script add" interactive input to use the new command form.

We're suggesting people use the form of the command that takes an exe_ctx - it
is both more convenient and more correct

Switch the "command script add" interactive input to use the new command form.

We're suggesting people use the form of the command that takes an exe_ctx - it
is both more convenient and more correct - since you should not be using
GetSelected{Target, Process, etc.} in commands.

show more ...

[lldb/Python] Make use of PythonObject and PythonFormat in callbacks (NFC)

This patch extends the template specialization of PythonFormat structs
and makes use of the pre-existing PythonObject class

[lldb/Python] Make use of PythonObject and PythonFormat in callbacks (NFC)

This patch extends the template specialization of PythonFormat structs
and makes use of the pre-existing PythonObject class to format arguments
and pass them to the right method, before calling it.

This is a preparatory patch to merge PythonFormat with SWIGPythonBridge's
GetPythonValueFormatString methods.

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

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

show more ...

[lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The

[lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The new method
allows users to specify the name of a Python callback function that
takes a `SBType` object and decides whether the type is a match or not.

Here is an overview of the changes performed:

- Add a new `eFormatterMatchCallback` matching type, and logic to handle
it in `TypeMatcher` and `SBTypeNameSpecifier`.

- Extend `FormattersMatchCandidate` instances with a pointer to the
current `ScriptInterpreter` and the `TypeImpl` corresponding to the
candidate type, so we can run registered callbacks and pass the type
to them. All matcher search functions now receive a
`FormattersMatchCandidate` instead of a type name.

- Add some glue code to ScriptInterpreterPython and the SWIG bindings to
allow calling a formatter matching callback. Most of this code is
modeled after the equivalent code for watchpoint callback functions.

- Add an API test for the new callback-based matching feature.

For more context, please check the RFC thread where this feature was
originally discussed:
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11

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

show more ...

[lldb] [Core] Split read thread support into ThreadedCommunication

Split the read thread support from Communication into a dedicated
ThreadedCommunication subclass. The read thread support is used

[lldb] [Core] Split read thread support into ThreadedCommunication

Split the read thread support from Communication into a dedicated
ThreadedCommunication subclass. The read thread support is used only
by a subset of Communication consumers, and it adds a lot of complexity
to the base class. Furthermore, having a dedicated subclass makes it
clear whether a particular consumer needs to account for the possibility
of read thread being running or not.

The modules currently calling `StartReadThread()` are updated to use
`ThreadedCommunication`. The remaining modules use the simplified
`Communication` class.

`SBCommunication` is changed to use `ThreadedCommunication` in order
to avoid changing the public API.

`CommunicationKDP` is updated in order to (hopefully) compile with
the new code. However, I do not have a Darwin box to test it, so I've
limited the changes to the bare minimum.

`GDBRemoteCommunication` is updated to become a `Broadcaster` directly.
Since it does not inherit from `ThreadedCommunication`, its event
support no longer collides with the one used for read thread and can
be implemented cleanly. The support for
`eBroadcastBitReadThreadDidExit` is removed from the code -- since
the read thread was not used, this event was never reported.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133251

show more ...

[lldb] Use nullptr instead of NULL (NFC)

Identified with modernize-use-nullptr.

[lldb] Remove a redundaunt return statement (NFC)

Identified with readability-redundant-control-flow.

[lldb] Remove uses of six module (NFC)

With lldb (& llvm) requiring Python 3.6+, use of the `six` module can be removed.

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