Summary:
Do not assume that liblldb.so is located in $(lldb -P)/../../../lib
when creating the _lldb python symlink. Instead, use the path passed
to LLVM_LIBDIR_SUFFIX, defaulting to $(lldb -P)/../../../lib when this
variable is not set.
Reviewers: vharron, emaste, zturner
Subscribers: zturner, labath, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19067
llvm-svn: 267462
This code was getting evaluated unintentionally at binding
generation time instead of binding file compilation time.
Addresses:
https://bugs.swift.org/browse/SR-1192
llvm-svn: 265829
We are using hardlinks instead of symlinks, and we attempted to
have some logic where we don't re-create the link if the target
file already exists. This logic is faulty, however, when you
manually delete the source file (e.g. liblldb.dll) and then rebuild
lldb so that a brand new liblldb.dll gets written. Now the two files
have different inodes, but the target exists, so we would not remake
the link and the target would become stale.
We fix this by only doing the optimization if they are really the
exact same file (by comparing inode numbers), and if they are not
the same file but the target exists, we delete it and re-create
the link.
llvm-svn: 263844
The swig typemaps had some magic for output File *'s on OS X that made:
SBDebugger.GetOutputFileHandle()
actually work. That was protected by a "#ifdef __MACOSX__", but the corresponding define
got lost going from the Darwin shell scripts to the python scripts for running
swig, so the code was elided. I need to pass the define to SWIG, but only when
targetting Darwin.
So I added a target-platform argument to prepare_bindings, and if that
is Darwin, I pass -D__APPLE__ to swig, and that activates this code again, and
GetOutputFileHandle works again. Note, I only pass that argument for the Xcode
build. I'm sure it is possible to do that for cmake, but my cmake-foo is weak.
I should have been able to write a test for this by creating a debugger, setting the
output file handle to something file, writing to it, getting the output file handle
and reading it. But SetOutputFileHandle doesn't seem to work from Python, so I'd
have to write a pexpect test to test this, which I'd rather not do.
llvm-svn: 263183
Summary:
This does not yet give us a clean testsuite run but it does help with:
1. Actually building on linux
2. Run the testsuite with over 70% tests passing on linux.
Reviewers: tfiala, labath, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17182
llvm-svn: 260721
The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless
Fixes rdar://24556976
llvm-svn: 260349
SBProcess::ReadMemory and other related functions such as
WriteMemory are returning Python string() objects. This means
that in Python 3 that are returning Unicode objects. In reality
they should be returning bytes objects which is the same as a string
in Python 2, but different in Python 3. This patch updates the
generated SWIG code to return Python bytes objects for all
memory related functions.
One quirk of this patch is that the C++ signature of ReadCStringFromMemory
has it writing c-string data into a void*. This confuses our swig
typemaps which expect that a void* means byte data. So I hacked up
a custom typemap which maps this specific function to treat the
void* as string data instead of byte data.
llvm-svn: 258743
This needs to be able to handle bytes, strings, and bytearray objects.
In Python 2 this was easy because bytes and strings are the same thing,
but in Python 3 the 2 cases need to be handled separately. So as not
to mix raw Python C API code with PythonDataObjects code, I've also
introduced a PythonByteArray class to PythonDataObjects to make the
paradigm used here consistent.
llvm-svn: 258741
We already have char** typemaps which were near copy-pastes of
the const char** versions. This way we have only one version that
works for both.
llvm-svn: 257670
There were a number of problems preventing this from working:
1. The SWIG typemaps for converting Python lists to and from C++
arrays were not updated for Python 3. So they were doing things
like PyString_Check instead of using the PythonString from
PythonDataObjects.
2. ProcessLauncherWindows was ignoring the environment completely.
So any test that involved launching an inferior with any kind
of environment variable would have failed.
3. The test itself was using process.GetSTDOUT(), which isn't
implemented on Windows. So this was changed to save the
value of the environment variable in a local variable and
have the debugger look at the value of the variable.
llvm-svn: 257669
* 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
Summary: If six.py is simlink'd, an installation won't be able to find it unless it has access to the source tree that lldb was built from.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15422
llvm-svn: 255340
This patch fixes two issues:
1) Popen needs to be used with universal_newlines=True by default.
This elicits automatic decoding from bytes -> string in Py3,
and has no negative effects in other Py versions.
2) The swig typemaps for converting between string and (char*, int)
did not work correctly when the length of the string was 0,
indicating an error. In this case we would try to construct a
string from uninitialized data.
3) Ironically, the bug mentioned in #2 led to a test passing on
Windows that was actually broken, because the test was written
such that the assertion was never even getting checked, so it
passed by default. So we additionally fix this test to also
fail if the method errors. By fixing this test it's now broken
on Windows, so we also xfail it.
llvm-svn: 253487
Added a new flag, --allow-static-binding. When specified,
if (and only if) the swig binary cannot be found, then the
LLDBWrapPython.cpp and lldb.py from the
scripts/Python/{static-binding-dir} are copied into the place where
swig would have generated them.
{static-binding-dir} defaults to static-binding, and can be
overridden with the --static-binding-dir command line argument.
The static bindings checked in are from r253424.
llvm-svn: 253448
This is only used by Xcode at the moment. It replaces the
buildSwigWrapperClasses.py and related per-script-language
scripts. It also fixes a couple bugs in those w/r/t Xcode
usage:
* the presence of the GCC_PREPROCESSOR_DEFINITIONS env var
should not be short-circuiting generation of the language
binding; rather, only if LLDB_DISABLE_PYTHON is present
within that environment variable.
* some logic around what to do when building in "non-Makefile"
mode. I've switched the handling of that to be on a
"--framework" flag - if specified, we build an OS X-style
framework; otherwise, we go with non.
Putting this up now only attached to the Xcode build so
others can look at it but not be affected by it yet.
After this, I'll tackle the finalizer, along with trying
it locally on Linux.
llvm-svn: 253317
Francis Ricci
Todd Fiala
Zachary Turner
Jim Ingham
Siva Chandra
Enrico Granata
Eugene Zelenko
Ted Woodward