[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

1 files changed, 2 insertions, 1 deletions

diff --git a/debuginfo-tests/test_debuginfo.pl b/debuginfo-tests/test_debuginfo.pl
index adc11c39d99..e4c2a5ea24c 100755
--- a/debuginfo-tests/test_debuginfo.pl
+++ b/debuginfo-tests/test_debuginfo.pl
@@ -56,7 +56,8 @@ my $my_debugger = $ENV{'DEBUGGER'};
 if (!$my_debugger) {
     if ($use_lldb) {
         my $path = dirname(Cwd::abs_path($0));
-        $my_debugger = "/usr/bin/env python $path/llgdb.py";
+        # At least on darwin, LLDB needs te system python.
+        $my_debugger = "/usr/bin/python $path/llgdb.py";
     } else {
         $my_debugger = "gdb";
     }