History log of /llvm-project-15.0.7/lldb/bindings/python/python-typemaps.swig (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2
# 392963bb 21-Sep-2022 Jitka Plesnikova <[email protected]>

[lldb] Fix 'error: non-const lvalue...' caused by SWIG 4.1.0

Fix the failure caused by change in SwigValueWraper for C++11 and later
for improved move semantics in SWIG commit.

https://github.com/s

[lldb] Fix 'error: non-const lvalue...' caused by SWIG 4.1.0

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
(cherry picked from commit f0a25fe0b746f56295d5c02116ba28d2f965c175)

show more ...


Revision tags: llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2
# 9d5e37ed 14-Dec-2021 Pavel Labath <[email protected]>

[lldb] (Semi-automatically) format .swig files

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 headach

[lldb] (Semi-automatically) format .swig files

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

show more ...


Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3
# 5d8eedee 22-Aug-2020 António Afonso <[email protected]>

Move Py_buffer_RAII to .h file so SWIG 2 doesnt have to parse it

`struct Py_buffer_RAII` definition uses explicit deleted functions which are not supported by SWIG 2 (only 3).
To get around this I m

Move Py_buffer_RAII to .h file so SWIG 2 doesnt have to parse it

`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

show more ...


Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1
# 52712d3f 08-May-2020 Lawrence D'Anna <[email protected]>

Re-land "get rid of PythonInteger::GetInteger()"

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 pyt

Re-land "get rid of PythonInteger::GetInteger()"

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

show more ...


# 478619cf 22-Apr-2020 Muhammad Omair Javaid <[email protected]>

Revert "get rid of PythonInteger::GetInteger()"

This reverts commit 7375212172951d2fc283c81d03c1a8588c3280c6.

This causes multiple test failures on LLDB AArch64 Linux buildbot.
http://lab.llvm.org:

Revert "get rid of PythonInteger::GetInteger()"

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

show more ...


# 73752121 21-Apr-2020 Lawrence D'Anna <[email protected]>

get rid of PythonInteger::GetInteger()

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 lon

get rid of PythonInteger::GetInteger()

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

show more ...


# c8de17bc 07-Apr-2020 Lawrence D'Anna <[email protected]>

Fix illegal early call to PyBuffer_Release in swig typemaps

Summary:
The buffer protocol does not allow us to just call PyBuffer_Release
and assume the buffer will still be there. Most things that

Fix illegal early call to PyBuffer_Release in swig typemaps

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

show more ...


Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init
# 61b6a4e8 14-Jan-2020 Raphael Isemann <[email protected]>

[lldb] Fix that SBThread.GetStopDescription is returning strings with uninitialized memory at the end.

Summary:
`SBThread.GetStopDescription` is a curious API as it takes a buffer length as a parame

[lldb] Fix that SBThread.GetStopDescription is returning strings with 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

show more ...


# 6498aff2 09-Jan-2020 Jonas Devlieghere <[email protected]>

[lldb/Bindings] Move bindings into their own subdirectory

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

[lldb/Bindings] Move bindings into their own subdirectory

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

show more ...