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 no longer needed with --find-swig, and although innocuous on systems with
swig in the path, it blows up when there is no swig in the path. This should
have been removed in the prior check-in.
llvm-svn: 253353
The green dragon OS X builder doesn't have swig on the path.
I need to enable behavior where we can look for it
in some well known spots.
llvm-svn: 253319
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
This allows for command-line debugging of iOS simulator binaries (as long as UI is not required, or a full UI simulator has previously been otherwise launched), as well as execution of the LLDB test suite on the iOS simulator
This is known to compile on OSX 10.11 GM - feedback from people on other platforms and/or older versions of OSX as to the buildability of this code is greatly appreciated
llvm-svn: 252112
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
These are two simple tests that make sure single line and
multiline content are processed and received by Editline.cpp.
Fancier tests to come...
llvm-svn: 251681
Also added a placeholder Editline gtest for some code that I'll add as soon
as I make sure this addition doesn't break any of the build bots.
This change also introduces some Xcode user-defined variables that I've used
to attempt to isolate the way Python is integrated into the build. I don't have
the rest of LLDB using it yet, I'm using the gtests as my guinea pig on that.
Currently these are:
PYTHON_FRAMEWORK_PATH
PYTHON_VERSION_MAJOR
PYTHON_VERSION_MINOR
I will convert the rest over to it after this gets a little time to bake
and any kinks are worked out of it.
llvm-svn: 251261
I am also letting a debugserver-related project entry slide in
since Xcode seems to insist on inserting it, and when I remove it
the new files don't show up.
llvm-svn: 251243
make it easier to run hand-built lldb roots and retain those
entitlements. This is currently only used by Xcode; command
line lldb doesn't expose the SBLaunchInfo::SetUserID()
launch option.
<rdar://problem/23154486>
llvm-svn: 250981
The purpose of the class is to make it easy to execute tasks in parallel
Basic design goals:
* Have a very lightweight and easy to use interface where a list of
lambdas can be executed in parallel
* Use a global thread pool to limit the number of threads used
(std::async don't do it on Linux) and to eliminate the thread creation
overhead
* Destroy the thread currently not in use to avoid the confusion caused
by them during debugging LLDB
Possible future improvements:
* Possibility to cancel already added, but not yet started tasks
* Parallel for_each implementation
* Optimizations in the thread creation destroyation code
Differential revision: http://reviews.llvm.org/D13727
llvm-svn: 250820
A REPL takes over the command line and typically treats input as source code.
REPLs can also do code completion. The REPL class allows its subclasses to
implement the language-specific functionality without having to know about the
IOHandler-specific internals.
Also added a PluginManager-based way of getting to a REPL given a language and
a target.
Also brought in some utility code and expression options that are useful for
REPLs, such as line offsets for expressions, ANSI terminal coloring of errors,
and a few IOHandler convenience functions.
llvm-svn: 250753
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.
Reviewers: emaste, granata.enrico, jingham, clayborg
Differential Revision: http://reviews.llvm.org/D13290
llvm-svn: 249673
This is meant to support languages that can do some sort of bridging from<-->to these ObjC types via types that statically vend themselves as Cocoa types, but dynamically have an implementation that does not match any of our well-known types, but where an introspecting formatter can be vended by the bridged language
llvm-svn: 249185
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
Todd Fiala