summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/Bindings] Move bindings into their own subdirectoryJonas Devlieghere2020-01-091-4/+4
| | | | | | | | | | | | All the code required to generate the language bindings for Python and Lua lives under scripts, even though the majority of this code aren't scripts at all, and surrounded by scripts that are totally unrelated. I've reorganized these files and moved everything related to the language bindings into a new top-level directory named bindings. This makes the corresponding files self contained and much more discoverable. Differential revision: https://reviews.llvm.org/D72437
* [CMake] Add $ORIGIN/../../../../lib to rpath if BUILD_SHARED_LIBS or ↵Fangrui Song2020-01-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | LLVM_LINK_LLVM_DYLIB on *nix Summary: lib/python2.7/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so, which depends on lib/libLLVM*.so (-DBUILD_SHARED_LIBS=ON) or lib/libLLVM-10git.so (-DLLVM_LINK_LLVM_DYLIB=ON). Add an additional rpath `$ORIGIN/../../../../lib` so that _lldb.so can be loaded from Python. This fixes an import error from lib/python2.7/dist-packages/lldb/__init__.py from . import _lldb ImportError: libLLVMAArch64CodeGen.so.10git: cannot open shared object file: No such file or directory The following configurations will work: * -DBUILD_SHARED_LIBS=ON * -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON * -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON (-DCLANG_LINK_CLANG_DYLIB=ON depends on -DLLVM_LINK_LLVM_DYLIB=ON) Reviewed By: labath Differential Revision: https://reviews.llvm.org/D71800
* [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/Lua] Generate Lua BindingsJonas Devlieghere2019-12-211-0/+19
| | | | | | | | | | | This patch uses SWIG to generate the Lua bindings for the SB API. It covers most of the API, but some methods require a type map similar to Python. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71235
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-131-2/+2
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* [LLDB] Only set FRAMEWORK when we're actually building a framework.Jonas Devlieghere2019-11-121-1/+2
|
* [LLDB] Fix/silence CMake developer warning for LLDB framework.Jonas Devlieghere2019-11-121-1/+1
| | | | | | | | | | | | 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.
* new api class: SBFileLawrence D'Anna2019-10-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SBFile is a scripting API wrapper for lldb_private::File This is the first step in a project to enable arbitrary python io.IOBase file objects -- including those that override the read() and write() methods -- to be used as the main debugger IOStreams. Currently this is impossible because python file objects must first be converted into FILE* streams by SWIG in order to be passed into the debugger. full prototype: https://github.com/smoofra/llvm-project/tree/files Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67793 llvm-svn: 373562
* SystemInitializer: Use Targets.def to selectively initialize ABI pluginsPavel Labath2019-09-261-5/+0
| | | | | | | | | | | This avoids having to define additional macros in the cmake file, and and also makes the logic in the cpp files more compact. It is also easily extendible to other plugin types (instruction emulation?) that should only be initialized if the corresponding llvm target is built. Thanks to Ilya Birukov for pointing me to this file. llvm-svn: 372952
* Have ABI plugins vend llvm MCRegisterInfo dataPavel Labath2019-09-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I was recently surprised to learn that there is a total of 2 (two) users of the register info definitions contained in the ABI plugins. Yet, the defitions themselves span nearly 10kLOC. The two users are: - dwarf expression pretty printer - the mechanism for augmenting the register info definitions obtained over gdb-remote protocol (AugmentRegisterInfoViaABI) Both of these uses need the DWARF an EH register numbers, which is information that is already available in LLVM. This patch makes it possible to do so. It adds a GetMCRegisterInfo method to the ABI class, which every class is expected to implement. Normally, it should be sufficient to obtain the definitions from the appropriate llvm::Target object (for which I provide a utility function), but the subclasses are free to construct it in any way they deem fit. We should be able to always get the MCRegisterInfo object from llvm, with one important exception: if the relevant llvm target was disabled at compile time. To handle this, I add a mechanism to disable the compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD cmake setting. This ensures all our existing are able to create their MCRegisterInfo objects. The new MCRegisterInfo api is not used yet, but the intention is to make use of it in follow-up patches. Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits Differential Revision: https://reviews.llvm.org/D67965 llvm-svn: 372862
* [CMake] `install-distribution` for LLDB on DarwinStefan Granitz2019-07-101-3/+5
| | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Folder structure for generated Xcode project to cover more targetsStefan Granitz2019-05-281-0/+1
| | | | llvm-svn: 361799
* [CMake] Emit LLDB.framework.dSYM to avoid potential name collision with ↵Stefan Granitz2019-04-181-0/+4
| | | | | | | | | | | | | | | | | | driver's lldb.dSYM Summary: Emit framework's dSYM bundle as LLDB.framework.dSYM instead of LLDB.dSYM, because the latter could conflict with the driver's lldb.dSYM when emitted in the same directory on case-insensitive file systems. Requires https://reviews.llvm.org/D60862 Reviewers: friss, beanz, bogner Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D60863 llvm-svn: 358686
* [Python] Define empty SWIG wrapper for unit testin"Jonas Devlieghere2019-03-261-0/+5
| | | | | | | | | The python plugin uses wrappers generated by swig. For the symbols to be available, we'd need to link against liblldb, which is not an option because the symbols could conflict with the static library we are testing. Instead we define the symbols ourselves in the unit test. llvm-svn: 356971
* [Python] Move SWIG wrapper dependency into the pluginJonas Devlieghere2019-03-251-5/+0
| | | | | | This should fix the Windows bot (fingers crossed). llvm-svn: 356967
* Pass /bigobj for SBReproducer.cpp with MSVCZachary Turner2019-03-061-0/+4
| | | | | | | | | /BIGOBJ is used to bypass certain COFF file format limitations and is used with, unsurprisingly, very big object files. This file has grown large enough that it needs this flag in order to compile successfully. llvm-svn: 355559
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Make liblldb depend on clang-headersAlex Langford2019-02-281-0/+4
| | | | | | | | | | | Summary: The clang headers are useful when dealing with clang modules. There is also a way to get to the clang headers from the SB API so it would be nice if they were also available when we just build lldb. Differential Revision: https://reviews.llvm.org/D58793 llvm-svn: 355149
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-211-1/+0
| | | | | | | | | | | | | | | | As per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html This commit implements option (3): > Go back to initializing the reproducer before the rest of the debugger. > The method wouldn't be instrumented and guarantee no other SB methods are > called or SB objects are constructed. The initialization then becomes part > of the replay. Differential revision: https://reviews.llvm.org/D58410 llvm-svn: 354631
* [Reproducers] SBReproducer framework: Capture & ReplayJonas Devlieghere2019-02-061-0/+1
| | | | | | | | | | | | | This is part two of the reproducer instrumentation framework. It contains the code to capture and replay function calls. The main user of this framework will be the SB API layer. For all the details refer to the RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html Differential revision: https://reviews.llvm.org/D56322 llvm-svn: 353324
* [CMake] Python bindings generation polishingStefan Granitz2019-01-041-7/+12
| | | | | | | | | | | | | | | | | Summary: Simplify SWIG invocation and handling of generated files. The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory. Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai Reviewed By: aprantl Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55332 llvm-svn: 350393
* [CMake] Revised LLDB.framework buildsStefan Granitz2019-01-041-29/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Reproducers] Change how reproducers are initialized.Jonas Devlieghere2018-12-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the way the reproducer is initialized. Rather than making changes at run time we now do everything at initialization time. To make this happen we had to introduce initializer options and their SB variant. This allows us to tell the initializer that we're running in reproducer capture/replay mode. Because of this change we also had to alter our testing strategy. We cannot reinitialize LLDB when using the dotest infrastructure. Instead we use lit and invoke two instances of the driver. Another consequence is that we can no longer enable capture or replay through commands. This was bound to go away form the beginning, but I had something in mind where you could enable/disable specific providers. However this seems like it adds very little value right now so the corresponding commands were removed. Finally this change also means you now have to control this through the driver, for which I replaced --reproducer with --capture and --replay to differentiate between the two modes. Differential revision: https://reviews.llvm.org/D55038 llvm-svn: 348152
* Add compatibility version to liblldb in framework buildsAlex Langford2018-09-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Building LLDB with xcodebuild sets the compatibility version of liblldb in LLDB.framework. Building the framework with cmake does not set the compatibility version, and so it defaults to 0.0.0. This is a discrepency in the difference between the xcode build and the cmake build. I tested this change by building without this patch. From the build tree I ran `otool -L Library/Frameworks/LLDB.framework/Versions/A/LLDB` and got this: ``` @rpath/LLDB.framework/Versions/A/LLDB (compatibility version 0.0.0, current version 8.0.0) ``` Did the same with this patch and the output contained this: ``` @rpath/LLDB.framework/Versions/A/LLDB (compatibility version 1.0.0, current version 8.0.0) ``` Reviewers: clayborg, labath Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D51959 llvm-svn: 342066
* Introduce install-lldb-framework targetAlex Langford2018-08-011-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Stop building liblldb with CMake's framework functionality"Alex Langford2018-07-271-14/+9
| | | | | | | | | | 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
* Stop building liblldb with CMake's framework functionalityAlex Langford2018-07-271-9/+14
| | | | | | | | | | | | 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
* Invert dependency between lldb-framework and lldb-suiteAlex Langford2018-07-171-2/+4
| | | | | | | | | | | | | | | | | 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
* ScriptInterpreterPython cleanupPavel Labath2018-06-211-5/+0
| | | | | | | | | Instead of #ifdef-ing the contents of all files in the plugin for all non-python builds, just disable the plugin at the cmake level. Also, remove spurious extra linking of the Python plugin in liblldb. This plugin is already included as a part of LLDB_ALL_PLUGINS variable. llvm-svn: 335236
* Introduce lldb-framework CMake target and centralize its logicAlex Langford2018-06-181-54/+0
| | | | | | | | | | | | | 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
* Disable warnings for the generated LLDB wrapper sourceRaphael Isemann2018-06-121-6/+5
| | | | | | | | | | | | | | | | | Summary: This source files emits all kind of compiler warnings on different platforms. As the source code in the file is generated and we therefore can't actually fix the warnings, we might as well disable them. Reviewers: aprantl, davide Reviewed By: davide Subscribers: davide, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D48096 llvm-svn: 334557
* Add dependency on clang-headers when building LLDB.framework using CMakeAlex Langford2018-06-011-0/+3
| | | | | | | | | | | | | | | Summary: The LLDB.framework generated when building with CMake + Ninja/Make is completely missing the clang headers. Although the code to copy them exists, we don't even generate them unless we're building LLDB standalone. Reviewers: clayborg, labath, sas Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D47612 llvm-svn: 333777
* Remove lldb-private headers when building LLDB.framework with CMakeAlex Langford2018-05-291-2/+1
| | | | | | | | | | | | | | | | | | | | Summary: Generating LLDB.framework when building with CMake+Ninja will copy the lldb-private headers because public_headers contains them, even though we try to make sure they don't get copied by removing root_private_headers from root_public_headers. This patch also removes SystemInitializerFull.h from the LLDB.framework headers when building with CMake. Reviewers: compnerd, sas, labath, beanz, zturner Reviewed By: labath Subscribers: clayborg, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D47278 llvm-svn: 333444
* Fix LLVM_LINK_LLVM_DYLIB build (pr35053)Pavel Labath2017-10-311-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r316368 broke this build when it introduced a reference to a pthread function to the Utility module. This caused cmake to generate an incorrect link line (wrong order of libs) because it did not see the dependency from Utility to the system libraries. Instead these libraries were being manually added to each final target. This changes moves the dependency management from the individual targets to the lldbUtility module, which is consistent with how llvm does it. The final targets will pick up these libraries as they will be a part of the link interface of the module. Technically, some of these dependencies could go into the host module, as that's where most of the os-specific code is, but I did not try to investigate which ones. Reviewers: zturner, sylvestre.ledru Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D39246 llvm-svn: 316997
* Add new files to the cmake lists.Jim Ingham2017-09-141-0/+2
| | | | llvm-svn: 313293
* Expose process instance info via SB APIVadim Macagon2017-08-011-0/+1
| | | | | | | | | | | Summary: Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo, and add SBProcess::GetProcessInfo() to retrieve info like parent ID, group ID, user ID etc. from a live process. Differential Revision: https://reviews.llvm.org/D35881 llvm-svn: 309664
* [CMake] Add SharingPtr.h to the Framework header listChris Bieneman2017-07-281-1/+1
| | | | | | lldb-forward.h which is a public header uses SharingPtr, so we need to include that header as well. llvm-svn: 309429
* [CMake] Cleanup of header fixup and installationChris Bieneman2017-07-281-11/+7
| | | | | | | | | | This patch does the following: * Gets the header copy step to re-run whenever header change * Gets the header fix-up step to re-run whenever headers are copied * Removes lldb-private*.h headers from the installed headers llvm-svn: 309394
* [CMake] Update Framework construction for iOSChris Bieneman2017-07-251-6/+12
| | | | | | On iOS frameworks don't have versions or resources, they are flatter bundles. This updates the LLDB framework build to accommodate the flatter bundles. llvm-svn: 309025
* [CMake] Rework construction of framework bundleChris Bieneman2017-07-251-5/+27
| | | | | | This adds an explicit step for processing the headers and restructures how the framework bundles are constructed. This should make the frameworks more reliably constructed. llvm-svn: 309024
* Initial implementation of SB APIs for Tracing support.Ravitheja Addepally2017-04-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces new SB APIs for tracing support inside LLDB. The idea is to gather trace data from LLDB and provide it through this APIs to external tools integrating with LLDB. These tools will be responsible for interpreting and presenting the trace data to their users. The patch implements the following new SB APIs -> -> StartTrace - starts tracing with given parameters -> StopTrace - stops tracing. -> GetTraceData - read the trace data . -> GetMetaData - read the meta data assosciated with the trace. -> GetTraceConfig - read the trace configuration Tracing is associated with a user_id that is returned by the StartTrace API and this id needs to be used for accessing the trace data and also Stopping the trace. The user_id itself may map to tracing the complete process or just an individual thread. The APIs require an additional thread parameter when the user of these APIs wishes to perform thread specific manipulations on the tracing instances. The patch also includes the corresponding python wrappers for the C++ based APIs. Reviewers: k8stone, lldb-commits, clayborg Reviewed By: clayborg Subscribers: jingham, mgorny Differential Revision: https://reviews.llvm.org/D29581 llvm-svn: 301389
* [CMake] Adding API dependency on UtilityChris Bieneman2017-02-131-0/+1
| | | | | | Utility is directly referenced from API. llvm-svn: 294986
* [CMake] Final dependency cleanup patch!Chris Bieneman2017-02-081-0/+17
| | | | | | | | | | | | | | | | | Summary: This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool. This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too. Help testing would be greatly appreciated. Reviewers: labath, zturner Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits Differential Revision: https://reviews.llvm.org/D29352 llvm-svn: 294515
* [CMake] Only support LLDB_BUILD_FRAMEWORK on CMake 3.7 and laterChris Bieneman2016-12-151-17/+8
| | | | | | | | | | CMake's framework target generation was unable to generate POST_BUILD steps (see: https://gitlab.kitware.com/cmake/cmake/issues/16363). It turns out working around this is really not reasonable. The more reasonable solution to me is just to not support LLDB.framework unless you are on CMake 3.7 or newer. Since CMake 3.7.1 is released that's how I'm going to handle this. llvm-svn: 289841
* [CMake] Populate the build directory's frameworkChris Bieneman2016-10-311-3/+9
| | | | | | | | This ensures that the Resources and clang headers are properly symlinked in LLDB's framework. This should fix the modules-related tests when building on Darwin with CMake if you are building a framework. I have another fix coming which gets them working on Darwin if you're building liblldb instead of a framework. llvm-svn: 285651
* Limit LLDB_EXPORT_ALL_SYMBOLS to lldb symbolsTodd Fiala2016-10-291-6/+3
| | | | | | | | | | | | | | | | | | | LLDB_EXPORT_ALL_SYMBOLS used to instruct the build to export all the symbols in liblldb on CMake builds. This change limits the CMake define to only add in the lldb_private namespace to the symbols that normally get exported, such that we export all the symbols in the public lldb namespace and the lldb_private namespace. This is a fix for: https://llvm.org/bugs/show_bug.cgi?id=30822 Reviewers: labath, beanz Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26093 llvm-svn: 285484
* [CMake] Populate LLDB.framework's headers directoryChris Bieneman2016-10-141-1/+17
| | | | | | | | | | | | | | | | | Summary: This patch adds support for installing public headers in LLDB.framework, and symlinking the headers into the build directory. While writing the patch I discovered a bug in CMake that prevents applying POST_BUILD steps to framework targets (https://gitlab.kitware.com/cmake/cmake/issues/16363). I've implemented the support using POST_BUILD steps wrapped under a CMake version check with a TODO so that we can track the fix. Reviewers: tfiala, zturner, spyffe Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D25570 llvm-svn: 284250
* Disable warnings in LLDBWrapPython.cpp with -Werror.Zachary Turner2016-10-051-0/+8
| | | | | | | | | | | When -Werror is used, we don't have control over the generated code from SWIG, and it often has warnings. Just disable them for this file when -Werror is used, they are usually not important anyway. Differential revision: https://reviews.llvm.org/D25246 llvm-svn: 283343
* [CMake] Initial support for LLDB.frameworkChris Bieneman2016-09-211-0/+14
| | | | | | | | | | | | | | | | | | | Summary: This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library. With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow. The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step. With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up. Reviewers: zturner, tfiala Subscribers: beanz, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D24749 llvm-svn: 282110
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-0/+1
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
OpenPOWER on IntegriCloud