1Building 2======== 3 4.. contents:: 5 :local: 6 7Getting the Sources 8------------------- 9 10Please refer to the `LLVM Getting Started Guide 11<https://llvm.org/docs/GettingStarted.html#getting-started-with-llvm>`_ for 12general instructions on how to check out the LLVM monorepo, which contains the 13LLDB sources. 14 15Git browser: https://github.com/llvm/llvm-project/tree/master/lldb 16 17Preliminaries 18------------- 19 20LLDB relies on many of the technologies developed by the larger LLVM project. 21In particular, it requires both Clang and LLVM itself in order to build. Due to 22this tight integration the Getting Started guides for both of these projects 23come as prerequisite reading: 24 25* `LLVM <https://llvm.org/docs/GettingStarted.html>`_ 26* `Clang <http://clang.llvm.org/get_started.html>`_ 27 28The following requirements are shared on all platforms. 29 30* `CMake <https://cmake.org>`_ 31* `Ninja <https://ninja-build.org>`_ (strongly recommended) 32 33If you want to run the test suite, you'll need to build LLDB with Python 34scripting support. 35 36* `Python <http://www.python.org/>`_ 37* `SWIG <http://swig.org/>`_ 38 39Optional Dependencies 40********************* 41 42Although the following dependencies are optional, they have a big impact on 43LLDB's functionality. It is strongly encouraged to build LLDB with these 44dependencies enabled. 45 46By default they are auto-detected: if CMake can find the dependency it will be 47used. It is possible to override this behavior by setting the corresponding 48CMake flag to ``On`` or ``Off`` to force the dependency to be enabled or 49disabled. When a dependency is set to ``On`` and can't be found it will cause a 50CMake configuration error. 51 52+-------------------+------------------------------------------------------+--------------------------+ 53| Feature | Description | CMake Flag | 54+===================+======================================================+==========================+ 55| Editline | Generic line editing, history, Emacs and Vi bindings | ``LLDB_ENABLE_LIBEDIT`` | 56+-------------------+------------------------------------------------------+--------------------------+ 57| Curses | Text user interface | ``LLDB_ENABLE_CURSES`` | 58+-------------------+------------------------------------------------------+--------------------------+ 59| LZMA | Lossless data compression | ``LLDB_ENABLE_LZMA`` | 60+-------------------+------------------------------------------------------+--------------------------+ 61| Libxml2 | XML | ``LLDB_ENABLE_LIBXML2`` | 62+-------------------+------------------------------------------------------+--------------------------+ 63| Python | Python scripting | ``LLDB_ENABLE_PYTHON`` | 64+-------------------+------------------------------------------------------+--------------------------+ 65| Lua | Lua scripting | ``LLDB_ENABLE_LUA`` | 66+-------------------+------------------------------------------------------+--------------------------+ 67 68Depending on your platform and package manager, one might run any of the 69commands below. 70 71:: 72 73 > yum install libedit-devel libxml2-devel ncurses-devel python-devel swig 74 > sudo apt-get install build-essential subversion swig python2.7-dev libedit-dev libncurses5-dev 75 > pkg install swig python 76 > pkgin install swig python27 cmake ninja-build 77 > brew install swig cmake ninja 78 79Windows 80******* 81 82* Visual Studio 2015 or greater 83* Windows SDK 8.0 or higher. In general it is best to use the latest available 84 version. 85* `GnuWin32 <http://gnuwin32.sourceforge.net/>`_ 86* `Python 3.5 or higher <https://www.python.org/downloads/windows/>`_ or 87 higher. Earlier versions of Python can be made to work by compiling your own 88 distribution from source, but this workflow is unsupported and you are own 89 your own. 90* `Python Tools for Visual Studio 91 <https://github.com/Microsoft/PTVS/releases>`_. If you plan to debug test 92 failures or even write new tests at all, PTVS is an indispensable debugging 93 extension to VS that enables full editing and debugging support for Python 94 (including mixed native/managed debugging) 95 96The steps outlined here describes how to set up your system and install the 97required dependencies such that they can be found when needed during the build 98process. They only need to be performed once. 99 100#. Install Visual Studio and the Windows SDK. 101#. Install GnuWin32, making sure ``<GnuWin32 install dir>\bin`` is added to 102 your PATH environment variable. 103#. Install SWIG for Windows, making sure ``<SWIG install dir>`` is added to 104 your PATH environment variable. 105 106Any command prompt from which you build LLDB should have a valid Visual Studio 107environment setup. This means you should run ``vcvarsall.bat`` or open an 108appropriate Visual Studio Command Prompt corresponding to the version you wish 109to use. 110 111macOS 112***** 113 114* To use the in-tree debug server on macOS, lldb needs to be code signed. For 115 more information see :ref:`CodeSigning` below. 116* If you are building both Clang and LLDB together, be sure to also check out 117 libc++, which is a required for testing on macOS. 118 119Building LLDB with CMake 120------------------------ 121 122The LLVM project is migrating to a single monolithic respository for LLVM and 123its subprojects. This is the recommended way to build LLDB. Check out the 124source-tree with git: 125 126:: 127 128 > git clone https://github.com/llvm/llvm-project.git 129 130CMake is a cross-platform build-generator tool. CMake does not build the 131project, it generates the files needed by your build tool. The recommended 132build tool for LLVM is Ninja, but other generators like Xcode or Visual Studio 133may be used as well. Please also read `Building LLVM with CMake 134<https://llvm.org/docs/CMake.html>`_. 135 136Regular in-tree builds 137********************** 138 139Create a new directory for your build-tree. From there run CMake and point it 140to the ``llvm`` directory in the source-tree: 141 142:: 143 144 > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [<cmake options>] path/to/llvm-project/llvm 145 146We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which 147subprojects to build in addition to LLVM (for more options see 148:ref:`CommonCMakeOptions` and :ref:`CMakeCaches`). Parts of the LLDB test suite 149require ``lld``. Add it to the list in order to run all tests. Once CMake is done, 150run ninja to perform the actual build. We pass ``lldb`` here as the target, so 151it only builds what is necessary to run the lldb driver: 152 153:: 154 155 > ninja lldb 156 157Standalone builds 158***************** 159 160This is another way to build LLDB. We can use the same source-tree as we 161checked out above, but now we will have multiple build-trees: 162 163* the main build-tree for LLDB in ``/path/to/lldb-build`` 164* one or more provided build-trees for LLVM and Clang; for simplicity we use a 165 single one in ``/path/to/llvm-build`` 166 167Run CMake with ``-B`` pointing to a new directory for the provided 168build-tree\ :sup:`1` and the positional argument pointing to the ``llvm`` 169directory in the source-tree. Note that we leave out LLDB here and only include 170Clang. Then we build the ``ALL`` target with ninja: 171 172:: 173 174 > cmake -B /path/to/llvm-build -G Ninja \ 175 -DLLVM_ENABLE_PROJECTS=clang \ 176 [<more cmake options>] /path/to/llvm-project/llvm 177 > ninja 178 179Now run CMake a second time with ``-B`` pointing to a new directory for the 180main build-tree and the positional argument pointing to the ``lldb`` directory 181in the source-tree. In order to find the provided build-tree, the build system 182looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate 183build directory for Clang, remember to pass its module path via ``Clang_DIR`` 184(CMake variables are case-sensitive!): 185 186:: 187 188 > cmake -B /path/to/lldb-build -G Ninja \ 189 -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \ 190 [<more cmake options>] /path/to/llvm-project/lldb 191 > ninja lldb 192 193.. note:: 194 195 #. The ``-B`` argument was undocumented for a while and is only officially 196 supported since `CMake version 3.14 197 <https://cmake.org/cmake/help/v3.14/release/3.14.html#command-line>`_ 198 199.. _CommonCMakeOptions: 200 201Common CMake options 202******************** 203 204Following is a description of some of the most important CMake variables which 205you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to 206the CMake command line. 207 208If you want to debug the lldb that you're building -- that is, build it with 209debug info enabled -- pass two additional arguments to cmake before running 210ninja: 211 212:: 213 214 > cmake -G Ninja \ 215 -DLLDB_EXPORT_ALL_SYMBOLS=1 \ 216 -DCMAKE_BUILD_TYPE=Debug 217 <path to root of llvm source tree> 218 219If you want to run the test suite, you will need a compiler to build the test 220programs. If you have Clang checked out, that will be used by default. 221Alternatively, you can specify a C and C++ compiler to be used by the test 222suite. 223 224:: 225 226 > cmake -G Ninja \ 227 -DLLDB_TEST_COMPILER=<path to C compiler> \ 228 <path to root of llvm source tree> 229 230It is strongly recommend to use a release build for the compiler to speed up 231test execution. 232 233Windows 234^^^^^^^ 235 236On Windows the LLDB test suite requires lld. Either add ``lld`` to 237``LLVM_ENABLE_PROJECTS`` or disable the test suite with 238``LLDB_ENABLE_TESTS=OFF``. 239 240Although the following CMake variables are by no means Windows specific, they 241are commonly used on Windows. 242 243* ``LLDB_TEST_DEBUG_TEST_CRASHES`` (Default=0): If set to 1, will cause Windows 244 to generate a crash dialog whenever lldb.exe or the python extension module 245 crashes while running the test suite. If set to 0, LLDB will silently crash. 246 Setting to 1 allows a developer to attach a JIT debugger at the time of a 247 crash, rather than having to reproduce a failure or use a crash dump. 248* ``PYTHON_HOME`` (Required): Path to the folder where the Python distribution 249 is installed. For example, ``C:\Python35``. 250* ``LLDB_RELOCATABLE_PYTHON`` (Default=0): When this is 0, LLDB will bind 251 statically to the location specified in the ``PYTHON_HOME`` CMake variable, 252 ignoring any value of ``PYTHONHOME`` set in the environment. This is most 253 useful for developers who simply want to run LLDB after they build it. If you 254 wish to move a build of LLDB to a different machine where Python will be in a 255 different location, setting ``LLDB_RELOCATABLE_PYTHON`` to 1 will cause 256 Python to use its default mechanism for finding the python installation at 257 runtime (looking for installed Pythons, or using the ``PYTHONHOME`` 258 environment variable if it is specified). 259 260Sample command line: 261 262:: 263 264 > cmake -G Ninja^ 265 -DLLDB_TEST_DEBUG_TEST_CRASHES=1^ 266 -DPYTHON_HOME=C:\Python35^ 267 -DLLDB_TEST_COMPILER=d:\src\llvmbuild\ninja_release\bin\clang.exe^ 268 <path to root of llvm source tree> 269 270 271Building with ninja is both faster and simpler than building with Visual Studio, 272but chances are you still want to debug LLDB with an IDE. One solution is to run 273cmake twice and generate the output into two different folders. One for 274compiling (the ninja folder), and one for editing, browsing and debugging. 275 276Follow the previous instructions in one directory, and generate a Visual Studio 277project in another directory. 278 279:: 280 281 > cmake -G "Visual Studio 15 2017 Win64" -Thost=x64 <cmake variables> <path to root of llvm source tree> 282 283Then you can open the .sln file in Visual Studio, set lldb as the startup 284project, and use F5 to run it. You need only edit the project settings to set 285the executable and the working directory to point to binaries inside of the 286ninja tree. 287 288 289NetBSD 290^^^^^^ 291 292Current stable NetBSD release doesn't ship with libpanel(3), therefore it's 293required to disable curses(3) support with the 294``-DLLDB_ENABLE_CURSES:BOOL=FALSE`` option. To make sure check if 295``/usr/include/panel.h`` exists in your system. 296 297macOS 298^^^^^ 299 300On macOS the LLDB test suite requires libc++. Either add ``libcxx`` to 301``LLVM_ENABLE_PROJECTS`` or disable the test suite with 302``LLDB_ENABLE_TESTS=OFF``. Further useful options: 303 304* ``LLDB_BUILD_FRAMEWORK:BOOL``: Builds the LLDB.framework. 305* ``LLDB_CODESIGN_IDENTITY:STRING``: Set the identity to use for code-signing 306 all executables. If not explicitly specified, only ``debugserver`` will be 307 code-signed with identity ``lldb_codesign`` (see :ref:`CodeSigning`). 308* ``LLDB_USE_SYSTEM_DEBUGSERVER:BOOL``: Use the system's debugserver, so lldb is 309 functional without setting up code-signing. 310 311 312.. _CMakeCaches: 313 314CMake caches 315************ 316 317CMake caches allow to store common sets of configuration options in the form of 318CMake scripts and can be useful to reproduce builds for particular use-cases 319(see by analogy `usage in LLVM and Clang <https://llvm.org/docs/AdvancedBuilds.html>`_). 320A cache is passed to CMake with the ``-C`` flag, following the absolute path to 321the file on disk. Subsequent ``-D`` options are still allowed. Please find the 322currently available caches in the `lldb/cmake/caches/ 323<https://github.com/llvm/llvm-project/tree/master/lldb/cmake/caches>`_ 324directory. 325 326Common configurations on macOS 327^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 328 329Build, test and install a distribution of LLDB from the `monorepo 330<https://github.com/llvm/llvm-project>`_ (see also `Building a Distribution of 331LLVM <https://llvm.org/docs/BuildingADistribution.html>`_): 332 333:: 334 335 > git clone https://github.com/llvm/llvm-project 336 337 > cmake -B /path/to/lldb-build -G Ninja \ 338 -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake \ 339 -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb" \ 340 llvm-project/llvm 341 342 > DESTDIR=/path/to/lldb-install ninja -C /path/to/lldb-build check-lldb install-distribution 343 344.. _CMakeGeneratedXcodeProject: 345 346Build LLDB standalone for development with Xcode: 347 348:: 349 350 > git clone https://github.com/llvm/llvm-project 351 352 > cmake -B /path/to/llvm-build -G Ninja \ 353 -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-base.cmake \ 354 -DLLVM_ENABLE_PROJECTS="clang;libcxx" \ 355 llvm-project/llvm 356 > ninja -C /path/to/llvm-build 357 358 > cmake -B /path/to/lldb-build \ 359 -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \ 360 -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \ 361 llvm-project/lldb 362 > open lldb.xcodeproj 363 > cmake --build /path/to/lldb-build --target check-lldb 364 365.. note:: 366 367 The ``-B`` argument was undocumented for a while and is only officially 368 supported since `CMake version 3.14 369 <https://cmake.org/cmake/help/v3.14/release/3.14.html#command-line>`_ 370 371 372Building the Documentation 373-------------------------- 374 375If you wish to build the optional (reference) documentation, additional 376dependencies are required: 377 378* Sphinx (for the website) 379* Graphviz (for the 'dot' tool) 380* doxygen (if you wish to build the C++ API reference) 381* epydoc (if you wish to build the Python API reference) 382 383To install the prerequisites for building the documentation (on Debian/Ubuntu) 384do: 385 386:: 387 388 > sudo apt-get install doxygen graphviz python3-sphinx 389 > sudo pip install epydoc 390 391To build the documentation, configure with ``LLVM_ENABLE_SPHINX=ON`` and build the desired target(s). 392 393:: 394 395 > ninja docs-lldb-html 396 > ninja docs-lldb-man 397 > ninja lldb-cpp-doc 398 > ninja lldb-python-doc 399 400Cross-compiling LLDB 401-------------------- 402 403In order to debug remote targets running different architectures than your 404host, you will need to compile LLDB (or at least the server component) for the 405target. While the easiest solution is to just compile it locally on the target, 406this is often not feasible, and in these cases you will need to cross-compile 407LLDB on your host. 408 409Cross-compilation is often a daunting task and has a lot of quirks which depend 410on the exact host and target architectures, so it is not possible to give a 411universal guide which will work on all platforms. However, here we try to 412provide an overview of the cross-compilation process along with the main things 413you should look out for. 414 415First, you will need a working toolchain which is capable of producing binaries 416for the target architecture. Since you already have a checkout of clang and 417lldb, you can compile a host version of clang in a separate folder and use 418that. Alternatively you can use system clang or even cross-gcc if your 419distribution provides such packages (e.g., ``g++-aarch64-linux-gnu`` on 420Ubuntu). 421 422Next, you will need a copy of the required target headers and libraries on your 423host. The libraries can be usually obtained by copying from the target machine, 424however the headers are often not found there, especially in case of embedded 425platforms. In this case, you will need to obtain them from another source, 426either a cross-package if one is available, or cross-compiling the respective 427library from source. Fortunately the list of LLDB dependencies is not big and 428if you are only interested in the server component, you can reduce this even 429further by passing the appropriate cmake options, such as: 430 431:: 432 433 -DLLDB_ENABLE_PYTHON=0 434 -DLLDB_ENABLE_LIBEDIT=0 435 -DLLDB_ENABLE_CURSES=0 436 -DLLVM_ENABLE_TERMINFO=0 437 438In this case you, will often not need anything other than the standard C and 439C++ libraries. 440 441Once all of the dependencies are in place, it's just a matter of configuring 442the build system with the locations and arguments of all the necessary tools. 443The most important cmake options here are: 444 445* ``CMAKE_CROSSCOMPILING`` : Set to 1 to enable cross-compilation. 446* ``CMAKE_LIBRARY_ARCHITECTURE`` : Affects the cmake search path when looking 447 for libraries. You may need to set this to your architecture triple if you do 448 not specify all your include and library paths explicitly. 449* ``CMAKE_C_COMPILER``, ``CMAKE_CXX_COMPILER`` : C and C++ compilers for the 450 target architecture 451* ``CMAKE_C_FLAGS``, ``CMAKE_CXX_FLAGS`` : The flags for the C and C++ target 452 compilers. You may need to specify the exact target cpu and abi besides the 453 include paths for the target headers. 454* ``CMAKE_EXE_LINKER_FLAGS`` : The flags to be passed to the linker. Usually 455 just a list of library search paths referencing the target libraries. 456* ``LLVM_TABLEGEN``, ``CLANG_TABLEGEN`` : Paths to llvm-tblgen and clang-tblgen 457 for the host architecture. If you already have built clang for the host, you 458 can point these variables to the executables in your build directory. If not, 459 you will need to build the llvm-tblgen and clang-tblgen host targets at 460 least. 461* ``LLVM_HOST_TRIPLE`` : The triple of the system that lldb (or lldb-server) 462 will run on. Not setting this (or setting it incorrectly) can cause a lot of 463 issues with remote debugging as a lot of the choices lldb makes depend on the 464 triple reported by the remote platform. 465 466You can of course also specify the usual cmake options like 467``CMAKE_BUILD_TYPE``, etc. 468 469Example 1: Cross-compiling for linux arm64 on Ubuntu host 470********************************************************* 471 472Ubuntu already provides the packages necessary to cross-compile LLDB for arm64. 473It is sufficient to install packages ``gcc-aarch64-linux-gnu``, 474``g++-aarch64-linux-gnu``, ``binutils-aarch64-linux-gnu``. Then it is possible 475to prepare the cmake build with the following parameters: 476 477:: 478 479 -DCMAKE_CROSSCOMPILING=1 \ 480 -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \ 481 -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \ 482 -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-gnu \ 483 -DLLVM_TABLEGEN=<path-to-host>/bin/llvm-tblgen \ 484 -DCLANG_TABLEGEN=<path-to-host>/bin/clang-tblgen \ 485 -DLLDB_ENABLE_PYTHON=0 \ 486 -DLLDB_ENABLE_LIBEDIT=0 \ 487 -DLLDB_ENABLE_CURSES=0 488 489An alternative (and recommended) way to compile LLDB is with clang. 490Unfortunately, clang is not able to find all the include paths necessary for a 491successful cross-compile, so we need to help it with a couple of CFLAGS 492options. In my case it was sufficient to add the following arguments to 493``CMAKE_C_FLAGS`` and ``CMAKE_CXX_FLAGS`` (in addition to changing 494``CMAKE_C(XX)_COMPILER`` to point to clang compilers): 495 496:: 497 498 -target aarch64-linux-gnu \ 499 -I /usr/aarch64-linux-gnu/include/c++/4.8.2/aarch64-linux-gnu \ 500 -I /usr/aarch64-linux-gnu/include 501 502If you wanted to build a full version of LLDB and avoid passing 503``-DLLDB_ENABLE_PYTHON=0`` and other options, you would need to obtain the 504target versions of the respective libraries. The easiest way to achieve this is 505to use the qemu-debootstrap utility, which can prepare a system image using 506qemu and chroot to simulate the target environment. Then you can install the 507necessary packages in this environment (python-dev, libedit-dev, etc.) and 508point your compiler to use them using the correct -I and -L arguments. 509 510Example 2: Cross-compiling for Android on Linux 511*********************************************** 512 513In the case of Android, the toolchain and all required headers and libraries 514are available in the Android NDK. 515 516The NDK also contains a cmake toolchain file, which makes configuring the build 517much simpler. The compiler, include and library paths will be configured by the 518toolchain file and all you need to do is to select the architecture 519(ANDROID_ABI) and platform level (``ANDROID_PLATFORM``, should be at least 21). 520You will also need to set ``ANDROID_ALLOW_UNDEFINED_SYMBOLS=On``, as the 521toolchain file defaults to "no undefined symbols in shared libraries", which is 522not compatible with some llvm libraries. The first version of NDK which 523supports this approach is r14. 524 525For example, the following arguments are sufficient to configure an android 526arm64 build: 527 528:: 529 530 -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake \ 531 -DANDROID_ABI=arm64-v8a \ 532 -DANDROID_PLATFORM=android-21 \ 533 -DANDROID_ALLOW_UNDEFINED_SYMBOLS=On \ 534 -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android \ 535 -DCROSS_TOOLCHAIN_FLAGS_NATIVE='-DCMAKE_C_COMPILER=cc;-DCMAKE_CXX_COMPILER=c++' 536 537Note that currently only lldb-server is functional on android. The lldb client 538is not supported and unlikely to work. 539 540Verifying Python Support 541------------------------ 542 543LLDB has a Python scripting capability and supplies its own Python module named 544lldb. If a script is run inside the command line lldb application, the Python 545module is made available automatically. However, if a script is to be run by a 546Python interpreter outside the command line application, the ``PYTHONPATH`` 547environment variable can be used to let the Python interpreter find the lldb 548module. 549 550The correct path can be obtained by invoking the command line lldb tool with 551the -P flag: 552 553:: 554 555 > export PYTHONPATH=`$llvm/build/Debug+Asserts/bin/lldb -P` 556 557If you used a different build directory or made a release build, you may need 558to adjust the above to suit your needs. To test that the lldb Python module is 559built correctly and is available to the default Python interpreter, run: 560 561:: 562 563 > python -c 'import lldb' 564 565 566Make sure you're using the Python interpreter that matches the Python library 567you linked against. For more details please refer to the :ref:`caveats 568<python_caveat>`. 569 570.. _CodeSigning: 571 572Code Signing on macOS 573--------------------- 574 575To use the in-tree debug server on macOS, lldb needs to be code signed. The 576Debug, DebugClang and Release builds are set to code sign using a code signing 577certificate named ``lldb_codesign``. This document explains how to set up the 578signing certificate. 579 580Note that it's possible to build and use lldb on macOS without setting up code 581signing by using the system's debug server. To configure lldb in this way with 582cmake, specify ``-DLLDB_USE_SYSTEM_DEBUGSERVER=ON``. 583 584If you have re-installed a new OS, please delete all old ``lldb_codesign`` items 585from your keychain. There will be a code signing certification and a public 586and private key. Reboot after deleting them. You will also need to delete and 587build folders that contained old signed items. The darwin kernel will cache 588code signing using the executable's file system node, so you will need to 589delete the file so the kernel clears its cache. 590 591Automatic setup: 592 593* Run ``scripts/macos-setup-codesign.sh`` 594 595Manual setup steps: 596 597* Launch /Applications/Utilities/Keychain Access.app 598* In Keychain Access select the ``login`` keychain in the ``Keychains`` list in 599 the upper left hand corner of the window. 600* Select the following menu item: Keychain Access->Certificate Assistant->Create a Certificate... 601* Set the following settings 602 603:: 604 605 Name = lldb_codesign 606 Identity Type = Self Signed Root 607 Certificate Type = Code Signing 608 609* Click Create 610* Click Continue 611* Click Done 612* Click on the "My Certificates" 613* Double click on your new ``lldb_codesign`` certificate 614* Turn down the "Trust" disclosure triangle, scroll to the "Code Signing" trust 615 pulldown menu and select "Always Trust" and authenticate as needed using your 616 username and password. 617* Drag the new ``lldb_codesign`` code signing certificate (not the public or 618 private keys of the same name) from the ``login`` keychain to the ``System`` 619 keychain in the Keychains pane on the left hand side of the main Keychain 620 Access window. This will move this certificate to the ``System`` keychain. 621 You'll have to authorize a few more times, set it to be "Always trusted" when 622 asked. 623* Remove ``~/Desktop/lldb_codesign.cer`` file on your desktop if there is one. 624* In the Keychain Access GUI, click and drag ``lldb_codesign`` in the 625 ``System`` keychain onto the desktop. The drag will create a 626 ``Desktop/lldb_codesign.cer`` file used in the next step. 627* Switch to Terminal, and run the following: 628 629:: 630 631 sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/lldb_codesign.cer 632 rm -f ~/Desktop/lldb_codesign.cer 633 634* Drag the ``lldb_codesign`` certificate from the ``System`` keychain back into 635 the ``login`` keychain 636* Quit Keychain Access 637* Reboot 638* Clean by removing all previously creating code signed binaries and rebuild 639 lldb and you should be able to debug. 640 641When you build your LLDB for the first time, the Xcode GUI will prompt you for 642permission to use the ``lldb_codesign`` keychain. Be sure to click "Always 643Allow" on your first build. From here on out, the ``lldb_codesign`` will be 644trusted and you can build from the command line without having to authorize. 645Also the first time you debug using a LLDB that was built with this code 646signing certificate, you will need to authenticate once. 647