One of the tests added in the recent floating point patch involves
string comparison against the debugger output; as DbgEng and LLDB have
different output, the test cannot pass against both of them, so disable
it on windows.
This patch adds an optional argument to DexExpectWatchBase, float_range,
which defines a +- acceptance range for expected floating point values.
If passed, this assumes every expected value to be a floating point
value, and an exception will be thrown if this is not the case.
Differential Revision: https://reviews.llvm.org/D124511
Prior to this patch, when comparing the paths of source files in Dexter
commands, we would use os.samefile. This function performs actual file
operations and requires the files to exist on the current system; this
is suitable when running the test for the first time, but renders the
DextIR output files non-portable, and unusable if the source files no
longer exist in their original location.
Differential Revision: https://reviews.llvm.org/D127099
The DexDeclareAddress command checks the value of a variable at a
certain point in the debugged program, and saves that value to be used
in other commands. If the value at that point is not a valid address
however, it currently causes an error in Dexter when we try to cast it -
this is fixed in this patch by catching the error and leaving the
address value unresolved.
Differential Revision: https://reviews.llvm.org/D127101
Currently in Dexter, every step at which a DexExpectWatchValue/Type does
not have the correct value is printed on a separate line. This patch
reduces the size of the text output by instead printing each incorrect
result (i.e. each incorrect value seen, 'Variable optimized out', and so
on) on its own line, alongside a list of the steps at which that result
was seen. This makes for much less spam in the output when watches are
missing or wrong for many steps.
Differential Revision: https://reviews.llvm.org/D120716
Since the NTTP may need to be cast to the type when rebuilding the name,
check that the type can be rebuilt when determining whether a template
name can be simplified.
We could only do this in limited ways (since we emit the TUs first, we
can't use ref_addr (& we can't use that in Split DWARF either) - so we
had to synthesize declarations into the TUs) and they were ambiguous in
some cases (if the CU type had internal linkage, parsing the TU would
require knowing which CU was referencing the TU to know which type the
declaration was for, which seems not-ideal). So to avoid all that, let's
just not reference types defined in the CU from TUs - instead moving the
TU type into the CU (recursively).
This does increase debug info size (by pulling more things out of type
units, into the compile unit) - about 2% of uncompressed dwp file size
for clang -O0 -g -gsplit-dwarf. (5% .debug_info.dwo section size
increase in the .dwp)
This information isn't preserved in the DWARF description of function
types (though probably should be - it's preserved on the function
declarations/definitions themselves through the DW_AT_noreturn attribute
- but we should move or also include that in the subroutine type itself
too - but for now, with it not being there, the DWARF is lossy and
can't be reconstructed)
Add a test checking that each SIMD intrinsic produces the expected instruction.
Since this test spans both clang and LLVM, place it in a new
intrinsic-header-tests subdirectory of cross-project-tests.
This revives D101684 now that cross-project-tests exists. In practice, the tests
of lowering from wasm_simd128.h to LLVM IR were not as useful as this end-to-end
test.
Updates the version check of gdb in cross-project-tests/lit.cfg.py so that
unexpected version formats do not prevent the new tests from running.
Depends on D121661.
Differential Revision: https://reviews.llvm.org/D121662
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
Breakpoint deletion in visual studio is currently implemented by
iterating over the breakpoints we want to delete, for each of which we
iterate over the complete set of breakpoints in the debugger instance
until we find the one we wish to delete. Ideally we would resolve this
by directly deleting each breakpoint by some ID rather than searching
through the full breakpoint list for them, but in the absence of such a
feature in VS we can instead invert the loop to improve performance.
This patch changes breakpoint deletion to iterate over the complete list
of breakpoints, deleting breakpoints that match the breakpoints we
expect to delete by checking set membership. This represents a
worst-case improvement from O(nm) to O(n), for 'm' breakpoints being
deleted out of 'n' total. In practise this is almost exactly 'm'-times
faster, as when we delete multiple breakpoints they are typically
adjacent in the full breakpoint list.
Differential Revision: https://reviews.llvm.org/D120658
Dexter saves various files to a new results directory each time it is run
(including when it's run by lit tests) and there isn't a way to opt-out. This
patch reconfigures the behaviour to be opt-in by removing the default
`--results-directory` location. Now results are only saved if
`--results-directory` is specified.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D119545
Due to the way type units work, this would lead to a declaration in a
type unit of a local type in a CU - which is ambiguous. Rather than
trying to resolve that relative to the CU that references the type unit,
let's just not try to simplify these names.
Longer term this should be fixed by not putting the template
instantiation in a type unit to begin with - since it references an
internal linkage type, it can't legitimately be duplicated/in more than
one translation unit, so skip the type unit overhead. (but the right fix
for that is to move type unit management into a DICompositeType flag
(dropping the "identifier" field is not a perfect solution since it
breaks LLVM IR linking decl/def merging during IR linking))
Lambda names aren't entirely canonical (as demonstrated by the
cross-project-test added here) at the moment (we should fix that for a
bunch of reasons) - even if the template referencing them is
non-simplified, other names referencing /that/ template can't be
simplified either because type units might cause a different template to
be picked up that would conflict with the expected name.
(other than for roundtripping precision, it'd be OK to simplify types
that reference types that reference lambdas - but best be consistent
between the roundtrip/verify mode and the actual simplified template
names mode)
Some configurations of gdb pretty print std::deque and some don't. Make
this test run only on system-darwin (which uses lldb instead), otherwise
it will fail on some non-darwin machines and not others.
And XFAIL debuginfo-tests/llgdb-tests/asan-deque.cpp on !system-darwin.
On non-darwin systems these tests use gdb and this one fails because gdb
doesn't pretty-print std::deque (the elements of the deque are not printed so
the CHECK lines fail).
Differential Revision: https://reviews.llvm.org/D118760
Follow up to D118468 (5257efdc5b).
When built from source, gdb's version string looks like this:
GNU gdb (GDB) 9.2
...
But for installed versions it looks different. E.g.
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
...
Use a regex rather than str.parition in the version string parsing in order to
handle this case too.
Tests in the `cross-project-tests/debuginfo-tests/llgdb-tests` directory run
gdb on non-darwin platforms. gdb versions less than 10.1 cannot parse the DWARF
v5 emitted by clang, and DWARF v5 is now the default, so these tests fail on
Linux with gdb versions less than 10.1. This patch lets us XFAIL the tests
under these conditions.
Add `gdb-clang-incompatibility` to the `available_features` in
`cross-project-tests/lit.cfg.py` when clang's default DWARF version is 5 or
greater and the gdb (if found) version is less than 10.1.
Discourse discussion:
https://llvm.discourse.group/t/gdb-10-1-cant-read-clangs-dwarf-v5/6035
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D118468
Not quite NFC because a little work was required to configure some tests to run
on Windows at all.
Before this patch on Windows:
$ llvm-lit cross-project-tests\debuginfo-tests\dexter\feature-tests
Unsupported: 49
Passed : 23
After this patch on Windows:
$ llvm-lit cross-project-tests\debuginfo-tests\dexter\feature-tests
Unsupported : 27
Passed : 39
Expectedly failed: 6
There are 3 main changes here. The first is to add a few more substitutions in
cross-project-tests/lit.cfg.py so that tests need to use specific flags can
still use the dexter regression test defaults for the native platform. These
are:
%dexter_regression_test_debugger
%dexter_regression_test_builder
%dexter_regression_test_cflags
%dexter_regression_test_ldflags
Tests that now use these options and therefore can be run on Windows too
(though the second is still failing for unknown reasons):
cross-project-tests/debuginfo-tests/dexte/feature_tests
/subtools/clang-opt-bisect/clang-opt-bisect.cpp
/subtools/test/source-root-dir.cpp
The second change is to remove spurious `REQUIRES: system-linux, lldb` and
`UNSUPPORTED: system-windows` directives, and make changes to lit.local.cfg
files that have the same effect. I've also added comments to the genuine
REQUIRES, UNSUPPORTED, and XFAIL directives so it's easier to understand
requirements at a glance. The most common reason for a test to not be supported
on Windows is that it uses DexLimitSteps, DexDeclareAddress, or DexCommandLine,
none of which are supported in the dbgeng driver.
There are two failures on Windows that were previously hidden, which I've
XFAILed:
cross-project-tests/debuginfo-tests/dexter/feature_tests
/commands/perfect/dex_finish_test/default_conditional.cpp
/commands/perfect/dex_finish_test/default_conditional_hit_count.cpp
And two that were easy to fix:
cross-project-tests/debuginfo-tests/dexter/feature_tests
/commands/perfect/dex_finish_test/default_simple.cpp
/commands/perfect/dex_finish_test/default_hit_count.cpp
Lastly, I've set three directories as unsupported.
cross-project-tests/debuginfo-tests/dexter/feature_tests
/commands/perfect/limit_steps
/commands/perfect/dex_declare_address
/commands/perfect/dex_declare_file
The first two are unsupported on Windows because they contains tests for the
DexLimitSteps and DexDeclareAddress commands which aren't supported in the
dbgeng driver. The third is unsupported on all platforms as the tests involve
invoking clang directly, which isn't currently a supported way of building
tests for dexter in lit (it can cause problems for cross compilers that can
target the host, as the tests use the default triple and linker, which may
be aligned for the default target, not host).
Tested on Windows and Linux.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D118048
There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. After this only
the C API will have reference to "Identifier", but those will be reworked in a followup.
The main updates are:
* Identifier -> StringAttr
* StringAttr::get requires the context as the first parameter
- i.e. `Identifier::get("...", ctx)` -> `StringAttr::get(ctx, "...")`
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D116626
DexUnreachable is a useful tool for specifying that lines shouldn't be
stepped on. Right now they have to be placed in the source file; lets allow
them to be placed instead in a detached .dex file, by adding on_line and
line-range keyword arguments to the command.
Differential Revision: https://reviews.llvm.org/D115449
This patch adds a "DexCommandLine" command, allowing dexter tests to
specify what command line options the test should be started with. I've
also plumbed it through into the debuggers.
This eases the matter of pointing Dexter at larger tests, or controlling
different paths through a single binary from a Dexter test.
Differential Revision: https://reviews.llvm.org/D115330
- Prevent symbols from being stripped so that it can run with 'RelWithDebInfo'.
- Adjust llvm-support CHECKs after code changes.
- Polish mlir-support CHECKs as suggested in https://reviews.llvm.org/D116646.
Differential Revision: https://reviews.llvm.org/D116837
Update prettyprinters.py to match MLIR changes.
This has gone unnoticed because no build bot is running tests with debug info.
I will look into what we can do about this separately. There is
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/,
from Apple. The Debug Info tests are failing despite the green result.
See https://github.com/llvm/llvm-project/issues/48872.
Note: the llvm-support.gdb test only works with Debug,
but not RelWithDebInfo because some checked symbols are stripped.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D116646
Currently, lld is marked as a dependency on Windows in
cross-project-tests/CMakeLists.txt which means CMake will fail if lld isn't
enabled. The idea of the cross-project-tests is that tests that don't have
their dependencies met should just be unsupported.
Remove the depenency from the CMake step and check whether Dexter's
platform-specific dependencies have been met in
cross-project-tests/lit.cfg.py. If the dependencies are met then add 'dexter'
to the available_features, otherwise don't and the dexter tests will be
"UNSUPPORTED".
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D115872
These tests were spuriously failing on Windows due to path separators getting
flipped from `/` to `\\` in various parts of dexter:
test_add_breakpoint_with_source_root_dir
test_get_step_info
test_get_step_info_no_source_root_dir
Tested on Windows and Linux.
Patch written by @TWeaver.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D115338
Fixes a failure on the llvm-clang-x86_64-sie-ubuntu-fast buildbot caused
by the test requiring lldb (with the standard dexter lit config), but
not including a "Requires: lldb" clause.
This patch adds a new dexter command, DexDeclareAddress, which is used
to test the relative values of pointer variables. The motivation for
adding this command is to allow meaningful assertions to be made about
pointers that go beyond checking variable availability and null
equality.
The full explanation and syntax is in Commands.md.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D111447
[NFC] As part of using inclusive language within the llvm project, this patch
replaces master with controller in these tests.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D114108
Matching a recent clang change I've made, now 'int[3]' is formatted
without the space between the type and array bound. This commit updates
libDebugInfoDWARF/llvm-dwarfdump to match that formatting.
Actually we can, for now, remove the explicit "operator" handling
entirely - since clang currently won't try to flag any of these as
rebuildable. That seems like a reasonable state for now, but it could be
narrowed down to only apply to conversion operators, most likely - but
would need more nuance for op> and op>> since they would be incorrectly
flagged as already having their template arguments (due to the trailing
'>').
This isn't perfect, since it doesn't use lazy_string - so if the
std::string does contain unprintable characters it might fail, but seems
better than nothing & LLVM doesn't generally store binary data in
std::strings.
I'm not sure if there's a way to make this a bit more general - the
property that matters is that there's /some/ itanium ABI target the
tests can use to compile - not link or run in this case. But this seems
sufficient for the llgdb tests, so it should be sufficient (though
perhaps not necessary) for this roundtrip test.
Compilation is all that's needed here - linking helped avoid certain
false positives in llvm-dwarfdump --verify related to overlapping
functions when those functions were actually in distinct sections.
That's since been fixed, so we can adjust the test to only compile, and
not link.
This test was failing on the PS4 bot because the test attempts to link, but the PS4 platform requires an external
linker that is not present, causing the test to fail. This should get the PS4 bot green again.
D109833 makes the flags `--builder` and `--binary` mutually exclusive, which
caused some regression tests to fail. Add a new substitution
`%dexter_regression_base` that doesn't include the `--builder`, `--cflags` or
`--ldflags` flags and use that for tests that use the `--binary` flag.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D112624
Stephen Tozer