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

This can include objects that have complex state and need to be torn down intelligently (e.g. our SB* objects)

This will fail if the Python interpreter does not hold a valid thread state. So, acquire one, delete the session dictionary, and then let go of it on destruction

This fixes rdar://20960843

llvm-svn: 242745

There are other characters we could optimize for (any non-letter pretty much), but keyword.iskeyword() will handle them, whereas quotes do have the potential to confuse us, so they actually need custom handling

Fixes rdar://problem/21022787

llvm-svn: 239779

Summary:
There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix
we have in for this is not working all the time and is introducing unnecessary delays. This
change does:
- Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being
  confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to
  lldb-dev.
- coordinates printing of asynchronous text with the iohandlers. This is also based on a
  (different) Greg's patch, but I have added stronger synchronization to it to avoid races.

Together, these changes solve the prompt problem for me on linux (both with and without libedit).
I think they should behave similarly on Mac and FreeBSD and I think they will not make matters
worse for windows.

Test Plan: Prompt comes out alright. All tests still pass on linux.

Reviewers: clayborg, emaste, zturner

Subscribers: lldb-commits

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

llvm-svn: 238313

This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())

Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones

llvm-svn: 238286

Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.

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

llvm-svn: 237218

This patch deprecates the three Python CMake variables in favor of
a single variable PYTHON_HOME which points to the root of a python
installation.  Since building Python doesn't output the files in
a structure that is compatible with the PYTHONHOME environment
variable, we also provide a script install_custom_python.py which
will copy the output of a custom python build to the correct
directory structure.

The supported workflow after this patch will be to build python
once for each configuration and architecture {Debug,Release} x {x86,x64}
and then run the script.  Then run CMake specifying -DPYTHON_HOME=<path>

The first time you do this will probably require you to delete your
CMake cache.

The old workflow is still supported during a transitionary period,
but a warning is printed at CMake time, and this will eventually
be removed.

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

llvm-svn: 234660

Previously, users on Windows had to manually specify PYTHONPATH
to point to the site-packages directory before running LLDB.
The reason for this was because sys.path was being initialized
with a path containing unescaped backslashes, causing escape
sequences to end up in the paths.

llvm-svn: 234516

In an effort to reduce binary size for components not wishing to
link against all of LLDB, as well as a parallel effort to reduce
link dependencies on Python, this patch splits out the notion of
LLDB initialization into "full" and "common" initialization.

All code related to initializing the full LLDB suite lives directly
in API now.  Previously it was only referenced from API, but because
it was defined in lldbCore, it would get implicitly linked against
by everything including lldb-server, causing a considerable
increase in binary size.

By moving this to the API layer, it also creates a better layering
for the ongoing effort to make the embedded interpreter replacable
with one from a different language (or even be completely removeable).

One semantic change necessary to get this all working was to remove
the notion of a shared debugger refcount.  The debugger is either
initialized or uninitialized now, and calling Initialize() multiple
times will simply have no effect, while the first Terminate() will
now shut it down no matter how many times Initialize() was called.
This behaves nicely with all of our supported usage patterns though,
and allows us to fix a number of nasty hacks from before.

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

llvm-svn: 233758

This removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes.  To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*.  Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.

Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type.  For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes

The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.

llvm-svn: 232534