Mac OS X 10.11, El Capitan, released c. Oct 2015) I conditionalized
the use of the framework on "if sdk == macosx 10.11". But since
macOS 10.12 has shipped this year, the framework was no longer being
built in. I can either start listing every OS 10.11 and newer, or
remove the version check.
This will break building lldb with xcodebuild / Xcode for people
running Mac OS X 10.10 or older. If so, I'll back this change out.
I'm not sure if we have many people working on macs running the
older OSes on their build systems.
<rdar://problem/30159130>
llvm-svn: 293742
lldb-gtest binary that xcode builds for -scheme lldb-gtest; these tests
won't run on macosx systems. Fixes testsuite failures we started
seeing after 290819.
<rdar://problem/29853778>
llvm-svn: 290917
Summary:
This class is unused, and since the StringRef refactor, it does not even
implement the Connection interface.
Reviewers: clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27134
llvm-svn: 288117
Summary:
All usages have been replaced by appropriate std::chrono funcionality, and the
class is now unused. The only used part of the cpp file is the DumpTimePoint
function, which I have moved into the only caller (CommandObjectTarget.cpp).
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D26451
llvm-svn: 287096
Since Xcode can't seem to handle quotes in preprocessor definitions, I've changed the build to assume that the define is unquoted. This should fix the failing Darwin bots.
llvm-svn: 286504
Summary:
This change unifies and simplifies the code paths between the Darwin and non-Darwin code to print the LLDB version information.
It also introduces a new variable in CMake LLDB_VERSION_STRING which can be used to specify custom version information. On Darwin this value is implicitly set based on the resource/LLDB-Info.plist file.
With the LLDB_VERSION_STRING variable set to lldb-360.99.0, the -version output is:
> ./bin/lldb -version
lldb version 4.0.0 (lldb-360.99.0)
clang revision 286264
llvm revision 286265
This behavior is unified across all target platforms.
Reviewers: lldb-commits
Subscribers: mgorny, tfiala
Differential Revision: https://reviews.llvm.org/D26478
llvm-svn: 286479
plan generator.
Fix a small bug in EmulateInstructionARM64::GetFramePointerRegister
which was returning the stack pointer reg instead of fp, prevented
the unwinder from recognizing the switch to using the fp in a
function. (<rdar://problem/28663117>)
Add a new eContextRestoreStackPointer context hint so that the arm64
emulator can flag when the frame pointer value is copied back in to
the stack pointer and that should be used to compute the canonical
frame address again in an epilogue sequence. (<rdar://problem/28704862>)
Small changes to UnwindAssemblyInstEmulation to have a method we can
call without a live process/thread/etc for unit tests.
<rdar://problem/28663117>
<rdar://problem/28704862>
<rdar://problem/28509178>
llvm-svn: 283847
Tests are failing and build is failing on windows and darwin.
Will fix and commit it later
-------------------------------------------------------------
Revert "xfailing minidump tests again ... :("
This reverts commit 97eade002c9e43c1e0d11475a4888083a8965044.
Revert "Fixing new Minidump plugin tests"
This reverts commit 0dd93b3ab39c8288696001dd50b9a093b813b09c.
Revert "Add the new minidump files to the Xcode project."
This reverts commit 2f638a1d046b8a88e61e212220edc40aecd2ce44.
Revert "xfailing tests for Minidump plugin"
This reverts commit 99311c0b22338a83e6a00c4fbddfd3577914c003.
Revert "Adding a new Minidump post-mortem debugging plugin"
This reverts commit b09a7e4dae231663095a84dac4be3da00b03a021.
llvm-svn: 283352
a linux bot test failure. That one is fixed; hopefully there won't
be any others turned up this time.
The eh_frame augmentation code wasn't working right after the
reorg/rewrite of the classes. It works correctly now for the one
test that was failing - but we'll see what the test bots come up
with.
<rdar://problem/28509178>
llvm-svn: 282659
This changes the Xcode target used by the Green Dragon Xcode CI.
When calling xcodebuild with LLDB_PYTHON_TESTSUITE_ARCH set, the
arch's xUnit XML output is now set to an arch-specific filename:
$(BUILD_DIR)/test-results-$(LLDB_PYTHON_TESTSUITE_ARCH).xml.
The change also ensures that the Python testsuite sees the Xcode
build settings passed in through environment variables.
llvm-svn: 282605
A testbot found a regression introduced in the testsuite with
the changes in r282565 on Ubuntu (TestStepNoDebug.ReturnValueTestCase).
I'll get this set up on an ubuntu box and figure out what is happening
there -- likely a problem with the eh_frame augmentation, which isn't
used on macosx.
llvm-svn: 282566
x86AssemblyInspectionEngine and the current UnwindAssembly_x86 to
allow for the core engine to be exercised by unit tests.
The UnwindAssembly_x86 class will have access to Targets, Processes,
Threads, RegisterContexts -- it will be working in the full lldb
environment.
x86AssemblyInspectionEngine is layered away from all of that, it is
given some register definitions and a bag of bytes to profile.
I wrote an initial unittest for a do-nothing simple x86_64/i386
function to start with. I'll be adding more.
The x86 assembly unwinder was added to lldb early in its bringup;
I made some modernization changes as I was refactoring the code
to make it more consistent with how we write lldb today.
I also added RegisterContextMinidump_x86_64.cpp to the xcode project
file so I can run the unittests from that.
The testsuite passes with this change, but there was quite a bit of
code change by the refactoring and it's possible there are some
issues. I'll be testing this more in the coming days, but it looks
like it is behaving correctly as far as I can tell with automated
testing.
<rdar://problem/28509178>
llvm-svn: 282565
This change adds support for the gtests that require input data
in the Inputs files. This is done through a new Xcode script
phase that runs the scripts/Xcode/prepare-gtest-run-dir.sh script.
That script simply copies the contents of all unittests/**/Inputs
dirs into ${TARGET_BUILD_DIR}/Inputs before running the test.
This change also renames the Xcode 'gtest-for-debugging' to
'gtest-build', and makes the gtest "build and run" target
depend on gtest-build. This reduces replication within the
targets. gtest .c/.cpp files now should only be added to
the gtest-build target.
llvm-svn: 281913
This Xcode build variable defaults to x86_64. It can be set to i386
to cause the lldb-python-test-suite target run the tests in the
specified architecture.
This flag is being added for the zorg build script so that Green Dragon
can run the test suite against both x86_64 and i386 macOS targets.
llvm-svn: 281639
The lldb-gtest target is for CI and runs the tests as
part of the build phase. It does not support debugging
the gtests from Xcode, though, due to the run happening
during the build phase.
This change adds a lldb-gtest-for-debugging target that
can be used to debug gtests.
llvm-svn: 279354
This change adds the Process/gdb-remote gtests to the Xcode
build. It also adds a virtual method impl to the continuation
delegate that I added with the StructuredDataPlugin change.
llvm-svn: 279203
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
Resumbitting the commit after fixing the following problems:
- broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F)
- the new code did not correctly handle the case where we went to interrupt the process, but it
stopped due to a different reason - the interrupt request would remain queued and would
interfere with the following "continue". I also added a unit test for this case.
This reapplies r277156 and r277139.
llvm-svn: 278118
This undoes my last commit. It collided with Pavel undoing
his change that my previous commit was adjusting for in the
Xcode file.
This reverts commit f6f29cb7d7c56f96f21d9c115ecc66d652639df3.
llvm-svn: 277157
The Green Dragon builder for macOS started failing yesterday with
session filenames that were too long. This change modifies the
Xcode target that runs the test suite and specifies a shorter
session filename format.
rdar://27539818
llvm-svn: 276760
for the fall (northern hemisphere) 2016 Darwin platforms to learn
about loaded images, instead of reading dyld internal data structures.
These new SPI don't exist on older releases, and new packets are
needed from debugserver to use them (those changes are already committed).
I had to change the minimum deployment target for debugserver in the xcode
project file to macOS 10.10 so that debugserver will use the
[[NSProcessInfo processInfo] operatingSystemVersion]
call in MachProcess::GetOSVersionNumbers to get the operarting system
version # -- this API is only available in macOS 10.10 and newer
("OS X Yosemite", released Oct 2014). If we have many people building
llvm.org lldb on older systems still, we can back off on this for the
llvm.org sources.
There should be no change in behavior with this commit, either to
older darwin systems or newer darwin systems.
For now the new DynamicLoader plugin is never activated - I'm forcing
the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI.
I'll remove that unconditional use of the old plugin soon, so the
newer plugin is used on the newest Darwin platforms.
<rdar://problem/25251243>
llvm-svn: 276254
a base class and a derived class, with the derived class containing
the methods specific to reading dyld's all_image_infos, dyld's
method of specifying images that have been loaded or unloaded, the
place where we put a breakpoint in dyld to get notified about newly
loaded or unloaded images.
This is in preparation for a second derived class which will use
some alternate methods for getting this information; that will be
a separate commit in the next few days.
There's a couple of ivars that should probably be in the derived
DyanmicLoaderMacOSX class instead of the base DynamicLoaderDarwin
class (m_dyld_image_infos, m_dyld_image_infos_stop_id). I don't
think I'll need to use these in the new derived class - I'll
move them down to DynamicLoaderMacOSX if it works out that way;
it'll simplify locking if I can do that.
<rdar://problem/25251243>
llvm-svn: 275733
$BUILT_PRODUCTS_DIR is usually the same as $CONFIGURATION_BUILD_DIR, but differs
when LLDB is being built BuildAndIntegration, in which case $BUILT_PRODUCTS_DIR
is more accurate.
llvm-svn: 275652
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
This change adds a new Xcode variable, LLDB_ENABLE_COVERAGE.
If set to 1, then the Xcode build will produce a clang
coverage-style build of LLDB. This can be done with a commandline
invocation such as:
xcodebuild -scheme desktop -configuration Debug build LLDB_ENABLE_COVERAGE=1
Alternatively, the variable can be locally modified from within Xcode
and built with the Xcode IDE.
llvm-svn: 273332
which doesn't like against all the extra UI frameworks on ios)
so it now generates a binary called "debugserver-nonui" and puts
it in /usr/local/bin instead of /Developer/usr/bin.
Add some cruft to RNBDefs.h to get the version number (provided
by Xcode at build time) with either the name "debugserver" or
"debugserver_nonui" as appropriate.
Add the "debugserver-mini" target to the top level "ios" target
in lldb xcode project file, so this nonui debugserver will be
built along with the normal lldb / debugserver.
<rdar://problem/24730789>
llvm-svn: 273236
Not sure what changed, but something outside our code
is failing one of the EditLine gtests on OS X CI (and
locally) before the gtest ever gets to run. This fails
the first EditLine gtest.
This change exports the TERM as "vt100" before running
the lldb-gtest binary, fixing the issue.
llvm-svn: 272844
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
Greg Clayton