| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The NDK cmake toolchain file defines CMAKE_SYSTEM_NAME=Android, so switch the
build to use that. I have also updated the in-tree toolchain file to do that
(instead of defining __ANDROID_NDK__), so it can still be used to build.
After migrating the last bits of non-toolchainy bits out of the in-tree
toolchain, I intend to delete it.
Reviewers: tberghammer, danalbert
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D28775
llvm-svn: 292212
|
|
|
|
|
|
|
| |
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.
llvm-svn: 291500
|
|
|
|
|
|
| |
The logic for install rules was wrong for tools included in the framework if the framework build is disabled.
llvm-svn: 290934
|
|
|
|
|
|
|
|
| |
This patch adds the last bit of support to get LLVM_DISTRIBUTION_COMPONENTS working with libLLDB when built as a framework.
This patch adds dummy install targets for binaries built into the framework's Resources directory, and makes the framework's install target depend on all the binaries that get installed with the framework.
llvm-svn: 290273
|
|
|
|
|
|
| |
This resolves PR 31433.
llvm-svn: 290180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Patch by Pino Toscano. Reported in http://bugs.debian.org/835665
Reviewers: tfiala, emaste
Subscribers: beanz, mgorny, emaste, krytarowski, brucem, tberghammer, danalbert, srhines, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D23977
llvm-svn: 290044
|
|
|
|
|
|
| |
In LLVM's CMake we have a convention that components have both a build and an install target. Making LLDB follow this convention will allow LLDB to take advantage of the LLVM_DISTRIBUTION_COMPONENTS build option from LLVM.
llvm-svn: 289879
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there.
Reviewers: zturner, labath, abidh
Subscribers: ki.stfu, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27759
llvm-svn: 289821
|
|
|
|
| |
llvm-svn: 288673
|
|
|
|
|
|
| |
This is updating to take r288632 into account.
llvm-svn: 288633
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This replaces all the uses of the __ANDROID_NDK__ define with __ANDROID__. This
is a preparatory step to remove our custom android toolchain file and rely on
the standard android NDK one instead, which does not provide this define.
Instead I rely, on __ANDROID__, which is set by the compiler.
I haven't yet removed the cmake variable with the same name, as we will need to
do something completely different there -- NDK toolchain defines
CMAKE_SYSTEM_NAME to Android, while our current one pretends it's linux.
Reviewers: tberghammer, zturner
Subscribers: danalbert, srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27305
llvm-svn: 288494
|
|
|
|
|
|
| |
This is no longer an issue with recent versions of the android ndk.
llvm-svn: 288387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The fix is to make sure llvm does not pull in dlopen() in configurations where it
is not available.
Reviewers: tberghammer, beanz
Subscribers: danalbert, srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26505
llvm-svn: 288331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmortem) debugging. The minidump portion was replaced by a cross-platform
solution. This left the plugin split into a formerly "common" base classes and
the derived classes for live debugging. This extra layer made the code harder
to understand and work with.
This patch simplifies these class hierarchies by rolling the live debugging
concrete classes up to the base classes. Last week I posted my intent to make
this change to lldb-dev, and I didn't hear any objections.
This involved moving code and changing references to classes like
ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit,
and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before
this refactor for unrelated reasons.)
llvm-svn: 287770
|
|
|
|
|
|
| |
This patch updates a bunch of places where add_dependencies was being explicitly called to add dependencies on intrinsics_gen to instead use the DEPENDS named parameter. This cleanup is needed for a patch I'm working on to add a dependency debugging mode to the build system.
llvm-svn: 287408
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the cross-platform minidump plugin working, the Windows-specific one is no longer needed. This eliminates the unnecessary code.
This does not eliminate the Windows-specific tests, as they hit a few cases the general tests don't. (The Windows-specific tests are currently passing.) I'll look into a separate patch to make sure we're not doing too much duplicate testing.
After that I might do a little re-org in the Windows plugin, as there was some factoring there (Common & Live) that probably isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D26697
llvm-svn: 287113
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The dependencies of our libraries (only liblldb, really) we marked as public, which caused all
their dependencies to be repeated when linking any executables to them. This is a problem because
then all the .a files could end up being linked twice, once to liblldb and once
again to to the executable linking against liblldb (lldb, lldb-mi). As it turns out,
our build actually depends on this behavior:
- on windows, lldb does not have getopt, so it pulls it from inside liblldb, even
though getopt is not a part of the exported interface of liblldb (maybe some of
the bsd variants have this problem as well)
- lldb-mi uses llvm, which again is not exported by liblldb
This change does not actually fix these problems (that is going to be a hard
one), but it does make them explicit by moving this magic from add_lldb_library
to the places the executable targets are defined. That way, I can link the
additional .a files only on targets that really need it, and the other targets
can build cleanly and make sure we don't regress further. It also fixes the
LLVM_LINK_LLVM_DYLIB build on linux.
Reviewers: zturner, beanz
Subscribers: ki.stfu, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D25680
llvm-svn: 284466
|
|
|
|
|
|
|
|
| |
This code was adding an explicit dependency on libclang because lldb needs clang headers, changing this to instead depend on the clang tablegen targets means we don't have to depend on building the clang bits in libclang that lldb doesn't need.
Note this is still a bit of a hack because we're adding the dependency to all lldb libraries, instead of just the ones that need it.
llvm-svn: 282196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library.
With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow.
The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step.
With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up.
Reviewers: zturner, tfiala
Subscribers: beanz, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24749
llvm-svn: 282110
|
|
|
|
|
|
|
| |
LLVM now has a copy of libcxxabi demangler, so lldb doesn't need to
keep one too.
llvm-svn: 280821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a Minidump parsing code.
There are still some more structures/data streams that need to be added.
The aim ot this is to be used in the implementation of
a minidump debugging plugin that works on all platforms/architectures.
Currently we have a windows-only plugin that uses the WinAPI to parse
the dump files.
Also added unittests for the current functionality.
Reviewers: labath, amccarth
Subscribers: tberghammer, danalbert, srhines, lldb-commits, dschuff
Differential Revision: https://reviews.llvm.org/D23545
llvm-svn: 280356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously the builting demangler was on for platforms that explicitly set a flag by modifying
Mangled.cpp (windows, freebsd). The Xcode build always used builtin demangler by passing a
compiler flag. This adds a cmake flag (defaulting to ON) to configure the demangling library used
at build time. The flag is only available on non-windows platforms as there the system demangler
is not present (in the form we're trying to use it, at least).
The impact of this change is:
- linux: switches to the builtin demangler
- freebsd, windows: NFC (I hope)
- netbsd: switches to the builtin demangler
- osx cmake build: switches to the builtin demangler (matching the XCode build)
The main motivation for this is the cross-platform case, where it should bring more consistency
by removing the dependency on the host demangler (which can be completely unrelated to the debug
target).
Reviewers: zturner, emaste, krytarowski
Subscribers: emaste, clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D23830
llvm-svn: 279808
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r279296. Including LLDBDependencies breaks the
netbsd lldb bot because it exposes LLDB_USED_LIBS, which causes
lldb_link_common_libs to run to completion in unintended sites, which
results in a malformed call to target_link_libraries.
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/5989
Thanks to Chris Bieneman for figuring this out!
llvm-svn: 279322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's pulling in all kinds of things it doesn't need (e.g, clang-tidy!).
Eliminating this dependency removes 1056 dependencies from the
'CommandObjectFrame.cpp.o' target and 454 dependencies from the 'lldb'
target. On my machine, this shaves 7 minutes off of a clean build of
lldb.
Thanks to Zachary Turner for pointing out some issues with an earlier
version of this patch!
Differential Revision: https://reviews.llvm.org/D22987
llvm-svn: 279296
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8.
llvm-svn: 279200
|
|
|
|
|
|
|
|
|
| |
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279198
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Cmake 2.8 support is gone and not coming back. We can remove a bit of legacy code now.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23554
llvm-svn: 278924
|
|
|
|
|
|
|
|
| |
linking liblldb.so:
../include/llvm/Target/TargetOptions.h:104: error: undefined reference to 'llvm::TargetRecip::TargetRecip()'
llvm-svn: 277585
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces basic support for debugging OCaml binaries.
Use of the native compiler with DWARF emission support (see
https://github.com/ocaml/ocaml/pull/574) is required.
Available variables are considered as 64 bits unsigned integers,
their interpretation will be left to a OCaml-made debugging layer.
Differential revision: https://reviews.llvm.org/D22132
llvm-svn: 277443
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D22771
llvm-svn: 276814
|
|
|
|
|
|
|
|
|
| |
* include CheckAtomic to set HAVE_CXX_ATOMICS64_WITHOUT_LIB properly (introduced in r274121)
* hint Clang CMake files for LLVM CMake files location (inctroduced in ~ r274176)
Differential revision: https://reviews.llvm.org/D22322
llvm-svn: 275641
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary : The problem appears while linking liblldb.so. The class Address contain atomic variable m_offset. The loading and storing of variable is access via atomic_load_8 and atomic_store_8 functions. Some target fail to implicitly link libatomic, which cause undefine reference to atomic_store_8/atomic_load_8. This patch uses http://reviews.llvm.org/D20896 to check if libatomic need to be explicitly link.
Reviewed by labath.
Differential: D20464
llvm-svn: 274121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
One can still use the LLVM variables to control this: LLVM_ENABLE_EH, LLVM_ENABLE_RTTI. It's not
clear to me why one would want to control these at lldb level and it's generally not even a good
idea to compile parts of the same binary with different values of these flags.
Reviewers: zturner, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20673
llvm-svn: 270863
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Recent increase in the usage of std::weak_ptr has caused us to rediscover an issue in libstdc++
versions prior to 4.9 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656>, which make this class
unusable without exceptions in the presence of multiple threads. It's virtualy impossible to work
around this issue without implementing our own shared_ptr/weak_ptr substitutes, which does not
seem like a good idea.
Therefore, I am adding a big CMake warning which warns you about this issue if you're attempting
a to do a build which is suceptible to this problem and suggests possible alternatives. Right
now, nothing spectacular will happen if you ignore this warning (all the crashes I have seen
occur during process shutdown), but there's no guarantee the situation will not change in the
future.
Reviewers: tberghammer, tfiala, nitesh.jain, omjavaid, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20671
llvm-svn: 270854
|
|
|
|
|
|
|
|
| |
In the android-arm ndk there is a duplicated typedef in link.h
and in unwind.h causing build erros. This CL introduces a HACK
to prevent LLVM from finding unwind.h to fix the issue.
llvm-svn: 270201
|
|
|
|
|
|
|
|
|
|
| |
LLVM_INSTALL_TOOLCHAIN_ONLY=ON.
Fix standalone build with CMake 2.8.12.2.
Differential revision: http://reviews.llvm.org/D20344
llvm-svn: 269996
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Developed on NetBSD with pkgsrc.
Reviewers: zturner, labath
Subscribers: jevinskie, zturner, tfiala, Eugene.Zelenko, artagnon, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D15067
llvm-svn: 269332
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19991
llvm-svn: 268750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Building HEAD of LLDB fails in linking against DebugInfoPDB. It also prints the following warning:
```
CMake Warning (dev) in source/Plugins/SymbolFile/PDB/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
Target "lldbPluginSymbolFilePDB" has an INTERFACE_LINK_LIBRARIES property.
This should be preferred as the source of the link interface for this
library but because CMP0022 is not set CMake is ignoring the property and
using the link implementation as the link interface instead.
INTERFACE_LINK_LIBRARIES:
LLVMDebugInfoPDB
Link implementation:
(empty)
```
CMP0022 was introduced in CMake-2.8.11, bump minimal required version from 2.8 to 3.0 to gain more useful features like libexecinfo(3) detection on NetBSD.
Reviewers: emaste, zturner, labath
Subscribers: zturner, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D19685
llvm-svn: 268191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
|
|
|
|
| |
llvm-svn: 264168
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
|
|
|
|
|
|
|
|
|
| |
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
|
|
|
|
|
|
|
| |
This allows to find the LLVM's CMake files after moving them in
r259821.
llvm-svn: 259845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linking with LLVM shared libraries currently produces linker errors. This works around the issue
(pr24953) by disabling linking with llvm so for lldb libraries.
Patch by Evangelos Foutras.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16293
llvm-svn: 258921
|
|
|
|
|
|
|
|
|
|
| |
Some distributions of python have their version defined as follows in patchlevel.h (note the '+'):
#define PY_VERSION "2.7.9+"
The '+' char needs to be stripped by the cmake regex so that LLDBs python lib detection is successful.
Differential Revision: http://reviews.llvm.org/D15566
llvm-svn: 255893
|