Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
$(LLDB_PYTHON_TESTSUITE_CC) defaults to the just-built clang. Together
with changes to the zorg repo, this enables the Green Dragon LLDB OS X
Xcode-based builder to run the new TSAN LLDB tests.
llvm-svn: 265315
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
This patch adds ThreadSanitizer support into LLDB:
- Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented.
- A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo.
- SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection.
- Added some test cases.
Reviewed by Greg Clayton.
llvm-svn: 264162
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
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
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
These files won't build for ios etc arm builds of lldb and aren't
used for macosx native lldb's.
http://reviews.llvm.org/D17750
<rdar://problem/24287153>
llvm-svn: 262566
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
This change restores the Xcode build to working after Makefile support
was stripped from LLVM and clang recently.
With this change, the Xcode build now requires cmake (2.8.12.2+).
The cmake must either be on the path that Xcode sees, or it must
exist in one of the following locations:
* /usr/local/bin/cmake
* /opt/local/bin/cmake
* $HOME/bin/cmake
If the ninja build tool is present on the path, it will be used.
If not, ninja will be cloned (via git), bootstrap-built, and
used for the llvm/clang build.
LLDB now requires a minimum deployment target of OS X 10.9. Prior
to this, it was 10.8. The llvm/clang cmake build will not run
with Xcode 7.2 or Xcode 7.3 beta's compiler with the minimum
deployment target set to anything lower than 10.9. This is
related to #include <atomic>.
When llvm or clang source code does not exist in the lldb tree,
it will be cloned via git using http://llvm.org/git/{project}.git.
Previously it used SVN. If this causes any heartache, we can
make this smarter, autodetect an embedded svn and use svn instead.
(And/or use SVN if a git command is not available).
This change also fixes an lldb-mi linkage failure (needed
libncurses) as exposed by one of the LLVM libs.
llvm-svn: 259027
The python test run target started failing recently.
I tracked it down to what looks like the passing of
environment variables into the python script.
This locally fixes the vast majority of errors that
were ultimately inferior test build command failures.
Not sure what caused that to start happening.
llvm-svn: 258585
A few files were accidentally added to the Copy Files build phase for our man
page, and they would appear when 'xcodebuild install' was invoked. This removes
those files – they continue to be built correctly, but they aren't installed
with our man page.
llvm-svn: 258194
The Green Dragon LLVM builders are starting to parse xunit output
on LLDB Xcode builders. By default the XML formatter treats
xpass (unexpected successes) as failures. The new flag added
ensures we simply ignore those for purposes of xUnit output.
LLDB is not currently XPASS clean.
llvm-svn: 257717
Most of the time CONFIGURATION_BUILD_DIR and BUILT_PRODUCTS_DIR are the same,
but they are different in 'xcodebuild install' situations. The file needs to be
put into BUILT_PRODUCTS_DIR or lldb's Python interface doesn't work when lldb is
built using 'xcodebuild install'.
llvm-svn: 257653
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
Split-dwarf uses a different header format to specify the address range
for the elements of the location lists.
Differential revision: http://reviews.llvm.org/D12880
llvm-svn: 247789
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
Summary:
This platform-specific code wasn't fully implemented and wasn't
actually needed. There was one call for the log file path and
that has been addressed.
This lets us also remove an error message from MICmnLogMediumFile
as it is no longer used.
Reviewers: ki.stfu, domipheus, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12764
llvm-svn: 247388
* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
where applicable
Differential revision: http://reviews.llvm.org/D12291
llvm-svn: 247132
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
Summary:
This also moves the xcode support files to be near or the same
as the ones used for cmake.
The source/API/liblldb.xcodes.exports differs from the
source/API/liblldb.exports in that one contains the actual
symbol names (_ prefixed) while the other contains the symbol
names as they are in the code. The liblldb.exports file is
preprocessed by the cmake scripts into the correct per-platform
file needed (like a linker script on Linux).
This is not enabled on Windows as Windows doesn't use the same
name mangling and so it won't be valid there. Also, this is handled
already in a different way on Windows (via dll exports).
Reviewers: emaste, clayborg, labath, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12599
llvm-svn: 246822
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things
llvm-svn: 246612
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246568
Sean Callanan