| Age | Commit message (Collapse) | Author |
|---|
|
reconstructing DIE names (#168734)
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.
|
|
runnable on Darwin (#168725)
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
|
|
Updated the evaluate handler to check for DAP ErrorResponse bodies,
which are used to display user errors if a request fails. This was
updated in PR https://github.com/llvm/llvm-project/pull/167720
This should fix https://lab.llvm.org/buildbot/#/builders/163
|
|
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.
|
|
This isn't pretty but should help us keep the bot stable while issues
such as #158306 and #158311 are investigated
|
|
Added testing dependencies for `llvm-dis` and `obj2yaml`.
|
|
This will help diagnose flaky buildbots. The stderr output is only shown
by lit if the test fails.
|
|
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).
|
|
Reverts llvm/llvm-project#157145
This was just temporary to help debug a flaky bot
|
|
Reverts llvm/llvm-project#157130
This was just a temporary change to investigate a flaky bot failure
|
|
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.
|
|
|
|
|
|
Add `add_function_breakpoint` and `add_instruction_breakpoint` to DebuggerBase.
Add implementations for DAP-based debuggers.
|
|
|
|
|
|
|
|
This reverts commit e1e312e6af34803d1686d9ce5a441446811f425d.
The original patch had some python3.10 syntax, which was incompatible with
the python3.8 minimum version in LLVM currently; this reapply brings
everything down to 3.8 compatibility. Separately, some incorrect arguments
were passed in LLDBDAP._get_launch_params, which have been removed.
|
|
This patch adds support for bitcode members of thin archives to DTLTO
(https://llvm.org/docs/DTLTO.html) in ELF LLD.
For DTLTO, bitcode identifiers must be valid paths to bitcode files on
disk. Clang does not support archive inputs for ThinLTO backend
compilations. This patch adjusts the identifier for bitcode members of
thin archives in DTLTO links so that it is the path to the member file
on disk, allowing such members to be supported in DTLTO.
This patch is sufficient to allow for self-hosting an LLVM build with
DTLTO when thin archives are used.
Note: Bitcode members of non-thin archives remain unsupported. This will
be addressed in a future change.
Testing:
- LLD lit test coverage has been added to check that the identifier is
adjusted appropriately.
- A cross-project lit test has been added to show that a DTLTO link can
succeed when linking bitcode members of thin archives.
For the design discussion of the DTLTO feature, see: #126654.
|
|
This reverts commit 83dfdd8f5485f6b50213c88f02878f86b3f53852.
Temporary revert, as the above patch contains some python code requiring at
least version 3.10, when the minimum required by LLVM is 3.8.
|
|
This patch adds a new variety of driver to Dexter, allowing it to work
with DAP-based interfaces for debuggers. The first concrete instance of
this is implemented in this patch, adding support for an `lldb-dap`
debugger. This is functionally very similar to the existing LLDB
debugger support*, but uses lldb-dap as its executable instead of lldb.
This has been tested successfully against the existing feature_test
suite, and manually tested against some other inputs; support is
essentially complete, although any further DAP-based debuggers may
require additional hooks inserted into the base class to deal with any
idiosyncrasies they exhibit (as with the several that have been inserted
for lldb-dap).
NB: There are some small differences resulting from differences between
lldb-dap's use of the lldb API and Dexter's use in its lldb driver; one
small example of this is when evaluating variables, lldb-dap will try to
first use `GetValueForVariablePath` and fallback to `EvaluateExpression`
if necessary, while Dexter will always use `EvaluateExpression`; these
can give slightly different results, resulting in different output from
Dexter for the same input.
|
|
I believe these are relics from the days of dexter having the ability to
build your code
|
|
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in COFF LLD.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
Note: Bitcode members of non-thin archives are not currently supported.
This will be addressed in a future change. This patch is sufficient to
allow for self-hosting an LLVM build with DTLTO if thin archives are
used.
Testing:
- LLD `lit` test coverage has been added, using a mock distributor to
avoid requiring Clang.
- Cross-project `lit` tests cover integration with Clang.
For the design discussion of the DTLTO feature, see:
https://github.com/llvm/llvm-project/pull/126654
|
|
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in Clang.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
Testing:
- `lit` test coverage has been added to Clang's Driver tests.
- The DTLTO cross-project tests will use this Clang support.
For the design discussion of the DTLTO feature, see:
https://github.com/llvm/llvm-project/pull/126654
|
|
As a legacy of Dexter's role as a test runner, it selects a name for
result files based on the relative path from the test root to each
individual test. Since Dexter no longer takes a test directory as an
argument, only the basename for each test is ever used. This patch adds
an optional --test-root-dir argument, allowing for relative paths to be
used for result files again.
|
|
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in ELF LLD.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
It is expected that users will invoke DTLTO through the compiler driver
(e.g., Clang) rather than calling LLD directly. A Clang-side interface
for DTLTO will be added in a follow-up patch.
Note: Bitcode members of archives (thin or non-thin) are not currently
supported. This will be addressed in a future change. As a consequence
of this lack of support, this patch is not sufficient to allow for
self-hosting an LLVM build with DTLTO. Theoretically,
--start-lib/--end-lib could be used instead of archives in a self-host
build. However, it's unclear how --start-lib/--end-lib can be easily
used with the LLVM build system.
Testing:
- ELF LLD `lit` test coverage has been added, using a mock distributor
to avoid requiring Clang.
- Cross-project `lit` tests cover integration with Clang.
For the design discussion of the DTLTO feature, see: #126654.
|
|
Following commit b8fc288, which changed some dexter test substitutions to
be specific to C and C++, some tests that had been added since the original
patch was written were still using the old substitution; this patch updates
them to use the new.
|
|
This patch replaces invocations of clang with clang++ for a set of
c++ files in the dexter cross-project tests. As a small additional change,
this patch removes -lstdc++ from a test that did not appear to require it.
|
|
This implements arm, armeb, thumb, thumbeb PLT entries parsing support
in ELF for llvm-objdump.
Implementation is similar to AArch64MCInstrAnalysis::findPltEntries. PLT
entry signatures are based on LLD code for PLT generation
(ARM::writePlt).
llvm-objdump tests are produced from lld/test/ELF/arm-plt-reloc.s,
lld/test/ELF/armv8-thumb-plt-reloc.s.
|
|
The cross-project-tests's debuginfo-tests don't rely on lldb being built
to run. While this is a good, a bug in the system lldb can cause a test
to fail with no way of fixing it. This patch makes it so the tests use
the built lldb instead if it's available.
|
|
Currently, the index of SWMMAC builtins is of type `short`, likely based
on the
assumption that K can only be up to 32, meaning there are only 16
non-zero
elements. However, this is not future-proof. This patch updates all of
them to
`int`.
The intrinsics themselves don't need to be updated since they accept any
integer
type, and in the backend, they are already extended to 32-bit.
Additionally, the
tests already use various kinds of integers.
Partially fixes SWDEV-518183.
|
|
The idea behind this tool was that you'd instrument a source file to
measure its debug-info quality, then watch as it progressively got worse
with more optimisations being enabled in clang. However we've since
stripped the "building" portions of Dexter out as they were ill placed,
which makes this tooling redundant. The lack of __init__.py adjacent to
it means it couldn't be run anyway.
The core idea behind this is still sound; just it's best placed on the
other side of the build system, something that Dexter shouldn't try to
solve.
|
|
These generate a SyntaxWarning with Python 3.12.
|
|
From PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
|
|
Fixes issue added by: https://github.com/llvm/llvm-project/pull/111833
Following the previous commit that changed how Dexter imports modules,
the ComInterface module import became broken. This is because it had a
different directory structure to other modules, where we want to import
single file rather than a dir containing a __init__.py. For this case,
an optional extra arg has been added to load_module allowing a filename
to be specified, letting us import ComInterface.py directly and fixing
the issue.
|
|
Fixes: https://github.com/llvm/llvm-project/issues/111815
This patch replaces usage of the python `imp` library, which is
deprecated since python3.4 and removed in python3.12, with the
`importlib` library. As part of this update the repeated
find_module+load_module pattern is moved into a utility function, since
the importlib equivalent is much more verbose.
|
|
lldb will change how it reports stop reasons around breakpoints in the
near future. I landed an earlier version of this change and noticed
debuginfo test failures on the CI bots due to the changes. I'm
addressing the issues found by CI at
https://github.com/llvm/llvm-project/pull/105594 and will re-land once
I've done all of them.
Currently, when lldb stops at a breakpoint instruction -- but has not
yet executed the instruction -- it will overwrite the thread's Stop
Reason with "breakpoint-hit". This caused bugs when the original stop
reason was important to the user - for instance, a watchpoint on an
AArch64 system where we have to instruction-step past the watchpoint to
find the new value. Normally we would instruction step, fetch the new
value, then report the user that a watchpoint has been hit with the old
and new values. But if the instruction after this access is a breakpoint
site, we overwrite the "watchpoint hit" stop reason (and related
actions) with "breakpoint hit".
dexter sets breakpoints on all source lines, then steps line-to-line,
hitting the breakpoints. But with this new behavior, we see two steps
per source line: The first step gets us to the start of the next line,
with a "step completed" stop reason. Then we step again and we execute
the breakpoint instruction, stop with the pc the same, and report
"breakpoint hit". Now we can step a second time and move past the
breakpoint.
I've changed the `step` method in LLDB.py to check if we step to a
breakpoint site but have a "step completed" stop reason -- in which case
we have this new breakpoint behavior, and we need to step a second time
to actually hit the breakpoint like the debuginfo tests expect.
|
|
(#106465)
Getting this to work required a few additional changes:
- Add builtins for any instructions that can't be done with plain C
currently.
- Add support for the saturating version of fp_to_<s,i>_I16x8. Other
vector sizes supported this already.
- Support bitcast of f16x8 to v128. Needed to return a __f16x8 as
v128_t.
|
|
Currently the output of dexter --version contains the raw output of `git
remote get-url origin`, which may contain a username and password. This
patch adds a small change to remove these from the output string. A
similar patch for LLVM's default version string* also removes the git
URL altogether unless opted-in to; it's not clear whether this is a
necessary or desirable step yet, but if so we can trivially remove the
URL from Dexter as well.
*PR here: https://github.com/llvm/llvm-project/pull/105220
|
|
deprecated in python 3.10 and removed in 3.12. (#99852)
Attempt to reland #99549, but using packaging.version instead of
looseversion, based on the usage used for LLDB in #93712.
|
