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
This is fix for bug 23704: LLDB standalone build always include
ClangConfig.cmake even if Clang was built with LLVM (ClangConfig.cmake
doesn't exist).
Patch by: Eugene Zelenko
llvm-svn: 241575
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
Bruce Mitchener