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
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
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
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
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
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
Summary:
This approach is tunable with custom paths for curses library.
It also detects whether there are requirements met.
I make use of it on NetBSD.
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14529
llvm-svn: 253151
Summary:
These changes are still incomplete, but we are almost there.
Changes:
- CMake and gmake code
- SWIG code
- minor code additions
Reviewers: emaste, joerg
Subscribers: youri, akat1, brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14042
llvm-svn: 252403
Summary:
This breaks when using a symlink from llvm/tools/lldb to the lldb source
tree, instead of cloning directly as a child. With this change, we can
build properly, even when using links.
Reviewers: dawn, brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14089
llvm-svn: 251530
GCC produce a lot of strict-aliasing warning for the LLDB codebase
what makes reading the compile output very difficult. This change
disable these warnings to reduce the noise as we already ignore them.
We should consider re-enabling the warning if we fix all (or most)
strict-aliasing violation first.
Differential revision: http://reviews.llvm.org/D13981
llvm-svn: 251107
Newer versions of CMake include a "smarter" FindLibxml2 package.
In theory this is a good thing, but on Windows it's now smart
enough to find the version that comes with Gnuwin32, which doesn't
appear to be a valid libxml2 distribution. Or at the very least,
LLDB currently uses some header files from libxml2 that are not
part of this distribution.
Nobody on Windows is using any of this functionality right now
anyway, so just disable it.
llvm-svn: 250709
Adding the following flag to a cmake line:
-DLLDB_EXPORT_ALL_SYMBOLS=TRUE
will cause all symbols to be exported from liblldb. This enables the llvm
backtrace mechanism to see and report backtrace symbols properly when using
(lldb) log enable --stack ...
Prior to this change, only the SB API symbols would show up on Linux and other
systems that use a public-symbols-based backtrace lookup mechanism.
log enable --stack ... is a very handy, quick way to understand the flow
of how some log lines are getting hit within lldb without having to hook
up a top-level debugger over your current debug session.
llvm-svn: 250299
Summary:
Previously CMake would display messages like these:
```
-- LLDB Found PythonExecutable: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python_d.exe>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python.exe>
-- LLDB Found PythonLibs: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib>
-- LLDB Found PythonDLL: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python27_d.dll>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python27.dll>
```
This patch makes the messages look like this:
```
-- LLDB Found PythonExecutable: C:/Projects/Python-2.7.9-bin/x64/python.exe and C:/Projects/Python-2.7.9-bin/x64/python_d.exe
-- LLDB Found PythonLibs: C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib and C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib
-- LLDB Found PythonDLL: C:/Projects/Python-2.7.9-bin/x64/python27.dll and C:/Projects/Python-2.7.9-bin/x64/python27_d.dll
```
I've also added checks to ensure the messages are actually accurate, as in check that the files actually exist before claiming they've been found. If any of the files are missing Python integration will be disabled for the build.
Patch by Vadim Macagon. Thanks!
Reviewers: brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13520
llvm-svn: 249671
Summary:
Previously `CMAKE_BUILD_TYPE` was used to determine whether to link in `python27.lib` or `python27_d.lib`, unfortunately this only works reliably when using a CMake generator that generates a single build configuration (e.g. Ninja). The Visual Studio CMake generator generates four build configurations at once (`Debug`, `Release`, `RelWithDebInfo`, `MinSizeRel`), so if `CMAKE_BUILD_TYPE` is set to `Debug` all four build configurations end up linking in `python27_d.lib`, this is clearly undesirable.
To ensure that the correct Python lib is used for each build configuration the value of `PYTHON_LIBRARY` is now determined using generator expressions that evaluate to either the debug or release Python lib. The values of `PYTHON_EXECUTABLE` and `PYTHON_DLL` are now likewise determined using generator expressions.
Note that these changes only apply to the Windows build.
Patch by Vadim Macagon. Thanks!
Reviewers: zturner, brucem
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13234
llvm-svn: 248991
Summary:
This switches the decision as to whether or not to lldb-server should
be built to check the same flag that was added that controls whether
or not it is added as a dependency to the 'lldb' target.
It also sets that flag on FreeBSD to maintain parity with the existing
build configuration / situation on FreeBSD.
Reviewers: labath, emaste, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12925
llvm-svn: 247913
ninja lldb now does the following:
* forces the python post-build step to fire, which sets up the python lldb module properly.
* on Darwin and Linux, requires the lldb-server target to be built.
* on Darwin, requires the debugserver target to be built.
See http://reviews.llvm.org/D12899 for details.
llvm-svn: 247810
Summary:
This should be a mandatory build process going forward, if Python
is enabled. The longer term desire is to remove the old shell
scripts entirely.
Reviewers: zturner, clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12667
llvm-svn: 246979
Summary:
This was previously only established within debugserver, but
there is a use of the VLA extension in source/Host/macosx/Symbols.cpp,
so ignore this warning globally.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12515
llvm-svn: 246605
LLVM requires and handles this now and has the correct compiler
version checks. This block of code for cmake in LLDB is no longer
needed.
Summary: cmake no longer needs to deal with -std=c++11 checks.
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10994
llvm-svn: 241590
Summary:
Some old linux versions do not have process_vm_readv function defined. Even older versions do not
have even the __NR_process_vm_readv syscall number. We use cmake to detect these situations and
fallback appropriately: in the first case, we can issue the syscall manually, while it the latter
case, we need to drop fast memory read support completely.
Test Plan: linux test suite passes
Reviewers: ovyalov, Eugene.Zelenko
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10727
llvm-svn: 240927
Summary:
Several changes to fix CMake builds of LLDB with the
BUILD_SHARED_LIBS setting on.
- Force all internal libraries to be built STATIC.
- Add additional library dependencies (pthread, dl,
runtimedyld).
- modify finalisation of SWIG wrapper to symlink the
"lib" dir into python/site-packages, so _lldb.so's
RPATH resolves.
Test Plan: Verified one test case with "dotest.py".
Reviewers: sylvestre.ledru, zturner
Reviewed By: zturner
Subscribers: zturner, ted, tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10157
llvm-svn: 239007
This patch deprecates the three Python CMake variables in favor of
a single variable PYTHON_HOME which points to the root of a python
installation. Since building Python doesn't output the files in
a structure that is compatible with the PYTHONHOME environment
variable, we also provide a script install_custom_python.py which
will copy the output of a custom python build to the correct
directory structure.
The supported workflow after this patch will be to build python
once for each configuration and architecture {Debug,Release} x {x86,x64}
and then run the script. Then run CMake specifying -DPYTHON_HOME=<path>
The first time you do this will probably require you to delete your
CMake cache.
The old workflow is still supported during a transitionary period,
but a warning is printed at CMake time, and this will eventually
be removed.
Differential Revision: http://reviews.llvm.org/D8979
llvm-svn: 234660
Sigh. There's really not a good alternative until we decouple
python from lldb better. The only way the build works right now
is by having every executable link against every LLDB library.
This causes implicit transitive link dependencies on the union
of everything that LLDB brings in. Which means that if all we
want is one header file from interpreter, we have to bring in
everything, including everything that everything depends on,
which means python.
There's outstanding efforts to address this, but it's not yet
complete. So until then, this is all we can do.
llvm-svn: 232287
The existing state of affairs was getting a little unwieldy.
All of LLDB's utility functions and initial configuration was in
the root CMake file. I split this up into 3 separate files and
moved them to relevant subfolders under cmake/modules.
Also, I deleted the add_lldb_definitions() function. It seemed
to be somewhat useless and did not serve any real purpose that
I was able to figure out.
llvm-svn: 231010
Chris Bieneman