Fix Python 3 issues related to OS plugins.

* lldb::tid_t was being converted incorrectly, so this is updated to use
PythonInteger instead of manual Python Native API calls.
* OSPlugin_RegisterContex

Fix Python 3 issues related to OS plugins.

* lldb::tid_t was being converted incorrectly, so this is updated to use
PythonInteger instead of manual Python Native API calls.
* OSPlugin_RegisterContextData was assuming that the result of
get_register_data was a string, when in fact it is a bytes. So this
method is updated to use PythonBytes to do the work.

llvm-svn: 257398

show more ...

Python 3 - Fix script import --allow-reload.

Differential Revision: http://reviews.llvm.org/D15209
Reviewed By: Todd Fiala

llvm-svn: 254791

Introduce a `PythonExceptionState` class.

This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception st

Introduce a `PythonExceptionState` class.

This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception state
upon scope exit.

Additionally, unit tests are included to verify the
feature set of the class.

llvm-svn: 252994

show more ...

[SBValue] Add a method GetNumChildren(uint32_t max)

Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added.

[SBValue] Add a method GetNumChildren(uint32_t max)

Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:

Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.

Reviewers: vharron, clayborg, granata.enrico

Subscribers: labath, lldb-commits

Differential Revision: http://reviews.llvm.org/D13778

llvm-svn: 250930

show more ...

Fix potential file i/o problem with python handles.

llvm-svn: 250838

Introduce a `PythonFile` object, and use it everywhere.

Python file handling got an overhaul in Python 3, and it affects
the way we have to interact with files. Notably:

1) `PyFile_FromFile` no lo

Introduce a `PythonFile` object, and use it everywhere.

Python file handling got an overhaul in Python 3, and it affects
the way we have to interact with files. Notably:

1) `PyFile_FromFile` no longer exists, and instead we have to use
`PyFile_FromFd`. This means having a way to get an fd from
a FILE*. For this we reuse the lldb_private::File class to
convert between FILE*s and fds, since there are some subtleties
regarding ownership rules when FILE*s and fds refer to the same
file.
2) PyFile is no longer a builtin type, so there is no such thing as
`PyFile_Check`. Instead, files in Python 3 are just instances
of `io.IOBase`. So the logic for checking if something is a file
in Python 3 is to check if it is a subclass of that module.

Additionally, some unit tests are added to verify that `PythonFile`
works as expected on Python 2 and Python 3, and
`ScriptInterpreterPython` is updated to use `PythonFile` instead of
manual calls to the various `PyFile_XXX` methods.

llvm-svn: 250444

show more ...

Make uses of /dev/null portable across OSes.

Most platforms have "/dev/null". Windows has "nul". Instead of
hardcoding the string /dev/null at various places, make a constant
that contains the cor

Make uses of /dev/null portable across OSes.

Most platforms have "/dev/null". Windows has "nul". Instead of
hardcoding the string /dev/null at various places, make a constant
that contains the correct value depending on the platform, and use
that everywhere instead.

llvm-svn: 250331

show more ...

Avoid a -Wreorder warning in ScriptInterpreterPython.cpp.

llvm-svn: 250322

Fix Python initialization for Python 3.

Python 3 reverses the order in which you must call Py_InitializeEx
and PyEval_InitThreads. Since that log is in itself already a
little nuanced, it is refact

Fix Python initialization for Python 3.

Python 3 reverses the order in which you must call Py_InitializeEx
and PyEval_InitThreads. Since that log is in itself already a
little nuanced, it is refactored into a function so that the reversal
is more clear. At the same time, there's a lot of logic during
Python initialization to save off a bunch of state and then restore
it after initialization is complete. To express this more cleanly,
it is refactored to an RAII-style pattern where state is saved off
on acquisition and restored on release.

llvm-svn: 250306

show more ...

Change swig interface files to use PythonDataObjects.

llvm-svn: 250303

Fix compiler warnings in ScriptInterpreterPython

llvm-svn: 250282

Change PyFile_FromFile to use PyFile_FromFd when using Py3.

llvm-svn: 250213

Fix ref counting of Python objects.

PythonObjects were being incorrectly ref-counted. This problem was
pervasive throughout the codebase, leading to an unknown number of memory
leaks and potentially

Fix ref counting of Python objects.

PythonObjects were being incorrectly ref-counted. This problem was
pervasive throughout the codebase, leading to an unknown number of memory
leaks and potentially use-after-free.

The issue stems from the fact that Python native methods can either return
"borrowed" references or "owned" references. For the former category, you
*must* incref it prior to decrefing it. And for the latter category, you
should not incref it before decrefing it. This is mostly an issue when a
Python C API method returns a `PyObject` to you, but it can also happen with
a method accepts a `PyObject`. Notably, this happens in `PyList_SetItem`,
which is documented to "steal" the reference that you give it. So if you
pass something to `PyList_SetItem`, you cannot hold onto it unless you
incref it first. But since this is one of only two exceptions in the
entire API, it's confusing and difficult to remember.

Our `PythonObject` class was indiscriminantely increfing every object it
received, which means that if you passed it an owned reference, you now
have a dangling reference since owned references should not be increfed.
We were doing this in quite a few places.

There was also a fair amount of manual increfing and decrefing prevalent
throughout the codebase, which is easy to get wrong.

This patch solves the problem by making any construction of a
`PythonObject` from a `PyObject` take a flag which indicates whether it is
an owned reference or a borrowed reference. There is no way to construct a
`PythonObject` without this flag, and it does not offer a default value,
forcing the user to make an explicit decision every time.

All manual uses of `PyObject` have been cleaned up throughout the codebase
and replaced with `PythonObject` in order to make RAII the predominant
pattern when dealing with native Python objects.

Differential Revision: http://reviews.llvm.org/D13617
Reviewed By: Greg Clayton

llvm-svn: 250195

show more ...

Fix build broken by r249885

llvm-svn: 249900

Port native Python-API to 3.x

With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x,

Port native Python-API to 3.x

With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:

1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.

Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.

llvm-svn: 249886

show more ...

Convert the ScriptInterpreter system to a plugin-based one.

Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a spe

Convert the ScriptInterpreter system to a plugin-based one.

Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.

This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.

Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.

Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton

llvm-svn: 243681

show more ...