diff options
author | Ahmed Bougacha <ahmed.bougacha@gmail.com> | 2018-06-10 19:38:26 +0000 |
---|---|---|
committer | Ahmed Bougacha <ahmed.bougacha@gmail.com> | 2018-06-10 19:38:26 +0000 |
commit | 3629e3a2a8214e08dacf1034f5ab253ca0dba30a (patch) | |
tree | f63839580f72f8111f4cfb63812acad6c60c8236 /lldb/packages/Python/lldbsuite/test/python_api/default-constructor | |
parent | 304bd747af53232e717d5ad5c4f61de599063bcd (diff) | |
download | bcm5719-llvm-3629e3a2a8214e08dacf1034f5ab253ca0dba30a.tar.gz bcm5719-llvm-3629e3a2a8214e08dacf1034f5ab253ca0dba30a.zip |
[debuginfo-tests] Always use the system python to invoke llgdb.py.
/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
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/default-constructor')
0 files changed, 0 insertions, 0 deletions