Relands the commit to upstream the lldb-rpc-gen tool in order to fix a
build failure on the linux remote bots. The reland adds the Clang
resource dir unconditionally to the invocation for the tool instead of
only adding it in the event that we're using a standalone build.
Original PR description:
This commit upstreams the lldb-rpc-gen tool, a ClangTool that generates
the LLDB RPC client and server interfaces. This tool, as well as LLDB
RPC itself is built by default. If it needs to be disabled, put
-DLLDB_BUILD_LLDBRPC=OFF in your CMake invocation.
https://discourse.llvm.org/t/rfc-upstreaming-lldb-rpc/85804
Original PR Link:
https://github.com/llvm/llvm-project/pull/138031
Reverts llvm/llvm-project#138031. This is failing during the build phase
on the Ubuntu buildbot:
```
Error while processing /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBWatchpoint.h.
[78/78] Processing file /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBWatchpointOptions.h.
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-class-memaccess'; did you mean '-Wno-class-varargs'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-format-truncation'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-class-memaccess'; did you mean '-Wno-class-varargs'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-format-truncation'? [-Wunknown-warning-option]
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBWatchpointOptions.h:12:
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBDefines.h:12:
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/lldb-defines.h:12:
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/lldb-types.h:12:
/home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/lldb-enumerations.h:12:10: fatal error: 'cstdint' file not found
12 | #include <cstdint>
| ^~~~~~~~~
```
This commit upstreams the `lldb-rpc-gen` tool, a ClangTool that
generates the LLDB RPC client and server interfaces. This tool, as well
as LLDB RPC itself is built by default. If it needs to be disabled, put
-DLLDB_BUILD_LLDBRPC=OFF in your CMake invocation.
https://discourse.llvm.org/t/rfc-upstreaming-lldb-rpc/85804
There's 2 bugs that this commit fixes:
1. Calculate the correct file path for the output file by appending the
basename of the input header instead of appending the entire input
header's path to the framework path.
2. In the script, create the framework's header directory if it does not
exist.
Some inter-plugin dependencies are okay, others are not. Yet others not,
but we're sort of stuck with them. The idea is to be able to prevent
backsliding while making sure that acceptable dependencies are..
accepted. For context, see
https://github.com/llvm/llvm-project/pull/139170 and the attached
changes to the documentation.
This PR adds an MCP (Model Context Protocol ) server to LLDB. For
motivation and background, please refer to the corresponding RFC:
https://discourse.llvm.org/t/rfc-adding-mcp-support-to-lldb/86798
I implemented this as a new kind of plugin. The idea is that we could
support multiple protocol servers (e.g. if we want to support DAP from
within LLDB). This also introduces a corresponding top-level command
(`protocol-server`) with two subcommands to `start` and `stop` the
server.
```
(lldb) protocol-server start MCP tcp://localhost:1234
MCP server started with connection listeners: connection://[::1]:1234, connection://[127.0.0.1]:1234
```
The MCP sever supports one tool (`lldb_command`) which executes a
command, but can easily be extended with more commands.
When testing LLDB, we want to make sure to use the same Python as the
one we used to build it.
This patch uses the CMake variable `Python3_ROOT_DIR` to add the correct
Python to the `PATH` in LLDB lit tests, in order to ensure of this.
Please see https://github.com/swiftlang/swift/pull/82063 for the
original issue.
This is a continuation of https://github.com/swiftlang/swift/pull/82063.
…ers" (#143941)
Reland the script that converts lldb headers to RPC headers. The RPC
test was failing due to the incorrect input filepath being used.
Original commit message:
This commit replaces the shell script that fixes up includes for the
LLDB framework with a Python script. This script will also be used when
fixing up includes for the LLDBRPC.framework.
This commit replaces the shell script that fixes up includes for the
LLDB framework with a Python script. This script will also be used when
fixing up includes for the LLDBRPC.framework.
This relands the original commit for the versioning script in LLDB. This
commit uses '>' for output from `unifdef` for platforms that have that
executable but do not have the `-o` option. It also fixes the Xcode
build by adding a dependency between the liblldb-header-staging target
in the source/API/CMakeLists.txt the `liblldb-resource-headers` target
in LLDBFramework.cmake.
Original patch: https://github.com/llvm/llvm-project/pull/141116
If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.
This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).
The Swift Windows toolchain uses its own static build of libxml 2, which
is more recent than 2.8, resulting in the provided libxml 2 to be
rejected. This change allows to specify a custom version for libxml 2,
while defaulting to 2.8.
In #138329, _GNU_SOURCE was added for Cygwin, but when building Clang
standalone against an installed LLVM this definition was not picked up,
resulting in undefined strnlen. Follow the documentation in
https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project and add
the LLVM_DEFINITIONS in standalone projects' cmakes.
We want to be able to access the Clang resources directory in LLDB shell
tests, this commit adds the ability to do this by populating the
`CLANG_RESOURCE_DIR` variable in LLDBConfig.cmake.
For some operating systems (e.g. chromiumos), terminfo is a separate
package and library from ncurses. Both are still requirements for curses
support in lldb, individually.
This is a rework of this original spack commit:
9ea2612650
Instead though, this PR uses CMake to detect whether the symbol is
present and defined in the curses library, and only falls back to a separate
tinfo if not found.
Without this fix, LLDB cannot be built on these systems.
Fixes#101368
Clean up some unnecessary include paths. The use of `LibXml2::LibXml2`
with `target_link_libraries` on `libLLDBHost` ensures that the header
search path is properly propagated.
See
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731
for discussions.
This matches LLVM's requirement to run tests. For LLDB 20 there will be
a CMake warning telling builders that from LLDB 21 this will be a hard
requirement. From LLDB 21, it will be an error to try to build with
anything <= 3.8.
So there are no code changes in this commit. Once the llvm 20 branch is
created we can remove some < 3.8 support code.
As always, if you disable Python support you will not get any new
warnings or errors from this change.
Lua 5.3 and Lua 5.4 are similar enough that we can easily support both
in LLDB. This patch adds support for building LLDB with both and updates
the documentation accordingly.
Currently all of LLDB is being compiled with
-Wno-deprecated-declarations. That's not desirable, especially as part
of the LLVM monorepo, as we miss deprecation warnings from LLVM and
clang.
According to the git history, this was first introduced to suppress
warnings related to auto_ptr. Since then, other things have been
deprecated and gone unnoticed. This patch limits the flag to Host.mm
which uses a handful of LSApplication headers that have no replacement.
rdar://112040718
CMake -GXcode would otherwise offer to create one scheme for each
target, which ends up being a lot. For now, limit the default to the
`check-*` LIT targets, plus `ALL_BUILD` and `install`.
For targets that aren't in the default list, we now have a configuration
variable to promote an extra list of targets into schemes, for example
`-DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"` to
add schemes for `TargetParserTests` and `SupportTests` respectively.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
…db-resource-headers
The Xcode build otherwise fails with
```
CMake Error in source/API/CMakeLists.txt:
The custom command generating
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-standalone/lldb-xcode-build/include/lldb/API/SBLanguages.h
is attached to multiple targets:
lldb-sbapi-dwarf-enums
liblldb-resource-headers
but none of these is a common dependency of the other(s). This is not
allowed by the Xcode "new build system".
CMake Generate step failed. Build files cannot be regenerated correctly.
```
The `LLDB_TEST_USE_VENDOR_PACKAGES` has defaulted to `Off` for a while.
Either installing `pexpect` or skipping those tests with
`-DLLDB_TEST_USER_ARGS=--skip-category=pexpect` seems to be enough that
we can fully remove this option.
This patch removes the `LLDB_TEST_USE_VENDOR_PACKAGES` cmake
configuration as well as the associated code to add
`third_party/Python/module` to the python path. I'll do the actual
deletion of `third_party/Python/module` in a followup PR in the
(unlikely, I hope) event this commit needs to be reverted.
This includes the lldb-dap executable in the MacOS and Linux
distributions of Swift. Currently there is a commit in the Apple repo to
do this for just MacOS https://github.com/apple/llvm-project/pull/8176.
This PR extends this to both Linux and MacOS and brings the change
upstream.
@JDevlieghere @adrian-prantl
* It is possible to setup llvm-project builds without going through
`llvm/CMakeList.txt` so the fatal error handling should be smarter.
* Disable option on Apple style lldb-linux builds.
Building the Apple way turns off plugin support, meaning we don't need
to export unloadable symbols from all executables. While deadstripping
effects aren't expected to change, enabling this across all tools
prevents the creation of export tries. This saves us ~3.5 MB in just the
universal build of `clang`.
This switches the default of `LLDB_TEST_USE_VENDOR_PACKAGES` from `ON`
to `OFF` in preparation for eventually deleting it. All known LLDB
buildbots have this package installed, so flipping the default will
uncover any other users.
If this breaks anything, the preferred fix is to install `pexpect` on
the host system. The second fix is to build with cmake option
`-DLLDB_TEST_USE_VENDOR_PACKAGES=ON` as a temporary measure until
`pexpect` can be installed. If neither of those work, reverting this
patch is OK.
The goal here is to remove the third_party/Python/module tree, which
LLDB tests only use to `import pexpect`. This package is available on
`pip`, and I believe should not be hard to obtain.
However, in case it isn't easily available, deleting the tree right now
could cause disruption. This introduces a
`LLDB_TEST_USE_VENDOR_PACKAGES` cmake param that can be enabled, and the
tests will continue loading that tree. By default, it is enabled,
meaning there's really no change here. A followup change will disable it
by default once all known build bots are updated to include this
package. When disabled, an eager cmake check runs that makes sure
`pexpect` is available before waiting for the test to fail in an obscure
way.
Later, this option will go away, and when it does, we can delete the
tree too. Ideally this is not disruptive, and we can remove it in a week
or two.
Fixes several of these:
```
[3370/3822] Building CXX object tools\lldb\source\Plugins\Process\U...lldbPluginProcessUtility.dir\NativeRegisterContextDBReg_x86.cpp.ob
C:\git\llvm-project\lldb\source\Plugins\Process\Utility\NativeRegisterContextDBReg_x86.h(23): warning C4589: Constructor of abstract class 'lldb_private::NativeRegisterContextDBReg_x86' ignores initializer for virtual base class 'lldb_private::NativeRegisterContextRegisterInfo'
C:\git\llvm-project\lldb\source\Plugins\Process\Utility\NativeRegisterContextDBReg_x86.h(23): note: virtual base classes are only initialized by the most-derived type
```
