| Age | Commit message (Collapse) | Author |
|---|
|
This is an alternative solution to the issue described in #167990, which
can be summarized as that we cannot target Python 3.8 with the stable
API and support building for Python 3.13 and later due to the buffer
protocol.
The approach taken in this PR, and proposed by Ismail, is to sidesteps
the issue by dropping support for the buffer protocol. The only two
users are SBFile::Read and SBFile::Write. Instead, we support PyBytes
and PyByteArray which are the builtin types that conform to the buffer
protocol. Technically, this means a small regression, where those
methods could previously take custom types that conform to Python's
buffer protocol. Like Ismail, I think this is acceptable given the
alternatives.
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
The minimum supported SWIG version is 4.0 so there's no need for using a
separate file anymore.
|
|
Reverts llvm/llvm-project#167808
|
|
The bug [1] this is working around was fixed in SWIG 4.1. The workaround
uses functions and constants that are not part of the limited API, which
I'm trying to eliminate to make LLDB compatible with the Python Limited
C API [2].
[1] https://github.com/swig/swig/issues/1640
[2] https://github.com/llvm/llvm-project/issues/151617
|
|
the function signature for `GetStopDescription` is
`lldb::SBThread::GetStopDescription(char *dst_or_null, size_t len)`.
To get a description you need to call the function first time to get the
buffer size. a second time to get the description.
This is little worse from the python size as the signature is
`lldb.SBThread.GetStopDescription(int: len) -> list[str]` the user has
to pass the max size as possible with no way of checking if it is
enough.
This patch adds a new api
`lldb.SBThread.GetStopDescription(desc: lldb.SBStream()) -> bool` `bool
lldb::SBThread::GetStopDescription(lldb::SBStream &description)` which
handles this case.
Adds new Test case for lua.
|
|
# Summary
`SBFileSpec::GetPath(char *dst_path, size_t dst_len)` contains `char*`
type argument. Need to handle this for python. Fortunately there're
already similar definitions we can reuse.
# Test Plan
Start the freshly built lldb and run the following code
```
$ lldb
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> debugger = lldb.SBDebugger.Create()
>>> debugger.SetAsync (False)
>>> target = debugger.CreateTarget("~/tmp/hello")
>>> target.IsValid()
True
>>> breakpoint = target.BreakpointCreateByName('main', 'hello')
>>> breakpoint.GetNumLocations()
1
>>> process = target.LaunchSimple (None, None, os.getcwd())
>>> process.IsValid()
True
>>> thread = process.GetThreadAtIndex(0)
>>> frame = thread.GetFrameAtIndex(0)
>>> line = frame.GetLineEntry()
# Important line below
>>> file = line.GetFileSpec().GetPath(1024)
# Important line above
>>> print(file)
/home/wanyi/tmp/main.cpp
```
## Before this change
```
$ lldb
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> debugger = lldb.SBDebugger.Create()
>>> debugger.SetAsync (False)
>>> target = debugger.CreateTarget("~/tmp/hello")
>>> target.IsValid()
True
>>> breakpoint = target.BreakpointCreateByName('main', 'hello')
>>> breakpoint.GetNumLocations()
1
>>> process = target.LaunchSimple (None, None, os.getcwd())
>>> process.IsValid()
True
>>> thread = process.GetThreadAtIndex(0)
>>> frame = thread.GetFrameAtIndex(0)
>>> line = frame.GetLineEntry()
>>> file = line.GetFileSpec().GetPath(1024)
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: SBFileSpec.GetPath() missing 1 required positional argument: 'dst_len'
>>> print(file)
Traceback (most recent call last):
File "<console>", line 1, in <module>
NameError: name 'file' is not defined
```
|
|
Xcode uses a pseudoterminal for the debugger console.
- The upside of this apporach is that it means that it can rely on
LLDB's IOHandlers for multiline and script input.
- The downside of this approach is that the command output is printed to
the PTY and you don't get a SBCommandReturnObject. Adrian added support
for inline diagnostics (#110901) and we'd like to access those from the
IDE.
This patch adds support for registering a callback in the command
interpreter that gives access to the `(SB)CommandReturnObject` right
before it will be printed. The callback implementation can choose
whether it likes to handle printing the result or defer to lldb. If the
callback indicated it handled the result, the command interpreter will
skip printing the result.
We considered a few other alternatives to solve this problem:
- The most obvious one is using `HandleCommand`, which returns a
`SBCommandReturnObject`. The problem with this approach is the multiline
input mentioned above. We would need a way to tell the IDE that it
should expect multiline input, which isn't known until LLDB starts
handling the command.
- To address the multiline issue,we considered exposing (some of the)
IOHandler machinery through the SB API. To solve this particular issue,
that would require reimplementing a ton of logic that already exists
today in the CommandInterpeter. Furthermore that seems like overkill
compared to the proposed solution.
rdar://141254310
|
|
This is a second attempt to land #95007
Test Plan:
llvm-lit
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py
Reviewers: clayborg
Tasks: lldb
|
|
Reverting to unblock macOS buildbots which are currently failing on
these tests.
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/6377/
|
|
Test Plan:
llvm-lit
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py
llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py
Reviewers: clayborg
Tasks: lldb
|
|
(#95181)
…andOverrideCallback (#94518)"
This reverts commit 7cff05ada05e87408966d56b4c1675033187ff5c. The API
test that was added erroneously imports a module that isn't needed and
wouldn't be found which causes a test failures. This reversion removes
that import.
|
|
SBCommandInterpreter::CommandOverrideCallback (#94518)"
This reverts commit 6fb6eba9304b63e86ebf039edcb9a0b32e4b39e7.
This test breaks due to an incorrect import in the test.
|
|
SBCommandInterpreter::CommandOverrideCallback (#94518)
`SBCommandInterpreter::CommandOverrideCallback` was not being exposed to
the Python API and has no coverage in the
API test suite, so this commits exposes and adds a test for it. Doing
this involves also adding a typemap for the callback used for this
function so that it matches the functionality of other callback
functions that are exposed to Python.
|
|
This patch replaces uses of StringRef::startswith with
StringRef::starts_with for consistency with
std::{string,string_view}::starts_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
|
|
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>
|
|
RFC https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580
Use SWIG for the locate module callback the same as other Python callbacks.
TestLocateModuleCallback.py verifies the functionalities.
Differential Revision: https://reviews.llvm.org/D153735
|
|
If we have a `%typemap(freearg)` that frees the argument, we shouldn't
free it manually on an error path before calling `SWIG_fail`.
`SWIG_fail` will already free the memory in this case, and doing it
manually results in a double free.
Differential Revision: https://reviews.llvm.org/D147007
|
|
Python 3 doesn't have a distinction between PyInt and PyLong, it's all
PyLong now.
This also fixes a bug in SetNumberFromObject. This used to crash LLDB:
```
lldb -o "script data=lldb.SBData(); data.SetDataFromUInt64Array([2**63])"
```
The problem happened in the PyInt path:
```
if (PyInt_Check(obj))
number = static_cast<T>(PyInt_AsLong(obj));
```
when obj doesn't fit in a signed long, `PyInt_AsLong` would fail with
"OverflowError: Python int too large to convert to C long".
The existing long path does the right thing, as it will call
`PyLong_AsUnsignedLongLong` for uint64_t.
Differential Revision: https://reviews.llvm.org/D146590
|
|
Adding a new SBDebugger::SetDestroyCallback() API.
This API can be used by any client to query for statistics/metrics before
exiting debug sessions.
Differential Revision: https://reviews.llvm.org/D143520
|
|
When using SBProcess::GetScriptedImplementation in python, if the
process has a valid implementation, we returned a reference of the
object without incrementing the reference counting. That causes the
interpreter to crash after accessing the reference several times.
This patch address this by incrementing the reference count when passing
the valid object reference.
Differential Revision: https://reviews.llvm.org/D145260
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
Instead of maintaining separate swig interface files, we can use the API
headers directly. They implement the exact same C++ APIs and we can
conditionally include the python extensions as needed. To remove the
swig extensions from the API headers when building the LLDB
framework, we can use the unifdef tool when it is available. Otherwise
we just copy them as-is.
Differential Revision: https://reviews.llvm.org/D142926
|
|
This patch introduces a new `GetScriptedImplementation` method to the
SBProcess class in the SBAPI. It will allow users of Scripted Processes to
fetch the scripted implementation object from to script interpreter to be
able to interact with it directly (without having to go through lldb).
This allows to user to perform action that are not specified in the
scripted process interface, like calling un-specified methods, but also
to enrich the implementation, by passing it complex objects.
Differential Revision: https://reviews.llvm.org/D143236
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
Fix the failure caused by change in SwigValueWraper for C++11 and later
for improved move semantics in SWIG commit.
https://github.com/swig/swig/commit/d1055f4b3d51cb8060893f8036846ac743302dab
|
|
When attempting to use SWIG's `-builtin` flag, there were a few compile
failures caused by a mismatch between return type and return value. In those
cases, the return type was `int` but many of the type maps assume returning
`NULL`/`nullptr` (only the latter caused compile failures).
This fix abstracts failure paths to use the `SWIG_fail` macro, which performs
`goto fail;`. Each of the generated functions contain a `fail` label, which
performs any resource cleanup and returns the appropriate failure value.
This change isn't strictly necessary at this point, but seems like the right
thing to do, and for anyone who tries `-builtin` later, it resolves those
issues.
Differential Revision: https://reviews.llvm.org/D133961
|
|
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
|
|
`struct Py_buffer_RAII` definition uses explicit deleted functions which are not supported by SWIG 2 (only 3).
To get around this I moved this struct to an .h file that is included to avoid being parsed by swig.
Reviewed By: lawrence_danna
Differential Revision: https://reviews.llvm.org/D86381
|
|
This was reverted due to a python2-specific bug. Re-landing with a fix
for python2.
Summary:
One small step in my long running quest to improve python exception handling in
LLDB. Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn, omjavaid
Reviewed By: labath, omjavaid
Subscribers: omjavaid, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78462
|
|
This reverts commit 7375212172951d2fc283c81d03c1a8588c3280c6.
This causes multiple test failures on LLDB AArch64 Linux buildbot.
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/3695
Differential Revision: https://reviews.llvm.org/D78462
|
|
Summary:
One small step in my long running quest to improve python exception handling in
LLDB. Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78462
|
|
Summary:
The buffer protocol does not allow us to just call PyBuffer_Release
and assume the buffer will still be there. Most things that implement the
buffer protocol will let us get away with that, but not all. We need
to release it at the end of the SWIG wrapper.
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77480
|
|
uninitialized memory at the end.
Summary:
`SBThread.GetStopDescription` is a curious API as it takes a buffer length as a parameter that specifies
how many bytes the buffer we pass has. Then we fill the buffer until the specified length (or the length
of the stop description string) and return the string length. If the buffer is a nullptr however, we instead
return how many bytes we would have written to the buffer so that the user can allocate a buffer with
the right size and pass that size to a subsequent `SBThread.GetStopDescription` call.
Funnily enough, it is not possible to pass a nullptr via the Python SWIG bindings, so that might be the
first API in LLDB that is not only hard to use correctly but impossible to use correctly. The only way to
call this function via Python is to throw in a large size limit that is hopefully large enough to contain the
stop description (otherwise we only get the truncated stop description).
Currently passing a size limit that is smaller than the returned stop description doesn't cause the
Python bindings to return the stop description but instead the truncated stop description + uninitialized characters
at the end of the string. The reason for this is that we return the result of `snprintf` from the method
which returns the amount of bytes that *would* have been written (which is larger than the buffer).
This causes our Python bindings to return a string that is as large as full stop description but the
buffer that has been filled is only as large as the passed in buffer size.
This patch fixes this issue by just recalculating the string length in our buffer instead of relying on the wrong
return value. We also have to do this in a new type map as the old type map is also used for all methods
with the given argument pair `char *dst, size_t dst_len` (e.g. SBProcess.GetSTDOUT`). These methods have
different semantics for these arguments and don't null-terminate the returned buffer (they instead return the
size in bytes) so we can't change the existing typemap without breaking them.
Reviewers: labath, jingham
Reviewed By: labath
Subscribers: clayborg, shafik, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72086
|
|
All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.
I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.
Differential revision: https://reviews.llvm.org/D72437
|
