Summary: It's possible for an instance of the visual studio debugger
to return a NoneType line number location when stepping during a
debugging session.
This patches teaches DexTer how to handle this particular case without
crashing out.
Reviewers: Orlando
Differential revision: https://reviews.llvm.org/D75992
On Windows, an error running the debugger typically leaves a process
hanging around in the working directory. When Dexter exits, it can't then
delete the working directory and produces an exception, masking the problem
in the debugger. (This can be worked around by specifying --save-temps).
Rather than hard-erroring, print a warning when we can't delete the working
directory instead.
It'd be much better to improve our error handling, and make the
WorkingDirectory class aware that something's wrong when it enters exit.
However, this is something that's going to mask genuine errors and make
everyones lives harder right now, so I think this non-ideal fix is
important to get in first.
Differential Revision: https://reviews.llvm.org/D74548
These are some minor things that I've run into on Windows, largely in
error handling paths:
* Giving --lldb-executable on Windows triggers a "useless option" code
path, which touches an attribute that only exists in the
list_debuggers tool. Switch this to use hasattr, which will work in
all subtools.
* We were over-decoding some text reporting errors, but only in an
exception path
* The path to lldb on Windows needs to be quoted (even though dexter
isn't making use of it).
Differential Revision: https://reviews.llvm.org/D74546
When writing the Windows dbgeng driver for Dexter, I couldn't work out why it
would either launch a process and leave it free running, or if I started the
process suspended, never do anything with it. The result was a hack to create
and attach processes manually. This has been flaking out on Reids Windows
buildbot, and clearly wasn't a good solution.
Digging into this, it turns out that the "normal" cdb / windbg behaviour of
breaking whenever we attach to a process is not the default: it has to be
explicitly requested from the debug engine. This patch does so (by setting
DEBUG_ENGOPT_INITIAL_BREAK in the engine options), after which we can simply
call "CreateProcessAndAttach2" and everything automagically works.
No test for this behaviour: everything was just broken before.
Differential Revision: https://reviews.llvm.org/D74409
First, add LLD as a dependency on Windows. The windows batch scripts
pass -fuse-ld=lld, so they need it.
Second, decode builder stdout/stderr even if the command fails.
Otherwise it gets printed as b'line 1\n\rline 2\n\r'.
Last, make the batch script one line less noisy. We might want to try to
do more here, though. It would be nice if we could get as close to
possible as lit, where you can literally copy & paste the failing
command to re-run it.
With the two changes above, now the feature tests that use clang++.bat
pass for me. The clang-cl_vs2015 ones still fail, and I'll fix them
separately.
Reviewers: jmorse
Differential Revision: https://reviews.llvm.org/D69725
This is checking the version of Python used to run lit, which is not
necessarily the same as the version used to run the dexter tests. If
the tests are run via the build/bin/llvm-lit[.py] helper script, then
that is likely to pick up whatever version of Python is on PATH.
Conventionally, this will find Python 2. CMake already checks that
Python 3 is in use and puts the path to it in the lit site config, so
this check is redundant, and Python 3 will ultimately be used to run
dexter.
Reviewers: jmorse
Differential Revision: https://reviews.llvm.org/D69724
When running a program, Dexter single steps if it's in one of the source
files under test, or free-runs if it isn't. Handle the circumstance where
the current source file simply isn't known.
I baked the "test" subcommand into the %dexter substituion, as that's
what all of the dexter tests use. However I forgot about the internal
tests for whether dexters features are working. Install a %dexter_base
command to allow those tests to call dexter.py directly, and un-xfail
the tests on darwin.
Update too the list of paths the unittests shouldn't try and cover, as it
tries to load dbgeng on unix machines. Ideally we wouldn't be using this
method of test discovery in the future.
This reverts commit cb935f3456.
Discussion in D68708 advises that green dragon is being briskly
refurbished, and it's good to have this patch up testing it.
Dexter (Debug Experience Tester) is a test-driver for our debug info
integration tests, reading a set of debug experience expectations and
comparing them with the actual behaviour of a program under a debugger.
More about Dexter can be found in the RFC:
http://lists.llvm.org/pipermail/llvm-dev/2019-October/135773.html
and the phab review in D68708. Not all the debuginfo tests have been
transformed into Dexter tests, and we look forwards to doing that
incrementally.
This commit mostly aims to flush out buildbots that are running
debuginfo-tests but don't have python 3 installed, possibly
green-dragon and some windows bots.
Tom Weaver