Second attempt at relanding the lldb-rpc-gen tool. This should fix 2
issues:
- An assert that was hitting when building on Linux. The assert would
hit in the server source emitter, specifically when attemping to
determine the storage size for a return type is that is a pointer, but
isn't a const char *, const char ** or void pointer.
The assert would hit when attempting to generate
SBAttachInfo::GetProcessPluginName, which returns a const char *
(meaning it shouldn't have been in the code block for the assert at
all). The reason that it was hitting the assert when generating this
function is that lldb_rpc_gen::TypeIsConstCharPtr was returning false
for this function even though it did return a const char *. This was
happening because when checking the return type for a const char *,
TypeIsConstCharPtr would only check that the underlying type was a
signed char. This failed on Linux (but was fine on Darwin), as the
underlying type also needs to be checked for being an unsigned char.
- Cross compiling support
The build for lldb-rpc-gen had no support for cross compiling and as
such, the sources generated for lldb-rpc-gen would get compiled too
early in phase 2 when cross compiling, before the Clang toolchain was
built and this led to an error when trying to include stdlib files. This
reland splits this build into 2 by building the tool first and then
compiling the sources in the second stage of the cross-compiled 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:
github.com/llvm/llvm-project/pull/138031
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
From https://github.com/llvm/llvm-project/pull/140761. `MsvcBuilder`
passed `/std:<value>` (if specified) after `--`, so the compiler would
interpret this as a file. This moves the argument before the `--`.
Remove lldb-repro which was used to run the test suite against a
reproducer. The corresponding functionality has been removed from LLDB
so there's no need for the tool anymore.
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake
flags to pass arguments for cross-compilation and remote running of both Shell&API tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with
remote execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. The recommended compiler for that is Clang.
---------
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
Use the packaging [1] module for parsing version numbers, instead of
pkg_resources which is distributed with setuptools. I recently switched
over to using the latter, knowing it was deprecated (in favor of the
packaging module) because it comes with Python out of the box. Newer
versions of setuptools have removed `pkg_resources` so we have to use
packaging.
[1] https://pypi.org/project/packaging/
The distutils package has been deprecated and was removed from Python
3.12. The migration page [1] advises to use the packaging module
instead. Since Python 3.6 that's vendored into pkg_resources.
[1] https://peps.python.org/pep-0632/#migration-advice
The distutils package has been deprecated and was removed from Python
3.12. The migration page [1] advises to use the packaging module
instead. Since Python 3.6 that's vendored into pkg_resources.
[1] https://peps.python.org/pep-0632/#migration-advice
Fix the bug where merge-fdata unconditionally outputs boltedcollection
line, regardless of whether input files have it set.
Test Plan:
Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this
fix.
This reverts commit fd5206cc55c820598d5145d799b18d66cc193356.
Fixing the test case would require some awkard %if use that I'm not
sure would even work, or splitting it into 2 copies that are almost
identical.
Instead, always add -m for clang, which allows it for all targets,
but not for gcc which does not.
This reverts commit 7c3603e1c162382b5c038b99e482e0689e1505aa.
Turns out when you ask for "clang" it also uses the GCC Builder class,
so I need to update some tests.
This option is definitely needed for x86_64, and is valid for PowerPC
and s390x too.
I'm using "in" because on Armv8 Linux the uname is actually "armv8l"
not just "arm".
Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:
s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/
Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/
This allows the LLDB Shell tests to succeed in (e.g. CI) environments where
system libraries are provided hermetically as a sysroot.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D151269
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
This patch adds test infrastructure to utilize the GNUstep runtime in the LLDB test suite and adds coverage for features that already work on Linux. These seem accidental in parts, but it's a good early baseline. On Windows nothing works yet. Please find the repository for the GNUstep ObjC runtime here: https://github.com/gnustep/libobjc2
GNUstep support is disabled by default. CMake configuration involves two variables:
* `LLDB_TEST_OBJC_GNUSTEP=On` enables GNUstep support in the test suite. It requires the libobjc2 shared library and headers to be found.
* `LLDB_TEST_OBJC_GNUSTEP=Off` disables GNUstep support in the test suite and resets associated cache values if necessary (default).
* `LLDB_TEST_OBJC_GNUSTEP_DIR` allows to pass a custom installation root.
Differential Revision: https://reviews.llvm.org/D146058
TestFrameFormatNameWithArgs.test is enabled only in case of native
compilation but is applicable in case of cross compilation too. So,
provision support for enabling it in case of both, native and cross
compilation.
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D140839
This patch makes build helper script build.py to use platform.uname for
machine/architecture detection. Visual studio environment when set using
various batch files like vcvars*.bat set PLATFORM environment variable
however VsDevCmd.bat does not set PLATFORM variable.
Differential Revision: https://reviews.llvm.org/D133011
Improve utility of `FileCheck` output when a shell test fails.
The conflict is from:
1. On failure, `FileCheck` prints 5 lines of context
2. Shell tests first source `lit-lldb-init`, having the effect of printing its contents
If a `FileCheck` failure happens at the beginning of the input, then the
context shown is the `lit-lldb-init`, as it's over 5 lines and is the first
thing printed. As the init contents are fairly static, and presumably
uninteresting to most test failures, it seems reasonable to not print it.
Unfortunately it's not possible to use the `--source-quietly` flag in the lldb
invocation, because it will quiet all other `--source` flags on the command
line, making many tests fail.
This fix is a level of indirection, where a new sibling file named
`lit-lldb-init-quiet` is created, and its static contents are:
```
command source -C --silent-run true lit-lldb-init
```
This achieves the result of loading `lit-lldb-init` quietly. The `-C` flag
loads the path relatively.
Differential Revision: https://reviews.llvm.org/D132694
Summary:
This is an essential piece of infrastructure for us to be
continuously testing debug info with BOLT. We can't only make changes
to a test repo because we need to change debuginfo tests to call BOLT,
hence, this diff needs to sit in our opensource repo. But when upstreaming
to LLVM, this should be kept BOLT-only outside of LLVM. When upstreaming,
we need to git diff and check all folders that are being modified by our
commits and discard this one (and leave as an internal diff).
To test BOLT in debuginfo tests, configure it with -DLLVM_TEST_BOLT=ON.
Then run check-lldb and check-debuginfo.
Manual rebase conflict history:
https://phabricator.intern.facebook.com/D29205224https://phabricator.intern.facebook.com/D29564078https://phabricator.intern.facebook.com/D33289118https://phabricator.intern.facebook.com/D34957174
Test Plan:
tested locally
Configured with:
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;compiler-rt;bolt;debuginfo-tests"
-DLLVM_TEST_BOLT=ON
Ran test suite with:
ninja check-debuginfo
ninja check-lldb
Reviewers: #llvm-bolt
Subscribers: ayermolo, phabricatorlinter
Differential Revision: https://phabricator.intern.facebook.com/D35317341
Tasks: T92898286
This reverts commit d9247cc84825539d346c74eb1379c6cb948d3a71.
With the Windows tests updated to expect .EXE suffixes. This changed
because shutil.which uses PATHEXT which will contain, amongst others,
"EXE".
Also I noticed the "." in ".exe" was the wildcard dot not literal
dot so I've escaped those.
In build.py we have our own find_executable that looks
a lot like the distutils one that I switched to shutil.which.
This find_executable isn't quite the same as shutil.which
so I've refactored it to call that in the correct way.
Note that the path passed to shutil.which is in the form that
PATH would be, meaning separators are allowed.
```
>>> shutil.which("gcc", path="/home/david.spickett:/bin")
'/bin/gcc'
```
We just need to make sure it doesn't ignore the existing PATH
and normalise the result if it does find the binary.
The .exe extension is automatically added to the binary name
if we are on Windows.
Depends on D124601
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124604
LIT skips various system environment variables while building test
config. It turns out that we require PLATFORM environment variable for
detection of x86 vs Arm windows platform.
This patch adds system environment variable PLATFORM into LIT test
config for detection of win32 Arm platform.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D113165
lit.util.which('link') picks up the wrong link.exe in git bash, leading
to this error:
# command stderr:
/usr/bin/link: extra operand '/LIBPATH:C:\\Progra....'
Try '/usr/bin/link --help' for more information.
Instead, assume that link.exe is next to cl.exe.
Differential Revision: https://reviews.llvm.org/D109832
This patch stops lit from looking on the PATH for clang, lld and other
users of use_llvm_tool (currently only the debuginfo-tests) unless the
call explicitly requests to opt into using the PATH. When not opting in,
tests will only look in the build directory.
See the mailing list thread starting from
https://lists.llvm.org/pipermail/llvm-dev/2021-May/150421.html.
See the review for details of why decisions were made about when still
to use the PATH.
Reviewed by: thopre
Differential Revision: https://reviews.llvm.org/D102630
lit has grown a feature where it stores the runtimes of all tests.
Normally, these times should be stored in the build directory, but
because our API tests have set test_exec_root to point to the source
tree, it has ended up polluting our checkout and led to the
.lit_test_times.txt being committed to the repository.
Delete this file, and adjust the exec root of API tests. I've also
needed to adjust the root of Shell tests, in order to avoid the two
overlapping.
LLDB is supposed to ask the Clang Driver what the default module cache path is
and then use that value as the default for the
`symbols.clang-modules-cache-path` setting. However, we use the property type
`String` to change `symbols.clang-modules-cache-path` even though the type of
that setting is `FileSpec`, so the setter will simply do nothing and return
`false`. We also don't check the return value of the setter, so this whole code
ends up not doing anything at all.
This changes the setter to use the correct property type and adds an assert that
we actually successfully set the default path. Also adds a test that checks that
the default value for this setting is never unset/empty path as this would
effectively disable the import-std-module feature from working by default.
Reviewed By: JDevlieghere, shafik
Differential Revision: https://reviews.llvm.org/D92772
It seems that TestErrorMessages.test is failing on the standalone + Xcode builds
as lldb-server executable can't be found by lit's default PATH search. I assume
invoking lldb-server via a lit substitution gets this working again as
everything else is working, so that's what this patch is doing.
I had to add the lldb-server substitution as the test seems lldb-server specific
and we don't want it to default to debugserver on Darwin.
Using a substitution also seems in general like a good idea so that the commands
lit is printing on failure are using the full path to lldb-server and can be
re-run in a terminal.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91155
Refuse to run the shell tests when %lldb cannot be substituted. This
prevents the test from silently running again the `lldb` in your PATH.
I noticed because when this happens, %lldb-init gets substituted with
lldb-init, which does not exists.
On macOS 11, system libraries which are part of the shared cache
are not present on the filesystem anymore. This causes issues
with build.py, because it fails to link binaries with libSystem
or libc++.
The real issue is that build.py was not passing an SDK to the
compiler. The script accepts an argument for the SDK, but it
is currently unused. This patch just threads the SDK through
to the compile and link steps and this fixes a bunch of Shell
test failures on very recent macOS builds.
The convention is that the dwp file name is derived from the name of the
file holding the executable code, even if the linked portion of the
debug info is elsewhere (objcopy --only-keep-debug).
This change will bring lldb-vscode in line with how several other llvm
tools process command line arguments and make it easier to add future
options.
Differential revision: https://reviews.llvm.org/D74798
Explicitly disallow using lldb instead of %lldb in the shell tests. This
is a clever trick that is used by Swift to achieve the same results.
Differential revision: https://reviews.llvm.org/D73289
This patch introduces a small new utility (lldb-repro) to transparently
capture and replay debugger sessions through the command line driver.
Its used to test the reproducers by running the test suite twice.
During the first run, it captures a reproducer for every lldb invocation
and saves it to a well-know location derived from the arguments and
current working directory. During the second run, the test suite is run
again but this time every invocation of lldb replays the previously
recorded session.
Differential revision: https://reviews.llvm.org/D72823
Summary:
This patch addresses an ambiguity in how our existing tests invoke the
compiler. Roughly two thirds of our current "shell" tests invoke the
compiler to build the executables for the host. However, there is also
a significant number of tests which don't build a host binary (because
they don't need to run it) and instead they hardcode a certain target.
We also have code which adds a bunch of default arguments to the %clang
substitutions. However, most of these arguments only really make sense
for the host compilation. So far, this has worked mostly ok, because the
arguments we were adding were not conflicting with the target-hardcoding
tests (though they did provoke an occasional "argument unused" warning).
However, this started to break down when we wanted to use
target-hardcoding clang-cl tests (D69031) because clang-cl has a
substantially different command line, and it was getting very confused
by some of the arguments we were adding on non-windows hosts.
This patch avoid this problem by creating separate %clang(xx,_cl)_host
substutitions, which are specifically meant to be used for compiling
host binaries. All funny host-specific options are moved there. To
ensure that the regular %clang substitutions are not used for compiling
host binaries (skipping the extra arguments) I employ a little
hac^H^H^Htrick -- I add an invalid --target argument to the %clang
substitution, which means that one has to use an explicit --target in
order for the compilation to succeed.
Reviewers: JDevlieghere, aprantl, mstorsjo, espindola
Subscribers: emaste, arichardson, MaskRay, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69619
