Initially added in #187709. It was reverted in #188833, because
[llvm-clang-x86_64-sie-win](https://lab.llvm.org/buildbot/#/builders/46/builds/32873)
was failing in
`cross-project-tests/debuginfo-tests/dexter-tests/nrvo.cpp`.
The test passed for me locally. After checking on another machine, I
found that `S_DEFRANGE_REGISTER_REL_INDIR` is only supported by
dbgeng/WinDbg from Windows 10.0 Build 19041 (released 2020) onwards.
SDKs before this will fail to read the value. That buildbot is on
Windows 10.0 Build 17763.
I'm not sure if we should make the generation of that record
conditional. Debuggers that can't read the record will skip it. They'll
still see that there's some local variable, but won't be able to display
the value.
As far as I know, users of older Windows 10 builds should be able to
install a newer Windows SDK and use the WinDbg from that version. But I
haven't tested that.
This reverts commit 08a4085. The change breaks `nvro.cpp` in the
debugging tests on the buildbot
(https://lab.llvm.org/buildbot/#/builders/46/builds/32873) but works
locally for me. It might be because the buildbot is using an older
Windows SDK.
In addition, it reverts parts of #188769 (using `.` over `->`).
After #187709, the
[nrvo.cpp](3a56470a0e/cross-project-tests/debuginfo-tests/dexter-tests/nrvo.cpp)
test failed (e.g.
https://lab.llvm.org/buildbot/#/builders/46/builds/32858), because it
couldn't evaluate the expression `result.i` anymore. This was because it
actually evaluated `result->i`, which doesn't work anymore as `result`
is not a pointer or reference. Before #187709, `result` was declared as
a reference that lives at `frame-pointer+offset`.
Now it's no longer a reference, but the location is
`*(frame-pointer+offset) + 0`.
There weren't any other tests that were accessing struct fields and used
dbgeng as the debugger.
This patch adds a `has-gdb` LIT feature that I then use in the
`REQUIRES` clause for `llgdb` tests.
These tests were failing because `llgdb.py` couldn't find `gdb` on the
host when I tried enabling these tests on PR CI
(https://github.com/llvm/llvm-project/issues/188775).
We should get `gdb` installed on the buildbots. But we should also be
able to run the rest of the `cross-project-tests` in the meantime even
if gdb isn't installed.
PointerUnion stores a fixed-width `ceil(log2(N))`-bit tag in the low
bits of the pointer. This works only when every member type provides at
least that many low bits — if the least-aligned type doesn't,
compilation fails, even though the higher-aligned types may have plenty
of spare bits going to waste.
Introduce a variable-length escape-encoded tag that exploits the extra
low bits of higher-aligned types, analogous to UTF-8: types are grouped
into tiers by NumLowBitsAvailable; each non-final tier reserves one code
as an escape prefix, and the next tier extends the tag into the newly
available bits. This allows PointerUnion to hold more type variants than
a fixed-width tag permits.
The fixed-width path is used when the minimum alignment already provides
enough bits (the common case); the variable-width path activates only
when it doesn't, and requires types to be listed in non-decreasing
NumLowBitsAvailable order.
I need this for https://github.com/llvm/llvm-project/pull/186923 which
requires a 6-member PointerUnion in MLIR TypeRange/ValueRange. On 32-bit
systems, some members only provide 2 low bits, insufficient for a 3-bit
fixed-width tag.
In #188242, we replaced `PointerUnion`'s `PointerIntPair` storage with
`PunnedPointer<void*>`. The old formatters relied on the PIP synthetic
provider (LLDB) / `get_pointer_int_pair helper` (GDB) which no longer
work.
Instead, read raw bytes from `PunnedPointer` and compute the active tag
from template argument type alignments -- the same fixed-width encoding
the C++ implementation uses. When template arg enumeration is truncated
(e.g., function-local types in GDB), the formatters fall back to showing
a tag-stripped `void*` instead of silently misdecoding.
Alternatives that didn't work out:
- Adding a C++ helper (`getActiveMemberIdx`) callable from Python: gets
optimized out even with `__attribute__((used, noinline))`, and
expression evaluation fails for synthetic children.
- Using `isa`/`dyn_cast` checks from Python: requires expression
evaluation, which does not work for local types or synthetic children
without a frame context.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
`DenseIntOrFPElementsAttr` was recently generalized to accept any type
that implement the `DenseElementType` interface. The name
`DenseIntOrFPElementsAttr` does not make sense anymore. This commit
renames the attribute to `DenseTypedElementsAttr`. An alias is kept for
migration purposes. The alias will be removed after some time.
When using LLDB, the first and last call should be
SBDebugger::Initialize and SBDebugger::Terminate respectively.
While we're resilient against mistakes, I'm adding an assert (#185162)
to debug builds to catch those mistakes in-tree as they have the
potential to leak resources. The assert was tripped by Dexter.
This PR adds the missing calls to SBDebugger::{Initialize,Terminate},
and while I was at it, I also added a missing call to
SBDebugger::Destroy. With that, the Dexter tests pass locally with the
assert enabled.
Given the test case:
struct CBase {
virtual void foo();
};
void bar(CBase *Base) {
Base->foo();
}
and using '-emit-call-site-info' with llc, the following DWARF
is produced for the indirect call 'Base->foo()':
1$: DW_TAG_structure_type "CBase"
...
2$: DW_TAG_subprogram "foo"
...
3$: DW_TAG_subprogram "bar"
...
4$: DW_TAG_call_site
...
We add DW_AT_LLVM_virtual_call_origin to existing call-site
information, linking indirect calls to the function-declaration
they correspond to.
4$: DW_TAG_call_site
...
DW_AT_LLVM_virtual_call_origin (2$ "_ZN5CBase3fooEv")
The new attribute DW_AT_LLVM_virtual_call_origin helps to
address the ambiguity to any consumer due to the usage of
DW_AT_call_origin.
The functionality is available to all supported debuggers and
it is generated only for DWARF version 5 or greater.
…n in DWARF. (#167666)"
This reverts commit 418ba6e8ae2cde7924388142b8ab90c636d2c21f.
The commit caused an ICE due to hitting unreachable in
llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:1307
Fixes#182337
Given the test case:
struct CBase {
virtual void foo();
};
void bar(CBase *Base) {
Base->foo();
}
and using '-emit-call-site-info' with llc, the following DWARF
is produced for the indirect call 'Base->foo()':
1$: DW_TAG_structure_type "CBase"
...
2$: DW_TAG_subprogram "foo"
...
3$: DW_TAG_subprogram "bar"
...
4$: DW_TAG_call_site
...
We add DW_AT_LLVM_virtual_call_origin to existing call-site
information, linking indirect calls to the function-declaration
they correspond to.
4$: DW_TAG_call_site
...
DW_AT_LLVM_virtual_call_origin (2$ "_ZN5CBase3fooEv")
The new attribute DW_AT_LLVM_virtual_call_origin helps to
address the ambiguity to any consumer due to the usage of
DW_AT_call_origin.
The functionality is available to all supported debuggers.
The get_lldb_version_string function in the lit config used a greedy
regex that could, if using a lldb binary built with git revision output,
using a SHA that starts with a digit, result in the first digits of the
SHA being interpreted as the lldb version.
For example, if lldb emits:
$ lldb --version
lldb version 23.0.0git \
(https://github.com/dstenb/llvm-project.git revision \
7e565729e33d19d468520e7bfbb8b23a918adc9c)
the version would be interpreted as 7 rather than 23.0.0:
Marking some LLDB LLVM data-formatter tests as unsupported: using
version 7 whereas a version >= 1900 is required
(That check should compare towards 19.0.0, but that issue is addressed
in an other patch.)
Resolve this by using a non-greedy matcher.
Also, include a drive-by fix of some typos.
Windows supports short 8.3 form filenames (e.g. `compile_commands.json`
-> `COMPIL~1.JSO`) for legacy reasons. See:
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#short-vs-long-names.
Short 8.3 form paths are undesirable in distributed compilation
scenarios because they are local mappings tied to a specific directory
layout on a specific machine. As a result, they can break or defeat
sandboxing and path-based isolation mechanisms used by distributed build
systems.
We have observed such failures with DTLTO even in simple scenarios. For
example, on Windows, running:
```
clang.exe hello.c -flto=thin -fuse-ld=lld -fthinlto-distributor=fastbuild.exe -###
```
on my development machine reveals a short 8.3 form path being passed to
LLD (output paraphrased):
```
ld.lld -o a.out -plugin-opt=thinlto --thinlto-distributor=fastbuild.exe \
--thinlto-remote-compiler=clang.exe C:\Users\DUNBOB~1\AppData\Local\Temp\hello-380d65.o
```
This behavior occurs because, on Windows, the system temporary directory
is commonly derived from the `TMP`/`TEMP` environment variables. For
historical compatibility reasons, these variables are often set to short
8.3 form paths, particularly on systems where user names exceed eight
characters.
Whilst it's possible for users to work around these issues, in practice,
especially in automated and CI environments, users often have limited
control over their environment.
DTLTO generally tries to avoid embedding distribution-specific logic in
the LLVM source tree, and this principle also applies to path
normalization. However, on Windows, such short 8.3 form paths are
undesirable for any distribution system. This normalization also cannot
be delegated to distributors, as the ThinLTO module ID must be finalized
early during LTO and cannot be modified later.
Given this, normalizing away short 8.3 paths on Windows is a pragmatic,
targeted improvement, even though path normalization is not something a
toolchain would typically perform in the general case.
SIE internal tracker: TOOLCHAIN-19185
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.
