Commit Graph

384 Commits

Author SHA1 Message Date
Jonas Devlieghere c51ad1f836 [lldb/CMake] Don't use return() from macro()
> 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.
2019-12-20 20:53:33 -08:00
Jonas Devlieghere 94b1bc0fb8 Re-land "[lldb/CMake] Change how we deal with optional dependencies"
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.
2019-12-20 20:05:04 -08:00
Jonas Devlieghere fe86289bf1 Revert "[lldb/CMake] Change how we deal with optional dependencies"
This is failing on both the Windows and Debian bot.
2019-12-20 15:35:43 -08:00
Jonas Devlieghere 41d7c227b3 [lldb/CMake] Change how we deal with optional dependencies
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.
2019-12-20 14:13:28 -08:00
Jonas Devlieghere 2861324208 [lldb/Lua] Implement a Simple Lua Script Interpreter Prototype
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
2019-12-20 11:19:47 -08:00
Pavel Labath 40aa418223 [lldb/cmake] Delete LLDB_LINKER_SUPPORTS_GROUPS
The variable is unused.
2019-12-20 16:58:58 +01:00
Pavel Labath ca567ad6ff [lldb/cmake] Remove support for LLDB_DISABLE_CURSES
The buildbot which necessitated this is fixed.
2019-12-20 16:50:06 +01:00
Jonas Devlieghere 67de896229 [lldb/Lua] Add Boilerplate for a Lua Script Interpreter
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
2019-12-19 10:13:51 -08:00
Jonas Devlieghere e8af4fd42d [lldb/CMake] Initialize LLDB_ENABLE_POSIX based on the UNIX variable. 2019-12-13 13:46:43 -08:00
Jonas Devlieghere 4e26cf2cfb [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON
This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

Differential revision: https://reviews.llvm.org/D71482
2019-12-13 13:41:11 -08:00
Jonas Devlieghere 3011d55f72 [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_POSIX
Rename LLDB_DISABLE_POSIX to LLDB_ENABLE_POSIX and use cmakedefine01 for
consistency.
2019-12-13 10:00:59 -08:00
Pavel Labath ec109fb7ed [lldb/cmake] Temporarily revive LLDB_DISABLE_CURSES
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.
2019-12-13 10:23:35 +01:00
Jonas Devlieghere 61a2bdadb3 [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_TERMIOS
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.
2019-12-12 09:34:11 -08:00
Jonas Devlieghere 62456e579e [lldb/CMake] Rename LLDB_DISABLE_LIBEDIT to LLDB_ENABLE_LIBEDIT
This matches the naming scheme used by LLVM.

Differential revision: https://reviews.llvm.org/D71380
2019-12-12 09:23:06 -08:00
Jonas Devlieghere a4304f96d6 [lldb/CMake] Rename LLDB_DISABLE_CURSES to LLDB_ENABLE_CURSES
This matches the naming scheme used by LLVM.

Differential revision: https://reviews.llvm.org/D71377
2019-12-12 09:13:31 -08:00
Jonas Devlieghere ff82315d4e [lldb/CMake] Simplify linking against curses
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.
2019-12-11 14:36:32 -08:00
Jonas Devlieghere bf68bcb920 [lldb/Host] Use Host/Config.h for LibXML2 instead of a global define
Rename LIBXML2_DEFINED to LLDB_ENABLE_LIBXML2 and pass it through
Config.h instead of a global define.
2019-12-11 14:13:41 -08:00
Jonas Devlieghere 59998b7b7f [lldb/Host] Use Host/Config.h entries instead of a global define.
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
2019-12-10 11:16:52 -08:00
Jonas Devlieghere a921f587f7 Revert "[CMake] Re-enable -Wno-gnu-anonymous-struct & -Wno-nested-anon-types."
Whoops, they should be enabled, not disabled.
2019-11-18 17:00:35 -08:00
Jonas Devlieghere 755afc0af8 [CMake] Re-enable -Wno-gnu-anonymous-struct & -Wno-nested-anon-types.
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.
2019-11-18 16:58:40 -08:00
Jonas Devlieghere 34ca6e1fbe [LLDB] Remove debug message in AddLLDB.cmake 2019-11-12 15:33:03 -08:00
Jonas Devlieghere a247bd1f27 [LLDB] Fix/silence CMake developer warning for LLDB framework.
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.
2019-11-12 14:17:19 -08:00
Jonas Devlieghere fbb228c7d2 [LLDB] Always remove debugserver from LLVM_DISTRIBUTION_COMPONENTS
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.
2019-11-12 12:58:26 -08:00
António Afonso 31ea714e9a Add rpath to liblldb so vendors can ship their own python framework (or others)
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
2019-11-11 19:23:10 -08:00
Haibo Huang 77a60f0df6 [lldb] Record framework build path and use it everywhere
This avoids config time dependencies on liblldb. And enables other refactoring.
2019-11-06 14:05:35 -08:00
Vedant Kumar 610f80f7ba [cmake] Add an option to skip stripping before install
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.
2019-11-04 17:38:13 -08:00
Jonas Devlieghere fd025c094b [CMake] Move test dependency tracking into test/CMakeLists.txt
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.
2019-10-24 14:47:07 -07:00
Jonas Devlieghere eb1bbcec08 [CMake] Make it possible to set the RPATH in add_lldb_exectable.
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
2019-10-17 00:50:39 +00:00
Jonas Devlieghere d61ef7c46d [CMake] Fix add_lldb_test_dependency
This function would ignore all but the first argument. Now it correctly
adds every dependency by iterating over its arguments.

llvm-svn: 374216
2019-10-09 20:36:29 +00:00
Alex Langford 28fcc033c8 [CMake] Fix building without python on Windows
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
2019-10-08 18:38:46 +00:00
Jonas Devlieghere 37cf39df20 [CMake] Track test dependencies with add_lldb_test_dependency
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
2019-10-08 00:21:34 +00:00
Davide Italiano 33f054a316 [CMake] We only want to copy the headers for macOS.
<rdar://problem/55916729>

llvm-svn: 373970
2019-10-07 21:38:30 +00:00
Konrad Kleine 2c082b4827 [lldb][ELF] Read symbols from .gnu_debugdata sect.
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
2019-10-07 10:32:16 +00:00
Michal Gorny 9735739be7 [lldb] [cmake] Support linking against clang-cpp dylib
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
2019-10-04 12:03:03 +00:00
Stefan Granitz 2c72b41757 [lldb][CMake] Build LLDB.framework with -Wdocumentation in Xcode
llvm-svn: 372213
2019-09-18 10:41:13 +00:00
Stefan Granitz a206de8a0e [lldb][CMake] Infer `Clang_DIR` if not passed explicitly
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
2019-09-18 10:20:28 +00:00
Haibo Huang 5f8a3270ae Cache PYTHON_EXECUTABLE for windows
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
2019-09-18 01:00:12 +00:00
Adrian McCarthy f141de5bc9 Fix windows-x86-debug compilation with python enabled using multi-target 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
2019-09-05 17:22:30 +00:00
Pavel Labath 66d109640f [cmake] Remove the test for libstdc++<4.9
It is no longer relevant now that llvm requires >=5.1.

llvm-svn: 369371
2019-08-20 12:17:42 +00:00
Jonas Devlieghere 45e598d135 [CMake] Update CMAKE_OSX_DEPLOYMENT_TARGET to 10.12.
After LLVM moved to C++14, the RWMutex implementation was removed in
favor of std::shared_timed_mutex, which is only available on macOS
10.12 and later. As a workaround for older deployment targets, I added
   the original RWMutexImpl again, guarded by the deployment target.

When doing a standalone build of LLDB using the Xcode generator, the
CMake cache specifies a minimum deployment target. However, LLVM and
Clang might have been built with a different minimum deployment target.

This is exactly what happened for the Xcode build. LLVM was built with a
minimum deployment target newer than 10.12, using
std::shared_timed_mutex. LLDB on the other hand was built with a minimum
deployment target of 10.11, using the old RWMutexImpl, resulting in
undefined symbols at link-time.

This patch changes the minimum deployment target for the Xcode build to
10.12 to work around this problem. A better solution would involve
synchronizing the minimum deployment or even not setting one at all.

llvm-svn: 369220
2019-08-18 21:54:26 +00:00
Aaron Smith 216944ee03 Enable lldb-server on Windows
Summary:
This commit contains three small changes to enable lldb-server on Windows.

- Add lldb-server for Windows to the build
- Disable pty redirection on Windows for the initial lldb-server bring up
- Add a support to get the parent pid for a process on Windows
- Ifdef some signals which aren't supported on Windows

Thanks to Hui Huang for the help with this patch!

Reviewers: labath

Reviewed By: labath

Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D61686

llvm-svn: 368774
2019-08-13 23:50:54 +00:00
Stefan Granitz c822ab8f9a [lldb][CMake] Disable modules in Xcode projects
Summary: Apparently, module-enabled builds clash with Xcode's analysis.

Reviewers: aprantl, jingham, davide, teemperor

Reviewed By: davide

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65874

llvm-svn: 368294
2019-08-08 13:39:25 +00:00
Pavel Labath bac7862c00 Remove xcode-specific Config.h
Summary:
Now that the xcode project is removed, we no longer need/use the
hand-maintained Config.h file, as everything is configured through
cmake.

This patch deletes that file and reverts some of the changes from
r300372, which were made to support this use case.

Reviewers: sgraenitz, beanz

Subscribers: mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D65862

llvm-svn: 368266
2019-08-08 08:27:25 +00:00
Stefan Granitz befde45a6f [lldb][CMake] Fix one more detail in r368066
Differential Revision: https://reviews.llvm.org/D65797

llvm-svn: 368148
2019-08-07 10:47:49 +00:00
Stefan Granitz efd0e11b26 [lldb][NFC] Fix typo in 368066
Differential Revision: https://reviews.llvm.org/D65797

llvm-svn: 368143
2019-08-07 10:03:11 +00:00
Haibo Huang c6551bf013 Detect HAVE_SYS_TYPES_H in lldb
Summary:
After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in
Platform.h, or anywhere else in lldb. This change fixes that.

Reviewers: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65822

llvm-svn: 368125
2019-08-07 06:15:01 +00:00
Stefan Granitz 7f34a3652e [lldb][CMake] Generating Xcode projects
Summary:
Print a warning if the wrong cache script is used when generating a Xcode project, because it's too easy to confuse with Apple-lldb-macOS.cmake

```
  When building with Xcode, we recommend using the corresponding cache
  script.  If this was a mistake, clean your build directory and re-run
  CMake with:

    -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake

  See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject
```

Also set the generator inside the cache script.

Reviewers: JDevlieghere, jingham, clayborg

Reviewed By: JDevlieghere

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65797

llvm-svn: 368066
2019-08-06 17:21:34 +00:00
Stefan Granitz ed38be87fc [lldb][CMake] Avoid 'Autogenerate scheme' dialogs in Xcode projects
Summary:
Supported in CMake 3.9 and higher: https://cmake.org/cmake/help/v3.9/variable/CMAKE_XCODE_GENERATE_SCHEME.html
Older versions will just report it as unused in the end of the configuration process.

Reviewers: jingham, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65509

llvm-svn: 367538
2019-08-01 10:33:44 +00:00
Haibo Huang 79d117f27e [CMake] Move project() call to main CMake file
Summary:
The main CMake file don't have a project() call. In this case, cmake will run a dummy project(Project ) at the very beginning. Even before cmake_minimum_required. And a series of compiler detections will be triggered.

This is problematic if we depends on some policy to be set. E.g. CMP0056. try_compile will fail before we have a chance to do anything.

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65362

llvm-svn: 367273
2019-07-29 23:09:31 +00:00
Jonas Devlieghere fe4b12b4de [CMake] Print the correct variables
This didn't get updated after we decided to set PYTHON_MAJOR_VERSION and
PYTHON_MINOR_VERSION in find_python_libs_windows, instead of parsing the
variables ourselves.

llvm-svn: 367153
2019-07-26 20:58:10 +00:00
Jonas Devlieghere 81dab368bf [CMake] Fix find_python_libs_windows
Exporting PYTHON_INCLUDE_DIR to the Python scope somehow got lost in my
last change. Add it back again. This should fix the Windows bot!

llvm-svn: 367127
2019-07-26 16:32:49 +00:00
Jonas Devlieghere ac4a5c15fe [CMake] Print Python version on Windows
Trying to figure out what's causing the Windows bot to fail.

llvm-svn: 367125
2019-07-26 16:15:19 +00:00
Jonas Devlieghere 447ef83068 [CMake] Loosen Python version check and ignore patch version
Some versions of macOS report a different patch version for the system
provided interpreter and libraries.

Differential revision: https://reviews.llvm.org/D65230

llvm-svn: 367115
2019-07-26 14:26:33 +00:00
Stefan Granitz c8916258d5 [lldb][CMake] Fix framework-enabled build detail for Xcode
If debugserver or any other framework tool gets built first, its post-build copy operation was using 'Resources' as the file name instead of the destination directory. It was not a problem with Ninja, because here the framework structure was alreaady created at configuration time. With this fix, both generators are happy.

llvm-svn: 367005
2019-07-25 10:47:49 +00:00
Stefan Granitz 7e6f355b3e [lldb] Remove Xcode project legacy
Summary: Since D65109 removed the manually maintained Xcode project, there's a few things we don't need anymore. Anything here we should keep or anything more to remove?

Reviewers: JDevlieghere, jasonmolenda, clayborg, jingham, lanza, teemperor

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65155

llvm-svn: 366879
2019-07-24 09:20:14 +00:00
Saleem Abdulrasool e97f2f33e7 build: allow the user to specify `llvm-tblgen`
This follows the same pattern as Clang and permits the user to specify
the tablegen to use via `-DLLVM_TABLEGEN=`.  This allows for
cross-compiling LLDB for a foreign target (e.g. Windows ARM64 on Windows
X64).  The LLVM dependency for LLDB in that case must be a Windows ARM64
build which cannot cross-compile llvm-tblgen due to the way that Visual
Studio works.  Instead, permit the user to have a separate tablegen
build which can be used during the build.

llvm-svn: 366639
2019-07-20 17:59:08 +00:00
Stefan Granitz fc0d766511 [CMake] Align debugserver with lldb-server on Darwin
Summary: Make debugserver a tool like lldb-server, so it can be included/excluded via `LLDB_TOOL_DEBUGSERVER_BUILD`. This replaces the old `LLDB_NO_DEBUGSERVER` flag. Doing the same for darwin-debug while I am here.

Reviewers: xiaobai, JDevlieghere, davide

Reviewed By: xiaobai, JDevlieghere

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64994

llvm-svn: 366631
2019-07-20 11:18:31 +00:00
Stefan Granitz 6454a20b72 [CMake] Polish folders in generated Xcode project
Summary: Group plugins by subfolder. Move liblldb-resource-headers to `lldb misc`. Avoid install-distribution related targets in IDE-enabled builds.

Reviewers: jingham, mib, stella.stamenova

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64865

llvm-svn: 366459
2019-07-18 16:44:45 +00:00
Stefan Granitz 0c4948455d [CMake] Always build debugserver on Darwin and allow tests to use the system's one
Summary:
We can always build debugserver, but we can't always sign it to be useable for testing. `LLDB_USE_SYSTEM_DEBUGSERVER` should only tell whether or not the system debugserver should be used for testing.
The old behavior complicated the logic around debugserver a lot. The new logic sorts out most of it.

Please note that this patch is in early stage and needs some more testing. It should not affect platfroms other than Darwin. It builds on Davide's approach to validate the code-signing identity at configuration time.

What do you think?

Reviewers: xiaobai, JDevlieghere, davide, compnerd, friss, labath, mgorny, jasonmolenda

Reviewed By: JDevlieghere

Subscribers: lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64806

llvm-svn: 366433
2019-07-18 13:30:37 +00:00
Adrian McCarthy 3628a8fae9 [NFC] Clarify a Cmake status message regarding Python on LLDBConfig
llvm-svn: 366383
2019-07-17 22:36:26 +00:00
Jonas Devlieghere e37750b934 [CMake] Remove duplicated logic to find Python when doing a standalone build
I'm pretty sure there's no need to have this logic living in
LLDBStandalone. It doesn't appear anything in LLVM depends on this, and
We always go through LLDBConfig.cmake which has the canonical way to
find the Python libs and interpreter for LLDB.

Differential revision: https://reviews.llvm.org/D64821

llvm-svn: 366363
2019-07-17 19:36:20 +00:00
Jonas Devlieghere ca12cb9482 [CMake] Use LLVM_DIR and Clang_DIR for standalone builds.
When doing a standalone build, without setting LLDB_PATH_TO_LLVM_BUILD
or LLDB_PATH_TO_CLANG_BUILD, you get the following error.

```
CMake Error at cmake/modules/LLDBStandalone.cmake:23 (find_package):
  Could not find a package configuration file provided by "LLVM" with any of
  the following names:

    LLVMConfig.cmake
    llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.
```

This suggests setting LLVM_DIR to LLVM's install directory. However,
LLDBStandalone.cmake takes LLDB_PATH_TO_LLVM_BUILD as its hint. As
someone who isn't familiar with the standalone process, this is rather
confusing. This patch removes LLDB_PATH_TO_LLVM_BUILD and
LLDB_PATH_TO_CLANG_BUILD and instead use LLVM_DIR and Clang_DIR
respectively.

Differential revision: https://reviews.llvm.org/D64823

llvm-svn: 366362
2019-07-17 19:24:15 +00:00
Stefan Granitz ee24b40b9e [CMake] Avoid liblldb genex when figuring out the copy destination for framework tools
This genex created an order-only dependency to liblldb for every framework tool. It reduced build throughput in the first half of the compilation and pulled in unnecessary build units, e.g. debugserver required ~900 build units. With this change debugserver is (again) down at 52 build units!

llvm-svn: 366350
2019-07-17 17:14:40 +00:00
Jonas Devlieghere 7f24757b8e [CMake] Move standalone check so we don't have to reconfigure LLDB
By moving the standalone check into the main CMake file, the whole file
is ignored in a regular (non-standalone) build. This means that you can
make changes to LLDBStandalone.cmake without having to reconfigure a
build in a different directory. This matters when you share one source
repository with different build directories (e.g. release-assert, debug,
standalone).

Differential revision: https://reviews.llvm.org/D64824

llvm-svn: 366346
2019-07-17 16:47:02 +00:00
Nathan Lanza 98a48794ec Don't require python exe and lib versions to match while crosscompiling
Summary:
While cross compiling, the python executable is used to run a handful
of scripts while the libraries are linked and headers are included.
Theoretically it's possible for the versions to match completely, but
requiring the build to match 2.7.10 to 2.7.15 is unnecessary.

Subscribers: mgorny

Differential Revision: https://reviews.llvm.org/D64822

llvm-svn: 366285
2019-07-16 23:54:17 +00:00
Reid Kleckner 1d58c1d9d6 Fix LLDB Windows build Python version logic after r366243
llvm-svn: 366247
2019-07-16 18:46:51 +00:00
Jonas Devlieghere 5826ab6b0c [CMake] Fail when Python interpreter doesn't match Python libraries version
Because of how CMake finds the Python libraries and interpreter, it's
possible to end up with a discrepancy between the two. For example,
you'd end up using a Python 3 interpreter to run the test suite while
LLDB was built and linked against Python 2.

This patch adds a fatal error to CMake so we find out at configuration
time, instead of finding out at test time.

Differential revision: https://reviews.llvm.org/D64812

llvm-svn: 366243
2019-07-16 18:27:12 +00:00
Stefan Granitz e8ced86deb [CMake] Add Apple-lldb-Xcode.cmake cache that avoids install options
llvm-svn: 366226
2019-07-16 16:57:45 +00:00
Jonas Devlieghere 497bb44fc4 Make Python version setting actually effective
This needs to be outside the if to actually work. Also, this adjusts the
list of versions to match LLVM.

Patch by: Christian Biesinger

Differential revision: https://reviews.llvm.org/D64578

llvm-svn: 365988
2019-07-13 03:30:55 +00:00
Raphael Isemann 6f4fb4e7ad [lldb] Let table gen create command option initializers.
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).

This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).

Also refactoring the related data structures can now be done without changing the hundred of option initializers.

For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases",         'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
  def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```

For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables  in separate patches.

Reviewers: JDevlieghere, davide, sgraenitz

Reviewed By: JDevlieghere

Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64365

llvm-svn: 365908
2019-07-12 15:30:55 +00:00
Nico Weber d24faac011 Add Python 3.6 and 3.7 to the version list
Python 3.6 and 3.7 have been released.

Differential Revision: https://reviews.llvm.org/D64444

Patch from Christian Biesinger <cbiesinger@google.com>!

llvm-svn: 365688
2019-07-10 19:18:38 +00:00
Stefan Granitz bf223dff7e [CMake][NFC] Remove dead code lldb_append_link_flags() from AddLLDB.cmake
llvm-svn: 365651
2019-07-10 16:02:46 +00:00
Stefan Granitz 86d3c9fd1f [CMake][NFC] Polish comments in AddLLDB.cmake
llvm-svn: 365650
2019-07-10 16:00:03 +00:00
Stefan Granitz f554ce7f92 [CMake] Add Apple-lldb-Linux.cmake cache
llvm-svn: 365649
2019-07-10 15:59:56 +00:00
Stefan Granitz 839e305eb1 [CMake] Polish Apple-lldb caches
llvm-svn: 365648
2019-07-10 15:59:50 +00:00
Stefan Granitz 110f97632e [CMake] `install-distribution` for LLDB on Darwin
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.

LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.

Please let me know what you think, while I run a few more tests and add remarks+documentation.

Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny

Reviewed By: xiaobai, JDevlieghere

Subscribers: lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64408

llvm-svn: 365617
2019-07-10 11:09:29 +00:00
Stefan Granitz 05adc0f317 [CMake] Distribution builds for LLDB standalone
Summary:
Enable `distribution` and `install-distribution` targets in LLDB standalone and pre-populate the cache accordingly on macOS.
Documentation for distribution builds is here: https://llvm.org/docs/BuildingADistribution.html

Reviewers: xiaobai, mgorny, JDevlieghere, davide, compnerd

Reviewed By: xiaobai, JDevlieghere

Subscribers: lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64399

llvm-svn: 365616
2019-07-10 11:09:11 +00:00
Stefan Granitz 685911ffce [CMake] Remove extra lldb-framework target
Summary: The custom lldb-framework target was meant to encapsulate all build steps that LLDB.framework needs on top of the ordinaly liblldb. In the end all of it happens in post-build steps, so we can do the same with liblldb and cut down another source of confusion.

Reviewers: xiaobai, JDevlieghere

Reviewed By: xiaobai, JDevlieghere

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64397

llvm-svn: 365615
2019-07-10 11:09:01 +00:00
Stefan Granitz e5b868d6a3 [CMake] Polish a comment
llvm-svn: 365459
2019-07-09 10:29:07 +00:00
Stefan Granitz e9298dc902 [CMake] Don't initialize LLVM_INSTALL_TOOLCHAIN_ONLY in Apple-lldb-base cache
llvm-svn: 365458
2019-07-09 10:29:00 +00:00
Stefan Granitz 189355f3ee [CMake] Remove old lldb_setup_framework_rpaths_in_tool()
llvm-svn: 365457
2019-07-09 10:28:53 +00:00
Stefan Granitz 1665dd6346 [CMake] Avoid libcxxabi dependency when building LLDB from the monorepo on macOS
libc++abi became mandatory to link the libc++ binaries. LLDB only needs the build artifacts and not the linked output (we don't ship `libc++.dylib` and/or `libc++.a`). Disable the respective link steps to avoid the dependency to libc++abi.

<rdar://problem/51980716>

llvm-svn: 365038
2019-07-03 13:21:48 +00:00
Jason Molenda 37aeca39ba Update cmake build setup so lldb doesn't link against the DebugSymbols
framework on macOS, in line with the source/xcode project changes in
r364243.
<rdar://problem/49458356> 

llvm-svn: 364979
2019-07-02 23:36:39 +00:00
Stefan Granitz f2ffa7320e Specify log level for CMake messages (less stderr)
Summary:
Specify message levels in CMake. Prefer STATUS (stdout).

As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools,  noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step.

This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR)  instead of the default.

* I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations.
* Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know.

Patch by: Christoph Siedentop

Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz

Reviewed By: sgraenitz

Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits

Tags: #sanitizers, #lldb, #llvm

Differential Revision: https://reviews.llvm.org/D63370

llvm-svn: 363821
2019-06-19 15:25:32 +00:00
Stefan Granitz a0781b6e3a [CMake] Fix generated Xcode-project ignoring output directory setting for LLDB.framework
Other generators honor the `LIBRARY_OUTPUT_DIRECTORY` target property, but apparently Xcode doesn't. So we call `set_output_directory()` as `llvm_add_library()` would do and this works.
Note that `LIBRARY_OUTPUT_DIRECTORY` is still necessary, because it's used to store and read the target's absolute build directory (while `LLDB_FRAMEWORK_BUILD_DIR` is relative!).

llvm-svn: 363280
2019-06-13 17:35:50 +00:00
Stefan Granitz 8f30e322ab [CMake] Add fallbacks for copying clang-resource-headers to LLDB.framework in standalone builds
llvm-svn: 363271
2019-06-13 15:07:56 +00:00
Adrian McCarthy a4198c22dc NFC: Fix typo in a cmake message
llvm-svn: 362845
2019-06-07 21:14:01 +00:00
Stefan Granitz c769462438 [CMake] Add configuration dirs as potential locations for llvm-lit and llvm-tblgen in standalone builds
Summary:
If the provided LLVM build-tree used a multi-configuration generator like Xcode, `LLVM_TOOLS_BINARY_DIR` will have a generator-specific placeholder to express `CMAKE_CFG_INTDIR`. Thus `llvm-lit` and `llvm-tblgen` won't be found.
D62878 exports the actual configuration types so we can fix the path and add them to the search paths for `find_program()`.

Reviewers: xiaobai, labath, stella.stamenova

Reviewed By: xiaobai, stella.stamenova

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D62879

llvm-svn: 362589
2019-06-05 08:31:50 +00:00
Stefan Granitz e4ad1b7bbe [CMake] Move and add settings to Apple-lldb-base cache script
llvm-svn: 362500
2019-06-04 14:21:48 +00:00
Stefan Granitz 5dc9036746 [CMake] LLDB.framework tools handling
Summary:
Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach.

No function change otherwise.
This is a reduced follow-up from the proposal in D61952.

Reviewers: xiaobai, compnerd, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D62472

llvm-svn: 361946
2019-05-29 11:26:06 +00:00
Saleem Abdulrasool 99e040b3c9 build: only search for the needed python type
Windows has different types of runtime libraries which are ABI
incompatible with one another.  This requires that the debug build of
lldb link against the debug build of python.  Adjust the python search
to search for only the required type of python.  This permits building a
release build of lldb against just the release build of python.

llvm-svn: 361915
2019-05-29 02:26:29 +00:00
Stefan Granitz a3388e5f9e [CMake] Folder structure for generated Xcode project to cover more targets
llvm-svn: 361799
2019-05-28 09:29:05 +00:00
Stefan Granitz fd0779181f [CMake] Add first CMake cache files
Summary:
CMake cache scripts pre-populate the CMakeCache in a build directory with commonly used settings.
The CMake invocation from D61952 could look like this:

```
cmake -G Ninja -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-osx.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" ../llvm-project/llvm
```

Options specified on the command line will override options in the cache files (as long as caches don't use `FORCE`).
What do you think? (This is a first proposal and not set in stone.)

Reviewers: xiaobai, compnerd, JDevlieghere, aprantl, labath

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D61956

llvm-svn: 361069
2019-05-17 19:19:41 +00:00
Pavel Labath 56f9afaf6b [CMake] Correctly reinstate LLDB_CAN_USE_LLDB_SERVER
r360631 introduced a "syntax error" which meant that cmake was still not
honoring the value of LLDB_CAN_USE_LLDB_SERVER variable. The correct
syntax for seting an internal cache variable is "set(VAR value CACHE
INTERNAL)", but the patch omitted the "CACHE" keyword. The "syntax
error" is in quotes because without the CACHE keyword this is still
valid syntax for setting the value of LLDB_CAN_USE_LLDB_SERVER to "1
INTERNAL".

There doesn't seem to be a need for this to be a cache variable so I'm
reverting this variable to a plain one, as it was before r360621.

This will hopefully fix the windows build.

llvm-svn: 360652
2019-05-14 08:18:06 +00:00
Jonas Devlieghere 1d8b2a0661 [CMake] Reinstate LLDB_CAN_USE_LLDB_SERVER
We cannot manipulate the LLDB_TOOL_LLDB_SERVER_BUILD directly from
LLDBConfig.cmake because this would set the variable before the option
is defined in AddLLVM.cmake. Instead, we need to use the
LLDB_CAN_USE_LLDB_SERVER variable to conditionally add the lldb-server
subdirectory. This should ensure the variable doesn't get cleared.

llvm-svn: 360631
2019-05-13 22:55:11 +00:00
Jonas Devlieghere aeeeb37e37 [CMake] Simplify lldb-server handling
We can piggyback off the existing add_lldb_tool_subdirectory to decide
whether or not lldb-server should be built.

Differential revision: https://reviews.llvm.org/D61872

llvm-svn: 360621
2019-05-13 21:25:02 +00:00
Alex Langford babcbaf971 [CMake] Fix subtle CMake bug
CMake specifies that the DEPENDS field of add_custom_target is for files
and output of add_custom_command. In order to add a target dependency,
add_dependencies should be used.

llvm-svn: 359490
2019-04-29 19:44:43 +00:00
Frederic Riss 8ecb7bbe2b [CMake] Remove Apple-specific version logic.
We were using the LLDB-Info.plist as the canonical holder of the
version number, but there is really no good reason to do this. If
anything the plist should be generated using the information provided
to CMake.

For now just remove the logic extracting the version from the plist
and rely on LLDB_VERSION_STRING.

llvm-svn: 358604
2019-04-17 18:23:22 +00:00
Davide Italiano 6df6895d90 [tools] Make vscode and lldb-instr optional.
Summary:
Saves some build times, and they're not part of the usual
developer workflow.

Reviewers: JDevlieghere, friss

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D60780

llvm-svn: 358528
2019-04-16 21:15:28 +00:00
Alex Langford 7e7f79ccb1 [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds
Summary:
This line is unnecessary because add_llvm_executable will handle
linking the correct LLVM libraries for you. LLDB standalone builds are totally
fine without this.

In the best case, having this line here is harmless. In the worst case it can
cause link issues.

If you build lldb-server for android using the standalone build, this line
will cause LLVM_LIBRARY_DIR to be the first place you look for libraries.
This is an issue because if you built libc++, it will try to link against
that one instead of the one from the android NDK.  Meanwhile, the LLVM libraries
you're linking against were linked against the libc++ from the NDK.

Ideally, we would take advantage of the AFTER option for link_directories(), but
that was not available in LLDB's minimum supported version of CMake (CMake 3.4.3).

Differential Revision: https://reviews.llvm.org/D60180

llvm-svn: 357817
2019-04-05 21:01:50 +00:00