3629e3a2a8
/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 |
||
|---|---|---|
| .. | ||
| .arcconfig | ||
| CMakeLists.txt | ||
| README.txt | ||
| aggregate-indirect-arg.cpp | ||
| apple-accel.cpp | ||
| asan-blocks.c | ||
| asan.c | ||
| block_var.m | ||
| blocks.m | ||
| ctor.cpp | ||
| dbg-arg.c | ||
| foreach.m | ||
| forward-declare-class.cpp | ||
| lit.cfg.py | ||
| lit.local.cfg | ||
| lit.site.cfg.py.in | ||
| llgdb.py | ||
| nested-struct.cpp | ||
| nrvo-string.cpp | ||
| safestack.c | ||
| sret.cpp | ||
| stack-var.c | ||
| static-member-2.cpp | ||
| static-member.cpp | ||
| test_debuginfo.pl | ||
| vla.c | ||
README.txt
-*- rst -*-
This is a collection of tests to check debugging information generated by
compiler. This test suite can be checked out inside clang/test folder. This
will enable 'make test' for clang to pick up these tests. Typically, test
cases included here includes debugger commands and intended debugger output
as comments in source file using DEBUGGER: and CHECK: as prefixes respectively.
For example::
define i32 @f1(i32 %i) nounwind ssp {
; DEBUGGER: break f1
; DEBUGGER: r
; DEBUGGER: p i
; CHECK: $1 = 42
entry:
}
is a testcase where the debugger is asked to break at function 'f1' and
print value of argument 'i'. The expected value of 'i' is 42 in this case.