summaryrefslogtreecommitdiffstats
path: root/debuginfo-tests/test_debuginfo.pl
Commit message (Collapse)AuthorAgeFilesLines
* Reapply "Import Dexter to debuginfo-tests""Jeremy Morse2019-10-311-81/+0
| | | | | | | This reverts commit cb935f345683194e42e6e883d79c5a16479acd74. Discussion in D68708 advises that green dragon is being briskly refurbished, and it's good to have this patch up testing it.
* Revert "Import Dexter to debuginfo-tests"Jeremy Morse2019-10-311-0/+81
| | | | | | This reverts commit f78c236efda85af1e526ac35ed535ef4786450e3. Green dragon breakage was observed; I'll take a look at why.
* Import Dexter to debuginfo-testsJeremy Morse2019-10-311-81/+0
| | | | | | | | | | | | | | | | | 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.
* [debuginfo-tests] Always use the system python to invoke llgdb.py.Ahmed Bougacha2018-06-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | /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
* [debuginfo-tests] Support moving debuginfo-tests to llvm/projectsDon Hinton2017-12-121-0/+80
Summary: Add cmake and lit files needed to run these tests as an external project. Also, copy test_debuginfo.pl from llvm/utils since it's only used here. The copy in llvm/utils must be maintained as long as bots continue to include debuginfo-tests in clang/test. This patch depends on clang patch https://reviews.llvm.org/D41055. Reviewers: zturner, aprantl Reviewed By: aprantl Subscribers: mgorny, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D40971 llvm-svn: 320495
OpenPOWER on IntegriCloud