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
This patch adds a command, DexFinishTest, that allows a Dexter test to
be conditionally finished at a given breakpoint. This command has the
same set of arguments as DexLimitSteps, except that it does not allow a
line range (from_line, to_line), only a single line (on_line).
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D111988
This patch allows a visual studio solution file to be passed directly
into Dexter, instead of using a pre-built binary and a small internal
solution file with template arguments. This is primarily to allow
launching an application that has specific launch configuration
requirements, without needing all the details of this configuration to
be built directly into Dexter or adding a config file that simply
duplicates existing settings in the VS solution.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D110167
Fixes issue found on greendragon buildbot, in which an incorrectly
indented statement following an if block led to entire frames being
dropped instead of simply filtering unneeded watches.
This reverts commit 1f44fa3ac1.
Dexter currently accepts two possible arguments to determine the binary
used for testing; either --builder <builder> (and optionally
compiler/linker flags) to build the binary, or --binary <binary> to use
the provided binary directly. If both are passed, then --binary
overrides --builder; if neither are passed, then an error is raised.
This patch instead puts these arguments into a required mutually
exclusive argument group, so that an error is automatically raised by
argparse if both or neither are given.
As an additional change, the --cflags and --ldflags will now raise a
warning if they are passed without the --builder flag, as they are
meaningless if Dexter is using a pre-built binary.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D109833
Currently, Dexter's model for fetching watch values is to build a list of
expressions to watch before running the debugger, then evaluating all of them at
each breakpoint, then finally looking up the values of these expressions at each
line they were expected on. When using dexter on a large project while watching
many different expressions, this is very slow, as Dexter will make a massive
number of calls made to the debugger's API, the vast majority of which are not
being used for anything. This patch fixes this issue by having Dexter only
evaluate expressions at a breakpoint when it will be used by a Dexter command.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D107070
This change modifies the existing check-debuginfo target to only run the
debuginfo tests within the cross-project-tests, and adds a new target
(check-cross-project) which runs all the tests. The former has also been
modified to not be included in check-all (since the check-cross-project
target covers them).
Differential Revision: https://reviews.llvm.org/D96513
Reviewed by: aprantl
Also mark debuginfo_tests as UNSUPPORTED if clang can't be found and
remove it from the list of test dependencies if not in
LLVM_ENABLE_PROJECTS.
Differential Revision: https://reviews.llvm.org/D96511
Reviewed by: aprantl
gbtozers