summaryrefslogtreecommitdiffstats
path: root/lldb/cmake
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/CMake] Only auto-enable Lua when SWIG is foundJonas Devlieghere2020-01-082-1/+32
| | | | | | Just like Python, Lua should only be auto-enabled if SWIG is found as well. This moves the logic of finding SWIG and Lua as a whole into a new CMake package.
* [lldb/CMake] Use LLDB's autodetection logic for libxml2Jonas Devlieghere2020-01-081-12/+15
| | | | | | | Libxml2 is already an optional dependency. It should use the same infrastructure as the other dependencies. Differential revision: https://reviews.llvm.org/D72290
* [lldb/CMake] Only auto-enable Python when SWIG is foundJonas Devlieghere2020-01-071-29/+37
| | | | | | | | | As correctly pointed out by Martin on the mailing list, Python should only be auto-enabled if SWIG is found as well. This moves the logic of finding SWIG into FindPythonInterpAndLibs to make that possible. To make diagnosing easier I've included a status message to convey why Python support is disabled.
* [lldb/CMake] Only set PYTHON_HOME on WindowsJonas Devlieghere2020-01-061-1/+1
| | | | | | My earlier change for Python auto-detection caused PYTHON_HOME to be set unconditionally, while before the change this only happened for Windows. This caused the PythonDataObjectsTest to fail with an import error.
* [lldb/CMake] Autodetect Python dependencyJonas Devlieghere2020-01-062-48/+56
| | | | | | | | Python was the last remaining "optional" dependency for LLDB. This moves the code to find Python into FindPythonInterpAndLibs using the same principles as FindCursesAndPanel. Differential revision: https://reviews.llvm.org/D72107
* [lldb/CMake] Print whether an optional dependency was enabled.Jonas Devlieghere2020-01-021-5/+7
| | | | | | Use a status message to convey whether an optional dependency was found or not. With the auto-detection code it's not longer as simple as checking the CMake cache.
* [lldb/CMake] Fix variable naming in FindLibEditJonas Devlieghere2020-01-022-19/+21
| | | | | | | | | | | | The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by find_package_handle_standard_args. However this isn't valid for the package name. The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and "LIBEDIT_FOUND" are valid names. This fixes all the variables set by FindLibEdit to match the desired naming scheme.
* [lldb/CMake] Use PYTHON_LIBRARIES instead of PYTHON_LIBRARYJonas Devlieghere2020-01-021-2/+2
| | | | | | PYTHON_LIBRARIES is the canonical variable set by FindPythonLibs while PYTHON_LIBRARY is an implementation detail. This replaces the uses of the latter with the former.
* [lldb/CMake] Always set a value for find_package when finding optional ↵Alex Langford2019-12-231-0/+1
| | | | | | | | | dependencies Because this is a macro, previous values of `find_package` persist between calls. This means that if it is set to TRUE on any run, all subsequent runs will have find_package set to TRUE regardles of whether or not they should be.
* build: use `find_package(Python3)` rather than `PYTHON_HOME`Saleem Abdulrasool2019-12-221-0/+1
| | | | | | The behaviour of `PYTHON_HOME` can be emulated by setting `Python3_EXECUTABLE` to the absolute path instead of the custom variable now that we can find the python interpreter.
* build: improve python checks for WindowsSaleem Abdulrasool2019-12-221-167/+22
| | | | | | | | Require a newer CMake on Windows to use the Python3 support that is packaged in CMake. This version is able to check both 32-bit and 64-bit versions and will setup everything properly without the user needing to specify PYTHON_HOME. This enables building lldb's python bindings on Windows under Azure's CI again.
* [lldb/CMake] Don't use return() from macro()Jonas Devlieghere2019-12-201-4/+7
| | | | | | | | | > A macro is executed as if the macro body were pasted in place of the > calling statement. This has the consequence that a return() in a macro > body does not just terminate execution of the macro After converting from a function() to a macro(), the return() became invalid. This modifies the control flow to elude the return.
* Re-land "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-202-44/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* Revert "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-202-46/+44
| | | | This is failing on both the Windows and Debian bot.
* [lldb/CMake] Change how we deal with optional dependenciesJonas Devlieghere2019-12-202-44/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* [lldb/Lua] Implement a Simple Lua Script Interpreter PrototypeJonas Devlieghere2019-12-201-0/+3
| | | | | | | | | | | | | | | This implements a very elementary Lua script interpreter. It supports running a single command as well as running interactively. It uses editline if available. It's still missing a bunch of stuff though. Some things that I intentionally ingored for now are that I/O isn't properly hooked up (so every print goes to stdout) and the non-editline support which is not handling a bunch of corner cases. The latter is a matter of reusing existing code in the Python interpreter. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71234
* [lldb/cmake] Delete LLDB_LINKER_SUPPORTS_GROUPSPavel Labath2019-12-201-6/+0
| | | | The variable is unused.
* [lldb/cmake] Remove support for LLDB_DISABLE_CURSESPavel Labath2019-12-201-6/+1
| | | | The buildbot which necessitated this is fixed.
* [lldb/Lua] Add Boilerplate for a Lua Script InterpreterJonas Devlieghere2019-12-191-0/+4
| | | | | | | | | | | This adds the boilerplate necessary to support the Lua script interpreter. The interpreter is not functional yet and just reports that it's not implemented. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71232
* [lldb/CMake] Initialize LLDB_ENABLE_POSIX based on the UNIX variable.Jonas Devlieghere2019-12-131-1/+5
|
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-131-18/+21
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_POSIXJonas Devlieghere2019-12-131-3/+1
| | | | | Rename LLDB_DISABLE_POSIX to LLDB_ENABLE_POSIX and use cmakedefine01 for consistency.
* [lldb/cmake] Temporarily revive LLDB_DISABLE_CURSESPavel Labath2019-12-131-2/+11
| | | | | | | | | At least one lldb bot still uses this cmake variable instead of LLDB_ENABLE_CURSES. Add code to set the default value of the "enable" variable based on the old value of the "disable" setting. This should bring those bots back up, until we can update the master to use the new setting.
* [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_TERMIOSJonas Devlieghere2019-12-121-1/+1
| | | | | | | This renames LLDB_CONFIG_TERMIOS_SUPPORTED to LLDB_ENABLE_TERMIOS. It now also uses cmakedefine01 to keep things consistent with out other optional dependencies. But more importantly it won't silently fail when you forget to include Config.h.
* [lldb/CMake] Rename LLDB_DISABLE_LIBEDIT to LLDB_ENABLE_LIBEDITJonas Devlieghere2019-12-121-5/+5
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71380
* [lldb/CMake] Rename LLDB_DISABLE_CURSES to LLDB_ENABLE_CURSESJonas Devlieghere2019-12-121-5/+5
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71377
* [lldb/CMake] Simplify linking against cursesJonas Devlieghere2019-12-111-8/+0
| | | | | | Centralize the logic to determine what libraries to link against for curses in the CMake file where it is actually being used. Use target_include_directories instead of include_directories.
* [lldb/Host] Use Host/Config.h for LibXML2 instead of a global defineJonas Devlieghere2019-12-111-3/+2
| | | | | Rename LIBXML2_DEFINED to LLDB_ENABLE_LIBXML2 and pass it through Config.h instead of a global define.
* [lldb/Host] Use Host/Config.h entries instead of a global define.Jonas Devlieghere2019-12-101-8/+1
| | | | | | | | | | | As suggested by Pavel in a code review: > Can we replace this (and maybe python too, while at it) with a > Host/Config.h entry? A global definition means that one has to > recompile everything when these change in any way, whereas in > practice only a handful of files need this.. Differential revision: https://reviews.llvm.org/D71280
* Revert "[CMake] Re-enable -Wno-gnu-anonymous-struct & -Wno-nested-anon-types."Jonas Devlieghere2019-11-181-12/+0
| | | | Whoops, they should be enabled, not disabled.
* [CMake] Re-enable -Wno-gnu-anonymous-struct & -Wno-nested-anon-types.Jonas Devlieghere2019-11-181-0/+6
| | | | | | We're checking for support but we're discarding the result. My best guess is that these warnings were disabled in the past. However, I don't see a reason to keep it that way.
* [LLDB] Remove debug message in AddLLDB.cmakeJonas Devlieghere2019-11-121-1/+0
|
* [LLDB] Fix/silence CMake developer warning for LLDB framework.Jonas Devlieghere2019-11-121-1/+9
| | | | | | | | | | | | This fixes the following warning for developers: Target 'liblldb' was changed to a FRAMEWORK sometime after install(). This may result in the wrong install DESTINATION. Set the FRAMEWORK property earlier. The solution is to pass the FRAMEWORK flag to add_lldb_library and set the target property before install(). For now liblldb is the only customer.
* [LLDB] Always remove debugserver from LLVM_DISTRIBUTION_COMPONENTSJonas Devlieghere2019-11-121-0/+9
| | | | | | Centralize the logic to remove debugserver from LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is enabled. Now this happens regardless of whether the tests are enabled.
* Add rpath to liblldb so vendors can ship their own python framework (or others)António Afonso2019-11-111-0/+5
| | | | | | | | | | | | | | | | | Summary: I want to be able to specify which python framework to use for lldb in macos. With python2.7 we could just rely on the MacOS one but python3.7 is not shipped with the OS. An alternative is to use the one shipped with Xcode but that could be path dependent or maybe the user doesn't have Xcode installed at all. A definite solution is to just ship a python framework with lldb. To make this possible I added "@loader_path/../../../" to the rpath so it points to the same directory as the LLDB.framework, this way we can just drop any frameworks there. Reviewers: hhb, sgraenitz, xiaobai, smeenai, beanz, labath Reviewed By: labath Subscribers: beanz, labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69931
* [lldb] Record framework build path and use it everywhereHaibo Huang2019-11-063-13/+9
| | | | This avoids config time dependencies on liblldb. And enables other refactoring.
* [cmake] Add an option to skip stripping before installVedant Kumar2019-11-042-7/+10
| | | | | | The swift build system has support for cross-compiling, installing, and generating symbols for lldb. As the swift symbol-generation step occurs after installation, we need to disable stripping during the install.
* [CMake] Move test dependency tracking into test/CMakeLists.txtJonas Devlieghere2019-10-241-6/+0
| | | | | | As the name suggests, the LLDB test dependencies only matter to the different test suites. Therefore they belong in test/CMakeLists.txt rather than the top-level CMakeLists.txt.
* [CMake] Make it possible to set the RPATH in add_lldb_exectable.Jonas Devlieghere2019-10-171-2/+15
| | | | | | | | | | | | | | Make it possible to pass a build and install RPATH to add_lldb_executable instead of having to call lldb_setup_rpaths after the fact. This fixes a real issue where setting an install RPATH with lldb_setup_rpaths would only affect the symroot installation component. Given that lldb_setup_rpaths sets a target property I would expect this to be orthogonal to installation components. Regardless, it makes sense to integrate this functionality in add_lldb_exectable. llvm-svn: 375068
* [CMake] Fix add_lldb_test_dependencyJonas Devlieghere2019-10-091-2/+4
| | | | | | | This function would ignore all but the first argument. Now it correctly adds every dependency by iterating over its arguments. llvm-svn: 374216
* [CMake] Fix building without python on WindowsAlex Langford2019-10-081-2/+7
| | | | | | | | Summary: find_python_libs_windows might set LLDB_DISABLE_PYTHON to ON. Unfortunately we do not re-check this variable before using variables filled in by find_python_libs_windows, leading to a failed configuration. llvm-svn: 374100
* [CMake] Track test dependencies with add_lldb_test_dependencyJonas Devlieghere2019-10-081-0/+4
| | | | | | | | | | | | | I often use `ninja lldb-test-deps` to build all the test dependencies before running a subset of the tests with `lit --filter`. This functionality seems to break relatively often because test dependencies are tracked in an ad-hoc way acrooss cmake files. This patch adds a helper function `add_lldb_test_dependency` to unify test dependency tracking by adding dependencies to lldb-test-deps. Differential revision: https://reviews.llvm.org/D68612 llvm-svn: 373996
* [CMake] We only want to copy the headers for macOS.Davide Italiano2019-10-071-0/+2
| | | | | | <rdar://problem/55916729> llvm-svn: 373970
* [lldb][ELF] Read symbols from .gnu_debugdata sect.Konrad Kleine2019-10-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the .symtab section is stripped from the binary it might be that there's a .gnu_debugdata section which contains a smaller .symtab in order to provide enough information to create a backtrace with function names or to set and hit a breakpoint on a function name. This change looks for a .gnu_debugdata section in the ELF object file. The .gnu_debugdata section contains a xz-compressed ELF file with a .symtab section inside. Symbols from that compressed .symtab section are merged with the main object file's .dynsym symbols (if any). In addition we always load the .dynsym even if there's a .symtab section. For example, the Fedora and RHEL operating systems strip their binaries but keep a .gnu_debugdata section. While gdb already can read this section, LLDB until this patch couldn't. To test this patch on a Fedora or RHEL operating system, try to set a breakpoint on the "help" symbol in the "zip" binary. Before this patch, only GDB can set this breakpoint; now LLDB also can do so without installing extra debug symbols: lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h The above line runs LLDB in batch mode and on the "/usr/bin/zip -h" target: (lldb) target create "/usr/bin/zip" Current executable set to '/usr/bin/zip' (x86_64). (lldb) settings set -- target.run-args "-h" Before the program starts, we set a breakpoint on the "help" symbol: (lldb) b help Breakpoint 1: where = zip`help, address = 0x00000000004093b0 Once the program is run and has hit the breakpoint we ask for a backtrace: (lldb) r Process 10073 stopped * thread #1, name = 'zip', stop reason = breakpoint 1.1 frame #0: 0x00000000004093b0 zip`help zip`help: -> 0x4093b0 <+0>: pushq %r12 0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056 0x4093b9 <+9>: movl $0x1, %edi 0x4093be <+14>: xorl %eax, %eax Process 10073 launched: '/usr/bin/zip' (x86_64) (lldb) bt * thread #1, name = 'zip', stop reason = breakpoint 1.1 * frame #0: 0x00000000004093b0 zip`help frame #1: 0x0000000000403970 zip`main + 3248 frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243 frame #3: 0x0000000000408cee zip`_start + 46 In order to support the .gnu_debugdata section, one has to have LZMA development headers installed. The CMake section, that controls this part looks for the LZMA headers and enables .gnu_debugdata support by default if they are found; otherwise or if explicitly requested, the minidebuginfo support is disabled. GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6 (2013). Reviewers: espindola, labath, jankratochvil, alexshap Reviewed By: labath Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D66791 llvm-svn: 373891
* [lldb] [cmake] Support linking against clang-cpp dylibMichal Gorny2019-10-041-2/+13
| | | | | | | | | Link against clang-cpp dylib rather than split libs when CLANG_LINK_CLANG_DYLIB is enabled. Differential Revision: https://reviews.llvm.org/D68456 llvm-svn: 373734
* [lldb][CMake] Build LLDB.framework with -Wdocumentation in XcodeStefan Granitz2019-09-181-0/+3
| | | | llvm-svn: 372213
* [lldb][CMake] Infer `Clang_DIR` if not passed explicitlyStefan Granitz2019-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: If we only get `LLVM_DIR` and find Clang in the same provided build-tree, automatically infer `Clang_DIR` like this: ``` LLVM_DIR = /path/to/build-llvm/lib/cmake/llvm Clang_DIR = /paht/to/build-llvm/lib/cmake/clang ``` Reviewers: JDevlieghere, jingham, xiaobai, compnerd, labath Reviewed By: JDevlieghere, labath Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65798 llvm-svn: 372210
* Cache PYTHON_EXECUTABLE for windowsHaibo Huang2019-09-181-4/+4
| | | | | | | | | | | | Summary: This way it can be overwritten when cross compiling. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67641 llvm-svn: 372194
* Fix windows-x86-debug compilation with python enabled using multi-target ↵Adrian McCarthy2019-09-051-40/+92
| | | | | | | | | | | | | | | generator [Patch by Leonid Mashinskiy] Visual Studio CMake generator is multi-target and does not define CMAKE_BUILD_TYPE, so Debug build on VS was failing due selection of release python library. This patch reverts back some of latest changes and fixes building by raw VS using CMake expression generators. Differential Revision: https://reviews.llvm.org/D66994 llvm-svn: 371090
* [cmake] Remove the test for libstdc++<4.9Pavel Labath2019-08-201-22/+0
| | | | | | It is no longer relevant now that llvm requires >=5.1. llvm-svn: 369371
OpenPOWER on IntegriCloud