Since Dexter no longer intends to build any code, the ShouldBuild
property in any Visual Studio project being run by Dexter should be
false to ensure that a build step is never invoked by Dexter, whether
the project has already been built or not.
Reviewed by: OCHyams
The purpose of this example is to provide a case where the debugger /
debug info experience could be improved. A recent commit by clang
(0d2860b795) changed codegen such that it
changes how "small structs" are initialized, in a way that the debugger
is now able to correctly display the variable being targeted by this
test.
In order to keep the example relevant, i.e. failing, this commit makes
it so that the struct is now "big enough" to not trigger the new
codegen.
Currently if Dexter encounters a parser error with a command, the resulting
error message will refer to the most recently declared file (i.e. the source
file it is testing) rather than the file containing the command itself. This
patch fixes this so that parser errors point towards the correct location.
The issue with these test failures is that the dSYM was not being found
by lldb, which is why setting breakpoints was failing and lldb quit
without performing any steps. This change copies the dSYM to the same
temp directory that the executable is copied to.
The patch in https://reviews.llvm.org/D151465 broke greendragon, because
it is hardcoding the use of libstdc++ which is not available on darwin.
XFAILing these tests till they can be fixed.
The optnone tests, following the removal of the Dexter builder in a
prior patch (45a40c16), are experiencing intermittent failures. This
patch marks them unsupported to be fixed in a new commit, rather than
reverting the Dexter patch.
This patch makes a further attempt to fix the tests broken by the
previous revision by ensuring that the command line for the modified
Dexter tests use -std=gnu++11, in keeping with the old build script.
This reverts commit 5647f2908d.
Re-application of the Dexter builder removal reversed due to continued
errors on the green dragon LLDB buildbot:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/59716/
Cause of the error is unclear, but it looks as though there is some
unexpected non-determinism in the test failures.
This reverts commit 323270451d.
The error message "Couldn't lookup symbols" emitted from IRExecutionUnit
is grammatically incorrect. "Lookup" is noun when spelled without a
space. Update the error message to use the verb "look up" instead.
Following 262520a3, tests on windows bots began failing due to an incorrect
substitution in the previous patch, where clang-cl was used instead of
clang_cl.
Also fixes an inconsistency in the builders used for some of the tests
in 'dexter-tests', where %clang++ was used for some tests and %clang for
tests that should have identical RUN lines.
See "discussion":
https://discourse.llvm.org/t/rfc-dexter-feature-removals/60462
This patch removes the builder functionality from Dexter, as it is an active
maintenance burden and is no longer required since Dexter is being invoked by
other test runners that can handle the build step better, and there has been no
objection that it is still needed.
Differential Revision: https://reviews.llvm.org/D151465
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
Adds a pair of options for Dexter that allow the user to specify a
timeout duration. These options are:
* --timeout-total: Times out if the total run-time of the debugger session
exceeds <timeout-total> seconds.
* --timeout-breakpoint: Times out if the time without hitting a
breakpoint exceeds <timeout-breakpoint> seconds.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D145063
Adds a basic logging class to Dexter that uses the existing PrettyOutput
class for printing and supports 3 levels of verbosity (note, warning,
error). Intended to consolidate the logging logic for Dexter into one
place, removing the need for conditional log statements and making it
easier for us later if we wish to use a more complete logging class.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D144983
Adds an option to Dexter that passes command line arguments to the
debugged process, following (and in addition to) any arguments given by
the DexCommandLine command.
Differential Revision: https://reviews.llvm.org/D144979
The Visual Studio debugger currently uses blocking calls to Go and
StepInto, which interferes with Dexter's ability to do any processing
(e.g. checking for time outs) in between breakpoints. This patch updates
these functions to use non-blocking calls.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D144986
DexExpectStepOrder uses the line to expect a debugger step from the actual line
of the command in the Dexter source file. Now Dexter scripts have mainly moved
to thier own script files instead of the actual source, there should be a
option to override this behaviour to choose your own debugger step location.
Reviewed By: Orlando
Differential Revision: https://reviews.llvm.org/D142099
The test case optnone-simple-functions.cpp is expected to be compiled
unoptimized even under -O2 because of attribute optnone. But this attribute is
missed for main function, and caused the fail in
https://lab.llvm.org/buildbot/#/builders/217/builds/14046 when it triggered
optimizations. This patch fixes that by adding attribute optnone to main
function.
Differential Revision: https://reviews.llvm.org/D136778
The test dexter/feature_tests/commands/perfect/expect_step_kind/direction.cpp
was failing on a machine because __libc_start_call_main was not identified as a
"frame below main" (a frame we don't want to gather information from), causing
dexter to count one more step than expected in the test.
Add __libc_start_call_main to the list of "frames below main". There may
be a more robust way of doing this but this is a pragmatic solution we can
use for now.
The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.
Differential Revision: https://reviews.llvm.org/D128830
This test would previously expect one of the parameters to have
an incorrect DW_AT_location. Stepping through `fun` with a debugger
would then no reflect updates to one of the parameters.
With a recent change to Clang's DeadArgumentEliminationPass
(see `879f5118fc74657e4a5c4eff6810098e1eed75ac`) the generated
DWARF does not contain a location for `parama`, and stepping through
the function with `lldb` works as expected.
Differential Revision: https://reviews.llvm.org/D132664
DR2338 clarified that it was undefined behavior to set the value outside the
range of the enumerations values for an enum without a fixed underlying type.
We should diagnose this with a constant expression context.
Differential Revision: https://reviews.llvm.org/D130058
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)
