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
Summary: Make room for mlir-support pretty printers that I would like to add next.
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: merge_guards_bot, mgorny, rriddle, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73726
There was CMake code that would attempt to detect Python 3 even if
LLVM was configured with Python 2, but it messed with the environment
for the other LLVM projects. This commit removes this functionality
and just lkeaves a hard error if Python < 3 is detected and
debuginfo-tests are required.
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
LLDB already requires Python 3 on Windows, so I already configure it
that way. For some reason CMake fails to find the one that Visual Studio
automatically installs at this standard location:
C:/Program Files (x86)/Microsoft Visual Studio/Shared/Python37_64/python.exe
CMake prefers the python on path, which happens to be python 2.7.
Reviewers: aprantl, jmorse
Differential Revision: https://reviews.llvm.org/D69684
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.
These tests almost certainly work on Darwin anyway, I just wanted to
keep things in a fixed, working configuration, while pushing Dexter
up.
I've left Windows unsupported as the dexter command line will need further
adjustment to run dbgeng. This can be abstracted through the %dexter
substitution, but is a task for another time.
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.
This is a follow-up to r364466, but better implemented. Original
commit message still applies:
The breakpoint locations were in places where clang doesn't actually
emit a source location for and depend on the debugger's ability to
move the breakpoint forward onto a line that is already in the
function epilogue. In my testing older versions of LLDB fail to do
that, so I'm modifying the test to force a break-able location by
calling a noinline function.
<rdar://problem/52079841>
llvm-svn: 364589
The breakpoint locations were in places where clang doesn't actually
emit a source location for and depend on the debugger's ability to
move the breakpoint forward onto a line that is already in the
function epilogue. In my testing older versions of LLDB fail to do
that, so I'm modifying the test to force a break-able location by
calling a noinline function.
<rdar://problem/52079841>
llvm-svn: 364466
Summary: This creates an integration test for global constants
Reviewers: rnk
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62974
llvm-svn: 362745
This creates an integration test for inlined call line tables, and in
particular, ones that are discontiguous. We've had issues in the past
with discontiguous inline line tables, and until r362429 LLD didn't
write the inlinees section into the PDB.
The test was reduced from https://crbug.com/965670
Reviewers: thakis
Differential Revision: https://reviews.llvm.org/D62758
llvm-svn: 362431
This is an initial prototype of how we can run debugger integration
tests on Windows. cdb and windbg share a command language and debugger
engine. Visual Studio has its own, but we should at least be able to use
cdb as the basis for optimized debug info integration tests.
There's a lot of work to do here still. For example:
- Make fewer assumptions about the SDK location
- Don't assume x64 (important, I need x86 testing)
- More environment isolation, have lit setup vcvars instead of passing
LIB and INCLUDE down.
- Write a .py file to replace the grep+sed RUN line
But, this seemed like a good enough concept to commit as is, since it's
useful to me already.
Reviewers: aprantl, zturner
Differential Revision: https://reviews.llvm.org/D54187
llvm-svn: 361889
Check that the debugger can pretty-print unique_ptr and shared_ptr when
passed as a function argument.
This was reverted in r339961 because of a bug in the version of lldb
installed on the public Green Dragon builders.
rdar://42314305
llvm-svn: 340189
SafeStack support for Darwin has not been functional and was disabled in
r339719/r339720. Disable Darwin for the safestack debuginfo test.
llvm-svn: 339732
Some of Apple's public CI nodes ship an lldb which has trouble debugging
the asan-deque.cpp test. Specifically, that lldb appears to either parse
location lists in the test program incorrectly or to have a broken
std::deque data formatter.
We don't want to work around this by weakening the integration test, and
we're unable to update the lldb version on the CI node at the moment.
The compromise is to require AppleLLDB >= 1000 when AppleLLDB is being
used to debug this test.
Reviewed (in person) by Adrian Prantl.
Bot failure:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA/48074
rdar://42892721
llvm-svn: 338937
emplace_back was added in C++11, and its usage isn't critical to what's being
tested so using push_back instead will allow this test to work with more
compilers.
llvm-svn: 338371
LowerDbgDeclare inserts a dbg.value before each use of an address
described by a dbg.declare. When inserting a dbg.value before a CallInst
use, however, it fails to append DW_OP_deref to the DIExpression.
The DW_OP_deref is needed to reflect the fact that a dbg.value describes
a source variable directly (as opposed to a dbg.declare, which relies on
pointer indirection).
This patch adds in the DW_OP_deref where needed. This results in the
correct values being shown during a debug session for a program compiled
with ASan and optimizations (see https://reviews.llvm.org/D49520). Note
that ConvertDebugDeclareToDebugValue is already correct -- no changes
there were needed.
One complication is that SelectionDAG is unable to distinguish between
direct and indirect frame-index (FRAMEIX) SDDbgValues. This patch also
fixes this long-standing issue in order to not regress integration tests
relying on the incorrect assumption that all frame-index SDDbgValues are
indirect. This is a necessary fix: the newly-added DW_OP_derefs cannot
be lowered properly otherwise. Basically the fix prevents a direct
SDDbgValue with DIExpression(DW_OP_deref) from being dereferenced twice
by a debugger. There were a handful of tests relying on this incorrect
"FRAMEIX => indirect" assumption which actually had incorrect
DW_AT_locations: these are all fixed up in this patch.
Testing:
- check-llvm, and an end-to-end test using lldb to debug an optimized
program.
- Existing unit tests for DIExpression::appendToStack fully cover the
new DIExpression::append utility.
- check-debuginfo (the debug info integration tests)
Differential Revision: https://reviews.llvm.org/D49454
llvm-svn: 338069
/usr/bin/env is recommended as a cross-platform way to find python. But:
- we're only using lldb on darwin, where we know python (or at least,
the xcrun-style shortcut) is in /usr/bin/
- the python interpreter in LLDB comes from /S/L/F:
$ otool -L Contents/SharedFrameworks/LLDB.framework/LLDB | grep Python
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
so when we use the lldb python module, it calls into the swig/python
support in the lldb framework, and if there's a mismatch between the
interpreter and the linked python, weird things occur.
In theory, I believe this should be done by:
- looking for the LLDB framework (llgdb.py does some of that)
- finding the binary inside the framework
- looking for the Python it was linked against (otool -L)
- finding the interpreter executable inside the Python.framework
But in practice, that's only different if we use a custom LLDB
framework/pythonpath when running these tests, and AFAIK nobody does
that right now, so the code would be dead anyway.
Don't pretend we can use any arbitrary python: just use the system one.
Differential Revision: https://reviews.llvm.org/D47967
llvm-svn: 334369
Jeremy Morse