Commit Graph

28 Commits

Author SHA1 Message Date
Shoaib Meenai 015d78a25e [lldb] Remove XPCServices symlinking
This is a downstream change that was accidentally included upstream.

Reviewed By: vsk

Differential Revision: https://reviews.llvm.org/D97701
2021-03-01 11:23:46 -08:00
Raphael Isemann ce4d15fe14 [lldb] Symlink the Clang resource directory to the LLDB build directory in standalone builds
When doing a standalone build (i.e., building just LLDB against an existing
LLVM/Clang installation), LLDB is currently unable to find any Clang resource
directory that contains all the builtin headers we need to parse real source
code. This causes several tests that actually parse source code on disk within
the expression parser to fail (most notably nearly all the import-std-module
tests).

The reason why LLDB can't find the resource directory is that we search based on
the path of the LLDB shared library path. We assumed that the Clang resource
directory is in the same prefix and has the same relative path to the LLDB
shared library (e.g., `../clang/10.0.0/include`). However for a standalone build
where the existing Clang can be anywhere on the disk, so we can't just rely on
the hardcoded relative paths to the LLDB shared library.

It seems we can either solve this by copying the resource directory to the LLDB
installation, symlinking it there or we pass the path to the Clang installation
to the code that is trying to find the resource directory. When building the
LLDB framework we currently copy the resource directory over to the framework
folder (this is why the import-std-module are not failing on the Green Dragon
standalone bot).

This patch symlinks the resource directory of Clang into the LLDB build
directory. The reason for that is simply that this is only needed when running
LLDB from the build directory. Once LLDB and Clang/LLVM are installed the
already existing logic can find the Clang resource directory by searching
relative to the LLDB shared library.

Reviewed By: kastiglione, JDevlieghere

Differential Revision: https://reviews.llvm.org/D88581
2020-10-06 09:28:39 +02:00
Vedant Kumar d49aedd315 Build a flat LLDB.framework for embedded Darwin targets
This patch configures LLDB.framework to build as a flat unversioned
framework on non-macOS Darwin targets, which have never supported the
macOS framework layout.

This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to
reflect the fact that lldb is built for several different kinds of embedded
Darwin targets, not just iOS.

Differential Revision: https://reviews.llvm.org/D85770
2020-08-12 13:34:29 -07:00
Pavel Labath 363f05b83d [lldb] Delete the SharingPtr class
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.

This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.

Reviewers: teemperor, JDevlieghere, jingham

Subscribers: mgorny, jfb, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74153
2020-02-11 13:23:18 +01: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
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
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 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 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 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 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
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
Shoaib Meenai 5be71faf4b [build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].

I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.

[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html

Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille

Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits

Tags: #clang, #sanitizers, #lldb, #openmp, #llvm

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

llvm-svn: 355340
2019-03-04 21:19:53 +00:00
Stefan Granitz 1f34e851ee [CMake] Dump LLDB.framework tools at configuration time
llvm-svn: 352387
2019-01-28 16:57:19 +00:00
Stefan Granitz f126ce6881 [CMake] Revised LLDB.framework builds
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.

Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)

Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle

Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath

Reviewed By: aprantl

Subscribers: friss, mgorny, lldb-commits, #lldb

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

llvm-svn: 350391
2019-01-04 12:46:50 +00:00
Stefan Granitz 3d00002ea2 [CMake] Fix side-effect from LLDB_VERSION change in r346668 for framework-enabled builds
llvm-svn: 348360
2018-12-05 12:18:44 +00:00
Alex Langford 36706fd977 Introduce install-lldb-framework target
Summary:
Previously, I thought that install-liblldb would fail because CMake had
a bug related to installing frameworks. In actuality, I misunderstood the
semantics of `add_custom_target`: the DEPENDS option refers to specific files,
not targets. Therefore `install-liblldb` should rely on the actual liblldb
getting generated rather than the target.

This means that the previous patch I committed (to stop relying on CMake's
framework support) is no longer needed and has been reverted. Using CMake's
framework support greatly simplifies the implementation.

`install-lldb-framework` (and the stripped variant) is as simple as
depending on `install-liblldb` because CMake knows that liblldb was built as a
framework and will install the whole framework for you. The stripped variant
will depend on the stripped variants of individual tools only to ensure they
actually are stripped as well.

Reviewers: labath, sas

Subscribers: mgorny, lldb-commits

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

llvm-svn: 338594
2018-08-01 17:21:18 +00:00
Alex Langford 2f6a1018e0 Revert "Stop building liblldb with CMake's framework functionality"
This reverts r338154. This change is actually unnecessary, as the CMake
bug I referred to was actually not a bug but a misunderstanding of
CMake.

Original Differential Revision: https://reviews.llvm.org/D49888

llvm-svn: 338178
2018-07-27 23:38:58 +00:00
Alex Langford c1d4311c1b Stop building liblldb with CMake's framework functionality
Summary:
CMake has a bug in its ninja generator that prevents you from
installing targets that are built with framework support. Therefore, I want to
not rely on CMake's framework support.
See https://gitlab.kitware.com/cmake/cmake/issues/18216

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

llvm-svn: 338154
2018-07-27 19:41:17 +00:00
Alex Langford 60bdd09d10 Add back lldb-framework-headers target
In r338058 we removed the target `lldb-framework-headers`, which mean
lldb-framework no longer depended on `framework_headers`, so they never
actually got generated. This is a partial revert of r338058: I added
back the lldb-framework-headers target, but the framework-header-fix.sh
script still runs on the copied headers.

llvm-svn: 338074
2018-07-26 21:55:14 +00:00
Alex Langford 10c9e0e0d8 Make framework-header-fix process copied headers
Summary:
Previously the framework-header-fix script would change the sources
before they were copied, leading to unnecessary rebuilds on repeat
`ninja lldb` invocations. This runs the script on the headers after
they're copied into the produced LLDB.framework, meaning it doesn't
affect any files being built.

Patch by Keith Smiley <keithbsmiley@gmail.com>!

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

llvm-svn: 338058
2018-07-26 19:04:46 +00:00
Alex Langford 97ba3b64dd Invert dependency between lldb-framework and lldb-suite
Summary:
Currently, if you build lldb-framework the entire framework doesn't
actually build. In order to build the entire framework, you need to actually
build lldb-suite. This abstraction doesn't feel quite right because
lldb-framework truly does depend on lldb-suite (liblldb + related tools).

In this change I want to invert their dependency. This will mean that lldb and
finish_swig will depend on lldb-framework in a framework build, and lldb-suite
otherwise. Instead of adding conditional logic everywhere to handle this, I
introduce LLDB_SUITE_TARGET to handle it.

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

llvm-svn: 337311
2018-07-17 18:28:51 +00:00
Alex Langford bd09f772eb [CMake] Simplify a few framework build rules
llvm-svn: 336395
2018-07-05 22:16:15 +00:00
Alex Langford f66a36d2dc Fix up Info.plist when building LLDB.framework with CMake
Summary:
We weren't using the Info.plist template in resources previously.
When using that template, some of the key's values weren't being populated
because some variables were not being defined. In one case, CMake didn't
like the substring expansion syntax of CFBundleIdentifier so I got rid of that.

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

llvm-svn: 335014
2018-06-19 02:59:30 +00:00
Alex Langford 27510c18ad Introduce lldb-framework CMake target and centralize its logic
Summary:
In this patch I aim to do the following:

1) Create an lldb-framework target that acts as the target that handles generating LLDB.framework. Previously, liblldb acted as the target for generating the framework in addition to generating the actual lldb library. This made the target feel overloaded.
2) Centralize framework generation as much as it makes sense to do so.
3) Create a target lldb-suite, which depends on every tool and library that makes liblldb fully functional. One result of having this target is it makes tracking dependencies much clearer.

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

llvm-svn: 334968
2018-06-18 18:27:16 +00:00