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.
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.
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Haibo Huang