Fixes following error on macOS:
```
CHECK-NEXT: (llvm::SmallVector<int, 2>) value = size=2 {
^
<stdin>:41:65: note: scanning from here
(llvm::Expected<llvm::SmallVector<int, 2> &>) ExpectedVecRef = {
^
<stdin>:42:31: note: possible intended match here
(std::__1::reference_wrapper<llvm::SmallVector<int, 2> >::type) value = size=2 {
```
The `CHECK` for `(int)` was too strict. On macOS the type prints as:
```
08:46:24 29: (lldb) v -T ExpectedRef
08:46:24 30: (llvm::Expected<int &>) ExpectedRef = {
08:46:24 next:14'0 X error: no match found
08:46:24 31: (std::__1::reference_wrapper<int>::type) value = 100
08:46:24 next:14'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
08:46:24 next:14'1 ? possible intended match
08:46:24 32: }
08:46:24 next:14'0 ~~
```
This patch fixes LLDB data formatter support for llvm::Expected<T> with
the following changes:
llvm/utils/lldbDataFormatters.py: Fix ExpectedSynthProvider to handle
non-templated storage types (e.g., int, int*). Previously the formatter
only worked with templated storage types like std::reference_wrapper<T>.
cross-project-tests/lit.cfg.py:
Fix get_lldb_version_string() to use locally-built LLDB on non-Darwin
platforms instead of system LLDB
Fix minimum version from "1900" to "19.0.0" (typo in original code)
New test files: Added expected.cpp and expected.test to test the
formatter with Expected<int> and Expected<int*>.
---------
Co-authored-by: Jeffrey Tan <jeffreytan@fb.com>
We already have code to extract bitcode files from archives so they can
be distributed. Extend this code to extract bitcode from FatLTO objects
too, which otherwise cannot be used with DTLTO.
DTLTO emits temporary files to allow distribution of archive member
inputs.
It also emits temporary files from the ThinLTO backend, such as the
index files needed for each distributed ThinLTO backend compilation.
This change brings archive member temporary files into line with those
produced by the ThinLTO backend. They are now emitted in the same
location, warnings are emitted if they cannot be deleted, and they are
cleaned up on abnormal exit (e.g. Ctrl-C). All temporary files are
preserved when --save-temps is specified.
The existing signal-handling test has been extended to cover the full
set of DTLTO temporary files, and a new test has been added to exercise
temporary file handling in normal operation. Additionally, a minimal
test has been added to show the COFF behaviour.
SIE Internal tracker: TOOLCHAIN-21022
This change makes small, non-functional improvements to the DTLTO test
suite, including:
- Tightening+Regularizing FileCheck match expressions across tests
- Simplifying `signal.test` using more lit macro features
This change fixes two issues when processing multi-module bitcode files
in DTLTO:
1. The DTLTO archive handling code incorrectly uses
getSingleBitcodeModule(), which asserts when the bitcode file contains
more than one module.
2. The temporary file containing the contents of an input archive member
was not emitted for multi-module bitcode files. This was due to
incorrect logic for recording whether a bitcode input contains any
ThinLTO modules. In a typical multi-module bitcode file, the first
module is a ThinLTO module while a subsequent auxiliary module is
non-ThinLTO. When modules are processed in order, the auxiliary module
causes the entire bitcode file to be classified as non-ThinLTO, and the
archive-member emission logic then incorrectly skips it.
In addition, this patch adds a test that verifies that multi-module
bitcode files can be successfully linked with DTLTO. The test reproduces
both issues as they existed prior to this change.
SIE Tracker: TOOLCHAIN-21008
The LLVM release version and Apple LLDB version follow slightly different numbering scheme. Make sure we set the minimum required LLDB version appropriately.
Also refactors the `apple-lldb-pre-1000` feature check to use the same `get_lldb_version_string` method.
Currently this was causing the LLDB LLVM formatters to be skipped on our public macOS CI.
Reverts a4cc033408fe0a69aad6865ddc7e020d64098f20.
Relanding the original patch as-is, but changing the `__builtin_debugtrap`s to explicitly set breakpoints. Some bots failed to compile the tests when `__builtin_debugtrap` was used.
Also adding `REQUIRES: lldb-formats-compatibility` to the test because some build-bots run the tests with an LLDB version that doesn't support the `FindDirectNestedType` API.
Original commit message:
This patch revives the llvm::PointerIntPair LLDB data-formatter. The previous version was commented out because it relied on expression evaluation and was hence slow/brittle. The formatter in this PR doesn't rely on evaluating expressions.
Drive-by change:
* removes the llvm::PointerUnion formatter which was also commented out. A future version of it will look very different than it does now, so there's no point in keeping it because the diff won't be helpful in a review.
Most of this logic is similar to how we add the
`gdb-clang-incompatibility` attribute.
Some LLVM LLDB formatters will rely on LLDB features not available in
older versions of LLDB. This feature will allow those tests to add a
`REQUIRES: lldb-formatters-compatibility`, which will then mark the test
`UNSUPPORTED` for incompatible LLDB versions. I picked `19.0` pretty
arbitrarily based on when approximately the
`SBType::FindDirectNestedType` API was added to LLDB (which a future
formatter will require).
When building `cross-project-tests` with `_FORTIFY_SOURCE` set, we get
following warnings:
```
In file included from /app/gcc/14.2.0/include/c++/14.2.0/x86_64-pc-linux-gnu/bits/os_defines.h:39,
from /app/gcc/14.2.0/include/c++/14.2.0/x86_64-pc-linux-gnu/bits/c++config.h:680,
from /app/gcc/14.2.0/include/c++/14.2.0/type_traits:38,
from ../include/llvm/ADT/ADL.h:12,
from ../include/llvm/ADT/Hashing.h:47,
from ../include/llvm/ADT/ArrayRef.h:12,
from ../../cross-project-tests/debuginfo-tests/llvm-prettyprinters/lldb/arrayref.cpp:1:
/usr/include/features.h:381:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
381 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
```
This patch works around this by undefining the macro when compiling the
LLDB formatter tests.
If this ever becomes an issue we could try to detect `_FORTIFY_SOURCE`
and skip the tests if set.
Fixes https://github.com/llvm/llvm-project/issues/172893.
In the issue reported above there, it appears that LLDB is hitting a 3s
timeout as part of some CI tests; this patch attempts to fix the issue
by replacing the 3s timeout with a 60s timeout, which should be suitably
long for any CI job (lldb-dap itself will automatically time out after
30s, so this should not be hit unless the process hangs).
Depends on:
* https://github.com/llvm/llvm-project/pull/173238
(only last commit relevant for review)
This patch revives the `llvm::PointerIntPair` LLDB data-formatter. The
previous version was commented out because it relied on expression
evaluation and was hence slow/brittle. The formatter in this PR doesn't
rely on evaluating expressions.
Drive-by change:
* removes the `llvm::PointerUnion` formatter which was also commented
out. A future version of it will look very different than it does now,
so there's no point in keeping it because the diff won't be helpful in a
review.
This patch adds the bare-minimum tests for the LLDB `llvm::ArrayRef`
formatters. Since this would be the first LLVM data fromatter test for
LLDB, I wanted to keep the test itself minimal and mainly set up/agree
on the infrastructure (i.e., CMake machinery, etc.).
The setup mimicks that of GDB. The main differences are:
1. the GDB formatter tests put all the test cases in one monolithic test
file, whereas I'm planning on having one test-file per LLVM container.
2. the GDB formatter tests currently only get run if LLVM was built with
debug-info. Not sure we have any build-bots out there running this
configuration. In this patch we rely on just the debug-info from the
LLVM headers (see latest commit). That way the tests get more
consistently run (at least our public macOS buildbot runs the
cross-project-tests in Release+Asserts).
This patch implements support for handling archive members in DTLTO.
Unlike ThinLTO, where archive members are passed as in-memory buffers,
DTLTO requires archive members to be materialized as individual files on
the filesystem.
This is necessary because DTLTO invokes clang externally, which expects
file-based inputs.
To support this, this implementation identifies archive members among
the input files,
saves them to the filesystem, and updates their module_id to match their
file paths.
Following PR #169744 the DAP launch sequencing of Dexter was changed to
complete a launch request/response before performing configuration
steps. This matches LLDB's current behaviour, but is not compatible with
the DAP specification and causes issues interfacing with other
debuggers.
This patch tries to bridge the gap by using a sequencing that is mostly
DAP-compliant while still interfacing correctly with lldb-dap: we send a
launch request first, then perform all configuration steps and send
configurationDone, and then await the launch response. For lldb-dap, we
do not wait for the launch response and may send configuration requests
before it is received, but lldb-dap appears to handle this without
issue. For other debug adapters, the launch request will be ignored
until the configurationDone request is received and responded to, at
which point the launch request will be acted upon and responded to.
As an additional note, the initialized event should be sent after the
initialize response and before the launch request according to the spec,
but as LLDB currently sends it after the launch response Dexter has
avoided checking for it. Since the initialized event is now being sent
after the launch response by LLDB, we can start checking for it earlier
in the sequence as well (though technically the client should receive
the initialized event before it sends the launch request).
# Summary
This is a forward fix for test errors from
https://github.com/llvm/llvm-project/pull/163653.
The PR moved debugger initialization outside of
InitializeRequestHandler, and into Launch/AttachRequestHandlers to
support DAP sessions sharing debugger instances for dynamically created
targets. However, DExTer's DAP class seemed to set breakpoints before
the debugger was initialized, which caused the tests to hang waiting for
a breakpoint to hit due to none of the breakpoints getting resolved.
# Tests
```
bin/llvm-lit -v /home/qxy11/llvm/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/
```
Depends on:
* https://github.com/llvm/llvm-project/pull/168725
When compiling with `-glldb`, we repoint the `DW_AT_type` of a DIE to be
a typedef that refers to the `preferred_name`. I.e.,:
```
template <typename T> structure t7;
using t7i = t7<int>;
template <typename T> struct __attribute__((__preferred_name__(t7i))) t7 {};
template <typename... Ts> void f1()
int main() { f1<t7i>(); }
```
would produce following (minified) DWARF:
```
DW_TAG_subprogram
DW_AT_name ("_STN|f1|<t7<int> >")
DW_TAG_template_type_parameter
DW_AT_type (0x0000299c "t7i")
...
DW_TAG_typedef
DW_AT_type (0x000029a7 "t7<int>")
DW_AT_name ("t7i")
```
Note how the `DW_AT_type` of the template parameter is a typedef itself
(instead of the canonical type). The `DWARFTypePrinter` would take the
`DW_AT_name` of this typedef when reconstructing the name of `f1`, so we
would end up with a verifier failure:
```
error: Simplified template DW_AT_name could not be reconstituted:
original: f1<t7<int> >
reconstituted: f1<t7i>
```
Fixing this allows us to un-XFAIL the `simplified-template-names.cpp`
test in `cross-project-tests`. Unfortunately this is only tested on
Darwin, where LLDB tuning is the default. AFAIK, there is no other case
where the template parameter type wouldn't be canonical.
As of recent, LLVM includes the bit-size as a `DW_AT_bit_size` (and as
part of `DW_AT_name`) of `_BitInt`s in DWARF. This allows us to mark
`_BitInt`s as "reconstitutable" when compiling with
`-gsimple-template-names`. However, before doing so we need to make sure
the `DWARFTypePrinter` can reconstruct template parameter values that
have `_BitInt` type. This patch adds support for printing
`DW_TAG_template_value_parameter`s that have `_BitInt` type. Since
`-gsimple-template-names` only omits template parameters that are `<=
64` bit wide, we don't support `_BitInt`s larger than 64 bits.
The test was failing on Darwin for two reasons:
1. `-fdebug-type-sections` is not a recognized flag on Darwin
2. We fail to reconstitute a name if the template parameter has a type
that has a preferred_name. With LLDB tuning the type of such a parameter
is a typedef, i.e., the preferred name. Without tuning it would be the
canonical type that the typedef (possibly through a chain of typedefs)
points to.
This patch addresses (1) by splitting the `-fdebug-type-sections` tests
into a separate file (and only mark that one `UNSUPPORTED`). Which means
we can at least XFAIL the non-type-sections tests on Darwin.
To fix (2) we might need to make the `DWARFTypePrinter` aware of
non-canonical `DW_AT_type`s of template parameters.
1. Fixed 2 DTLTO cache tests that failed on MacOS because input to grep
command is different compared to Windows
2. Removed unneeded comments from dtlto-cache.ll
This patch implements DTLTO cache. DTLTO cache is implemented the same
way as ThinLTO cache. In fact the same class Cache is used for both of
them.
Because parameters for codegen are different for DTLTO and ThinLTO
(DTLTO codegen is done by invoking clang and its codegen parameters are
not fully synchronized with codegen parameters used by LTO backend).
The object files generated by DTLTO and ThinLTO might be different and
shouldn't be mixed. If ThinLTO and DTLTO share the same cache
directory, the cache file won't interfere with each other.
I added a couple of test files in cross-project-test/dtlto directory,
but if more tests are required for initial implementation, I could add
them.
This fixes the -fveclib flag getting lost on its way to the backend.
Previously this was its own cl::opt with a random boolean. Move the
flag handling into CommandFlags with other backend ABI-ish options,
and have clang directly set it, rather than forcing it to go through
command line parsing.
Prior to de68181d7f, codegen used TargetLibraryInfo to find the vector
function. Clang has special handling for TargetLibraryInfo, where it
would
directly construct one with the vector library in the pass pipeline.
RuntimeLibcallsInfo currently is not used as an analysis in codegen, and
needs to know the vector library when constructed.
RuntimeLibraryAnalysis could follow the same trick that
TargetLibraryInfo is using in the future, but a lot more boilerplate changes
are needed to thread that analysis through codegen. Ideally this would come
from an IR module flag, and nothing would be in TargetOptions. For now, it's
better for all of these sorts of controls to be consistent.
Reland #161355, after fixing up the cross-projects-tests for the wasm
simd intrinsics.
Original commit message:
Lower v4f32 and v2f64 fmuladd calls to relaxed_madd instructions.
If we have FP16, then lower v8f16 fmuladds to FMA.
I've introduced an ISD node for fmuladd to maintain the rounding
ambiguity through legalization / combine / isel.
Buildbot cross-project-tests-sie-ubuntu has been flaky after moving to
lldb-dap.
https://lab.llvm.org/buildbot/#/builders/181/builds/27670 - this test
fails for a single run but unfortunately there's not enough output to
diagnose it.
Add `-v` to the substitutions to get as much info as possible out of
failures. Most tests already have -v added manually. If we ever find a
tests needs to specifically run without it we can revert this and add
`-v` manually to tests it's missing from.
Buildbot cross-project-tests-sie-ubuntu has been unstable recently
(https://lab.llvm.org/buildbot/#/builders/181).
Dexter uses lldb-dap in these tests. Occasionally a one will fail with a
KeyError because of a missing "stackFrames" "source" "path".
I can't reproduce the failure locally, but with PRs #157130 and
#157145 I've got DAP logs from a pass and fail.
In a failure, "path" is missing for a step out of main (off the final brace),
and the passing test has one additional "module" event for libc.so.6.
```
<- {
"body": {
"module": {
"addressRange": "0x7ffff7dd1000",
"debugInfoSize": "4.9MB",
"id": "5792732F-7831-58C6-6FB4-F3756458CA24-E46E827D",
"name": "libc.so.6",
"path": "/lib/x86_64-linux-gnu/libc.so.6",
"symbolFilePath": "/usr/lib/debug/.build-id/57/92732f783158c66fb4f3756458ca24e46e827d.debug",
"symbolStatus": "Symbols loaded."
},
"reason": "new"
},
"event": "module",
"seq": 0,
"type": "event"
}
```
That explains why we get a step that is missing a "path" component in the
failure. I don't understand why LLDB (or LLDB-DAP) is sometimes unable to load
the module (in time?). But "path" is an optional field anyway, so I think it's
worth handling in dexter even if LLDB's behaviour here is confusing.
This commit should stabilize the bot if the only time a module goes missing is
for steps outside main. (Ideally none would go missing, but those shouldn't
interfere with the tests).
Buildbot cross-project-tests-sie-ubuntu sees sporadic test failures due to
missing "stackTrace" "source" "path". The "path" field is optional for
"source" according to DAP, so it's well formed. It works most of the time,
and doesn't consistently fail for any one test which is all strangely
inconsistent.
The failures couldn't be reproduced locally after running the feature_tests
in a loop for 3 hours. I haven't been able to work out why the "source" is
sometimes missing by just looking at LLDB code.
This patch prints the DAP log to stderr when the specific error condition is
hit, to help us understand why LLDB is sometimes getting into this state.
Dump additional context from FileCheck so this can be seen on the bots (on
a failure).
This patch will be reverted once we've collected some logs.
Buildbot cross-project-tests-sie-ubuntu sees sporadic test failures due to
missing "stackTrace" "source" "path". The "path" field is optional for
"source" according to DAP, so it's well formed. It works most of the time,
and doesn't consistently fail for any one test which is all strangely
inconsistent.
The failures couldn't be reproduced locally after running the feature_tests
in a loop for 3 hours. I haven't been able to work out why the "source" is
sometimes missing by just looking at LLDB code.
With this patch, we might be able to get clues about the flaky tests with
well timed log inspection.
Prior to this patch we incremented step_index every time the debugger
stopped. Now that some stops are not recorded, we should only increment
the step_index for those that are.
This should make the `-v` output more consistent between platforms and
debuggers.
Currently, Dexter's interface for lldb and lldb-dap has a post-step hook
that checks to see whether lldb reports that we stopped because we
completed a step, and if so checks to see whether the current $pc
address also matches a known breakpoint whose conditions (if any) are
met, and if so it requests to "step in", so that we "resume" execution,
stopping again at the current address, such that lldb now reports that
we have hit a breakpoint and provides the list of breakpoints that were
hit.
This logic has a flaw however: the call to "step in" sets an implicit
breakpoint on the next line. In Dexter's default stepping mode this is
not an issue, as we intend to step there eventually. When we use
DexContinue, however, we set a breakpoint from which we wish to continue
to the next user-specified breakpoint, rather than stepping. Currently,
there is a bug where Dexter sets a DexContinue breakpoint, arrives at
that bp from a step, requests "step in" so that LLDB gives us the hit
breakpoint ID, requests "continue" to hit the next user breakpoint, and
then arrives at the next line after the continue due to the earlier
"step in" request. This effectively negates the DexContinue command.
This patch fixes this behaviour by using "continue" instead of "step in"
in the post-step hook, ensuring that no implicit breakpoint is set so
that we do not incorrectly stop at the next line.
Adding together in a single commit as their implementations are linked.
Only supported for DAP debuggers. These two commands make it a bit easier to
drive dexter: DexStepFunction tells dexter to step-next though a function and
DexContinue tells dexter to continue (run free) from one breakpoint to another
within the current DexStepFunction function.
When the DexStepFunction function breakpoint is triggered, dexter sets an
instruction breakpoint at the return-address. This is so that stepping can
resume in any other DexStepFunctions deeps in the call stack.
This patch updates Dexter's lit test setup, making lldb-dap the default
debugger where available; as part of this, I've replaced references to
`--debugger lldb` with new substitutions that provide the debugger and
executable path: one substitution returns just lldb for the tests that
require it (all the LLDB-using tests in `dexter-tests`), and the other
which provides the system-preferred debugger for the tests that should
be able to run with any debugger (all the tests in `feature_tests`).
As a small note, one test generates output that differs between lldb and
lldb-dap - for this test specifically, we add an lldb-dap feature so
that it can be marked XFAIL if we fall back to using LLDB.
