Add trace load functionality to SBDebugger via the `LoadTraceFromFile` method.
Update intelpt test case class to have `testTraceLoad` method so we can take advantage of
the testApiAndSB decorator to test both the CLI and SB without duplicating code.
Differential Revision: https://reviews.llvm.org/D128107
D120690 introduced `eBasicTypeChar8` but missed proper documentation order. This also introduces the missing bindings data on Swig, which should correspond with the documented information.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D116136
When using the `script` Python repl, SB objects are printed in a way that gives
the user no information. The simplest example is:
```
(lldb) script lldb.debugger
<lldb.SBDebugger; proxy of <Swig Object of type 'lldb::SBDebugger *' at 0x1097a5de0> >
```
This output comes from the Python repl printing the `repr()` of an object.
None of the SB classes implement `__repr__`, and all print like the above.
However, many (most?, all?) SB classes implement `__str__`. Because they
implement `__str__`, a more detailed output can be had by `print`ing the
object, for example:
```
(lldb) script print(lldb.debugger)
Debugger (instance: "debugger_1", id: 1)
```
For convenience, this change switches all SB classes that implement to
`__str__` to instead implement `__repr__`. **The result is that `str()` and
`repr()` will produce the same output**. This is because `str` calls `__repr__`
for classes that have no `__str__` method.
The benefit being that when writing a `script` invocation, you don't need to
remember to wrap in `print()`. If that isn't enough motivation, consider the
case where your Python expression results in a list of SB objects, in that case
you'd have to `map` or use a list comprehension like `[str(x) for x in <expr>]`
in order to see the details of the objects in the list.
For reference, the docs for `repr` say:
> repr(object)
> Return a string containing a printable representation of an object. For
> many types, this function makes an attempt to return a string that would
> yield an object with the same value when passed to eval(); otherwise, the
> representation is a string enclosed in angle brackets that contains the
> name of the type of the object together with additional information often
> including the name and address of the object. A class can control what this
> function returns for its instances by defining a __repr__() method.
and the docs for `__repr__` say:
> object.__repr__(self)
> Called by the repr() built-in function to compute the “official” string
> representation of an object. If at all possible, this should look like a
> valid Python expression that could be used to recreate an object with the
> same value (given an appropriate environment). If this is not possible, a
> string of the form <...some useful description...> should be returned. The
> return value must be a string object. If a class defines __repr__() but not
> __str__(), then __repr__() is also used when an “informal” string
> representation of instances of that class is required.
>
> This is typically used for debugging, so it is important that the
> representation is information-rich and unambiguous.
Even if it were convenient to construct Python expressions for SB classes so
that they could be `eval`'d, however for typical lldb usage, I can't think of a
motivating reason to do so. As it stands, the only action the docs say to do,
that this change doesn't do, is wrap the `repr` string in `<>` angle brackets.
An alternative implementation is to change lldb's python repl to apply `str()`
to the top level result. While this would work well in the case of a single SB
object, it doesn't work for a list of SB objects, since `str([x])` uses `repr`
to convert each list element to a string.
Differential Revision: https://reviews.llvm.org/D127458
This patch renames the `SBCompileUnit::GetIndexForLineEntry` api to be
an overload of `SBCompileUnit::FindLineEntryIndex`
Differential Revision: https://reviews.llvm.org/D125594
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new `GetIndexForLineEntry` method to the `SBCompileUnit`
class. As the name suggests, given an `SBLineEntry` object, this will
return the line entry index within a specific compile unit.
This method can take a `exact` boolean that will make sure that the
provided line entry matches perfectly another line entry in the compile unit.
rdar://47450887
Differention Revision: https://reviews.llvm.org/D125437
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enabling
this by default may be undesirable (libraries shouldn't be messing with
signal handlers), so make this an explicit opt-in.
I "commandeered" this patch from Jordan Rupprecht who put this up for
review originally.
Differential revision: https://reviews.llvm.org/D91835
Expose diagnostic events through the SB API. Unlike the progress events,
I opted to use a SBStructuredData so that we can add fields in the
future.
Differential revision: https://reviews.llvm.org/D121818
They don't require that the memory return address be restored prior to
function exit, so there's no guarantee the value is correct. It's better
to return nothing that something that's not accurate.
Differential Revision: https://reviews.llvm.org/D121348
Add `IsAggregateType` to the SB API.
I'd like to use this from tests, and there are numerous other `Is<X>Type`
predicates on `SBType`.
Differential Revision: https://reviews.llvm.org/D121252
This patch relands commit 3e3e79a9e4, and
fixes the memory sanitizer issue described in D120284, by removing the
output arguments from the LLDB_INSTRUMENT_VA invocation.
Differential Revision: https://reviews.llvm.org/D120599
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is a follow-up of D120100 to address some feedbacks from
@labath.
This should mainly fix the race issue with the even listener by moving
the listener setup to the main thread.
This also changes the SBDebugger::GetProgressFromEvent SWIG binding
arguments to be output only, so the user don't have to provide them.
Finally, this updates the test to check it the out arguments are returned
in a tuple and re-enables the test on all platforms.
Differential Revision: https://reviews.llvm.org/D120284
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch defines the SBDebugger::eBroadcastBitProgress enum in the SWIG
interface and exposes the SBDebugger::{GetProgressFromEvent,GetBroadcaster}
methods as well.
This allows to exercise the API from the script interpreter using python.
Differential Revision: https://reviews.llvm.org/D120100
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new type of ScriptedProcess: CrashLogScriptedProcess.
It takes advantage of lldb's crashlog parsers and Scripted Processes to
reconstruct a static debugging session with symbolicated stackframes, instead
of just dumping out everything in the user's terminal.
The crashlog command also has an interactive mode that only provide a
very limited experience. This is why this patch removes all the logic
for this interactive mode and creates CrashLogScriptedProcess instead.
This will fetch and load all the libraries that were used by the crashed
thread and re-create all the frames artificially.
rdar://88721117
Differential Revision: https://reviews.llvm.org/D119501
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds the ability for the user to check if the command
interpreter's IOHandler is interactive.
Differential Revision: https://reviews.llvm.org/D119499
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Update `__init__.py` generation to implement `__lldb_init_module`, which calls
`__lldb_init_module` on submodules that define it.
This allows the use case where a user runs `command script import lldb.macosx`.
With this change, the `__lldb_init_module` function in `crashlog.py` and
`heap.py` will be run, which is where command registration is occurring.
Differential Revision: https://reviews.llvm.org/D119179
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
This patch introduces a new SBAPI method: `SBModule::IsFileBacked`
As the name suggests, it tells the user if the module's object file is
on disk or in memory.
rdar://68538278
Differential Revision: https://reviews.llvm.org/D118261
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
It complements the existing SBDebugger::SetCurrentPlatformSDKRoot and
allows one to set the sysroot of a platform without making it current.
Differential Revision: https://reviews.llvm.org/D117550
Return our PythonObject wrappers instead of raw PyObjects (obfuscated as
void *). This ensures that ownership (reference counts) of python
objects is automatically tracked.
Differential Revision: https://reviews.llvm.org/D117462
The lldbconfig module was necessary to run the LLDB test suite against a
reproducer. Since this functionality has been removed, the module is no
longer necessary.
Unlike the rest of our SB objects, SBEvent and SBCommandReturnObject
have the ability to hold non-owning pointers to their non-SB
counterparts. This makes it hard to ensure the SB objects do not become
dangling once their backing object goes away.
While we could make these two objects behave like others, that would
require plubming even more shared pointers through our internal code
(Event objects are mostly prepared for it, CommandReturnObject are not).
Doing so seems unnecessarily disruptive, given that (unlike for some of
the other objects) I don't see any good reason why would someone want to
hold onto these objects after the function terminates.
For that reason, this patch implements a different approach -- the SB
objects will still hold non-owning pointers, but they will be reset to
the empty/default state as soon as the function terminates. This python
code will not crash if the user decides to store these objects -- but
the objects themselves will be useless/empty.
Differential Revision: https://reviews.llvm.org/D116162
This starts to fix the other half of the lifetime problems in this code
-- dangling references. SB objects created on the stack will go away
when the function returns, which is a problem if the python code they
were meant for stashes a reference to them somewhere. Most of the time
this goes by unnoticed, as the code rarely has a reason to store these,
but in case it does, we shouldn't respond by crashing.
This patch fixes the management for a couple of SB objects (Debugger,
Frame, Thread). The SB objects are now created on the heap, and
their ownership is immediately passed on to SWIG, which will ensure they
are destroyed when the last python reference goes away. I will handle
the other objects in separate patches.
I include one test which demonstrates the lifetime issue for SBDebugger.
Strictly speaking, one should create a test case for each of these
objects and each of the contexts they are being used. That would require
figuring out how to persist (and later access) each of these objects.
Some of those may involve a lot of hoop-jumping (we can run python code
from within a frame-format string). I don't think that is
necessary/worth it since the new wrapper functions make it very hard to
get this wrong.
Differential Revision: https://reviews.llvm.org/D115925
I've found my recent ventures into the swig land painful because
of the strange way they are formatted. This patch attempts to alleviate
future headaches by formatting these files into something resembling the
normal llvm style.
Unfortunately, completely formatting these files automatically does not
work because clang format gets confused by swigs % syntax, so I have
employed a hybrid approach where I formatted blocks of c++ code with
clang-format and then manually massaged the code until it looked
reasonable (and compiled).
I don't expect these files to remain perfectly formatted (although, if
one's editor is configured to configure the current line/block on
request, one can get pretty good results by using it judiciously), but
at least it will prevent the (mangled form of the) old lldb style being
proliferated endlessly.
Differential Revision: https://reviews.llvm.org/D115736
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
This patch introduces a new method to SBData: SetDataWithOwnership.
Instead of referencing the pointer to the data, this method copies the
data buffer into lldb's heap memory.
This can prevent having the underlying DataExtractor object point to
freed/garbage-collected memory.
Differential Revision: https://reviews.llvm.org/D115652
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Some pythons are configured to set platlib somewhere outside of their
sys.prefix. It's important that we at least use some reasonable
default for LLDB_PYTHON_RELATIVE_PATH even in that case, because
even if the user overrides it on the cmake invocation, cmake will
still be called without the override in order to build tablegen.
Reviewed By: JDevlieghere, clayborg
Differential Revision: https://reviews.llvm.org/D114973
The LLDBSWIGPython functions had (at least) two problems:
- There wasn't a single source of truth (a header file) for the
prototypes of these functions. This meant that subtle differences
in copies of function declarations could go by undetected. And
not-so-subtle differences would result in strange runtime failures.
- All of the declarations had to have an extern "C" interface, because
the function definitions were being placed inside and extert "C" block
generated by swig.
This patch fixes both problems by moving the function definitions to the
%header block of the swig files. This block is not surrounded by extern
"C", and seems more appropriate anyway, as swig docs say it is meant for
"user-defined support code" (whereas the previous %wrapper code was for
automatically-generated wrappers).
It also puts the declarations into the SWIGPythonBridge header file
(which seems to have been created for this purpose), and ensures it is
included by all code wishing to define or use these functions. This
means that any differences in the declaration become a compiler error
instead of a runtime failure.
Differential Revision: https://reviews.llvm.org/D114369
Right now if the LLDB is compiled under the windows with static vcruntime library, the -o and -k commands will not work.
The problem is that the LLDB create FILE* in lldb.exe and pass it to liblldb.dll which is an object from CRT.
Since the CRT is statically linked each of these module has its own copy of the CRT with it's own global state and the LLDB should not share CRT objects between them.
In this change I moved the logic of creating FILE* out of commands stream from Driver class to SBDebugger.
To do this I added new method: SBError SBDebugger::SetInputStream(SBStream &stream)
Command to build the LLDB:
cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;libcxx" -DLLVM_USE_CRT_RELEASE="MT" -DLLVM_USE_CRT_MINSIZEREL="MT" -DLLVM_USE_CRT_RELWITHDEBINFO="MT" -DP
YTHON_HOME:FILEPATH=C:/Python38 -DCMAKE_C_COMPILER:STRING=cl.exe -DCMAKE_CXX_COMPILER:STRING=cl.exe ../llvm
Command which will fail:
lldb.exe -o help
See discord discussion for more details: https://discord.com/channels/636084430946959380/636732809708306432/854629125398724628
This revision is for the further discussion.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104413
This diff is adding the capping_size determination for the list and forward list, to limit the number of children to be displayed. Also it modifies and unifies tests for libcxx and libstdcpp list data formatter.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D114433
Configuring lldb with `LLDB_ENABLE_PYTHON=OFF` and `LLDB_ENABLE_LUA=ON` results in a CMake error:
CMake Error at lldb/bindings/lua/CMakeLists.txt:47 (create_relative_symlink):
Unknown CMake command "create_relative_symlink".
Call Stack (most recent call first):
lldb/CMakeLists.txt:117 (finish_swig_lua)
This is because the CMake function `create_relative_symlink` only exists in `lldb/bindings/python/CMakeLists.txt`, and not in `lldb/bindings/lua/CMakeLists.txt`.
Move the function to `lldb/bindings/CMakeLists.txt`, so it is available for all language bindings.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114465
Using an lldb_private object in the bindings involves three steps
- wrapping the object in it's lldb::SB variant
- using swig to convert/wrap that to a PyObject
- wrapping *that* in a lldb_private::python::PythonObject
Our SBTypeToSWIGWrapper was only handling the middle part. This doesn't
just result in increased boilerplate in the callers, but is also a
functionality problem, as it's very hard to get the lifetime of of all
of these objects right. Most of the callers are creating the SB object
(step 1) on the stack, which means that we end up with dangling python
objects after the function terminates. Most of the time this isn't a
problem, because the python code does not need to persist the objects.
However, there are legitimate cases where they can do it (and even if
the use case is not completely legitimate, crashing is not the best
response to that).
For this reason, some of our code creates the SB object on the heap, but
it has another problem -- it never gets cleaned up.
This patch begins to add a new function (ToSWIGWrapper), which does all
of the three steps, while properly taking care of ownership. In the
first step, I have converted most of the leaky code (except for
SBStructuredData, which needs a bit more work).
Differential Revision: https://reviews.llvm.org/D114259
This file was way more complicated than it needed to be.
This patch removes the automagic reference-to-pointer delegation and
replaces the template specializations with regular free functions
(taking reference arguments).
The reason I chose references is twofold:
- there are more arguments being passed by reference than by pointer
- the reference arguments make it more obvious that there is a lot of
leaking going on in there.
Currently, the code was assuming that the pointer arguments have some
kind of a special meaning and that pointer functions take ownership of
their arguments, which isn't true (it's possible it was true at some
point in the past, I haven't done the archeology).
This makes it easier to implement proper lifetime management in
follow-up patches.
Differential Revision: https://reviews.llvm.org/D114150
distutils is deprecated and will be removed, so we shouldn't be
using it.
We were using it to compute LLDB_PYTHON_RELATIVE_PATH.
Discussing a similar issue
[at python.org](https://bugs.python.org/issue41282), Filipe Laíns said:
If you are relying on the value of distutils.sysconfig.get_python_lib()
as you shown in your system, you probably don't want to. That
directory (dist-packages) should be for Debian provided packages
only, so moving to sysconfig.get_path() would be a good thing,
as it has the correct value for user installed packages on your
system.
So I propose using a relative path from `sys.prefix` to
`sysconfig.get_path("platlib")` instead.
On Mac and windows, this results in the same paths as we had before,
which are `lib/python3.9/site-packages` and `Lib\site-packages`,
respectively.
On ubuntu however, this will change the path from
`lib/python3/dist-packages` to `lib/python3.9/site-packages`.
This change seems to be correct, as Filipe said above, `dist-packages`
belongs to the distribution, not us.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114106
see: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38387/console
```
Could not find a relative path to sys.executable under sys.prefix
tried: /usr/local/opt/python/bin/python3.7
tried: /usr/local/opt/python/bin/../Frameworks/Python.framework/Versions/3.7/bin/python3.7
sys.prefix: /usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7
```
It was unable to find LLDB_PYTHON_EXE_RELATIVE_PATH because it was not resolving
the real path of sys.prefix.
caused by: https://reviews.llvm.org/D113650
LLDB doesn't use only the python stable ABI, which means loading
it into an incompatible python can cause the process to crash.
_lldb.so should be named with the full EXT_SUFFIX from sysconfig
-- such as _lldb.cpython-39-darwin.so -- so this doesn't happen.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112972
Apparently "{sys.prefix}/bin/python3" isn't where you find the
python interpreter on windows, so the test I wrote for
-print-script-interpreter-info is failing.
We can't rely on sys.executable at runtime, because that will point
to lldb.exe not python.exe.
We can't just record sys.executable from build time, because python
could have been moved to a different location.
But it should be OK to apply relative path from sys.prefix to sys.executable
from build-time to the sys.prefix at runtime.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D113650
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
This patch changes the `ScriptedThread` initializer in couple of ways:
- It replaces the `SBTarget` parameter by a `SBProcess` (pointing to the
`ScriptedProcess` that "owns" the `ScriptedThread`).
- It adds a reference to the `ScriptedProcessInfo` Dictionary, to pass
arbitrary user-input to the `ScriptedThread`.
This patch also fixes the SWIG bindings methods that call the
`ScriptedProcess` and `ScriptedThread` initializers by passing all the
arguments to the appropriate `PythonCallable` object.
Differential Revision: https://reviews.llvm.org/D112046
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Currently calling SBType::IsTypeComplete returns true for record types if and
only if the underlying record in our internal Clang AST has a definition.
The function however doesn't actually force the loading of any external
definition from debug info, so it currently can return false even if the type is
actually defined in a program's debug info but LLDB hasn't lazily created the
definition yet.
This patch changes the behaviour to always load the definition first so that
IsTypeComplete now consistently returns true if there is a definition in the
module/target.
The motivation for this patch is twofold:
* The API is now arguably more useful for the user which don't know or care
about the internal lazy loading mechanism of LLDB.
* With D101950 there is no longer a good way to ask a Decl for a definition
without automatically pulling in a definition from the ExternalASTSource. The
current behaviour doesn't seem useful enough to justify the necessary
workarounds to preserve it for a time after D101950.
Note that there was a test that used this API to test lazy loading of debug info
but that has been replaced with TestLazyLoading by now (which just dumps the
internal Clang AST state instead).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D112615
Jakob Johnson