I’m trying to get the test suite into a working state on windows, or at the very least get it to the point where it fails by saying that none of the tests are supported on this platform. I seem to be missing this file lldb.py though. Is it supposed to be in the tree, or is it generated somehow?
It is generated by running swig with many options. See:
lldb/scripts/build-swig-wrapper-classes.sh
Hmm, a shell script. kind of a non-starter for Windows. Any reason this can’t be a python script?
Hi Zachary,
As I can see, this file is generated at build time by modify-python-lldb.py script started by Makefile. It goes to tools/lldb/scripts directory that will be created in your build directory.
Hmm, a shell script. kind of a non-starter for Windows. Any reason this can't be a python script?
We currently have an option to build LLDB without python, so I would rather avoid requiring python in order to build LLDB as I hear from your build guys that building python is a very long and complex process. Windows doesn't come with python by default, so that seems like a bad precedent to set for a windows build. You might want to translate the .sh into a .bat file for use on windows? Not the best solution as it would always need to be updated whenever the .sh file is updated, but probably better than requiring python.
Greg
You can volunteer to write it more portably 
I’m already volunteering, just want to make sure it’s ok before I do the work 
That being said, Greg mentions in an earlier message that it might not be possible because we wish to support a Python-less build. Who uses this out of curiosity? I don’t think any Windows developers mind installing Python as a requirement. It’s also mentioned on the Building LLDB page (http://lldb.llvm.org/build.html) that Python is a dependency
We have already ported the lldb.py generating scripts to Python for portability and got the API working in Windows and Linux.
We can load an ELF file, dump symbols, do remote debugging etc.
This work has been put into review sometime ago, so might need some updation.
⚙ D2980 LLDB Python API support on Windows (ported the SWIG wrapper shell scripts to Python) <http://llvm-reviews.chandlerc.com/D2980>
We're planning to fix it up quite soon to match with the current tip.
Thanks,
Deepak
Interesting. I had already made some progress towards this in my own branch, so I’ll have a look.
BTW, I’m not sure what your solution was regarding the missing python modules, but the pexpect one in particualr is pretty trivial to fix. Just change it to subprocess.run() and remove the import of pexpect.
By the way, does this compile with MSVC 2013? Many of the changes I had to make to get things compiling don’t seem to be present in this patch.
Yes, it was compiling with MSVC 2013. It hasn't been updated though since the review was submitted.
We're working on it now, so should be fixed to current tip and upstreamed soon.
Thanks,
Deepak
Hi,
I'm planning to upstream the Windows Python API changes now.
This has been done by completely rewriting the shell scripts used for the API generation in Python so that it's portable across different platforms. We have tested it on both Windows and Linux successfully.
I have added a new CMake variable "LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION", to control if the new Python scripts for managing SWIG generating the API are enabled or not. This is disabled by default to not impact other platforms. This variable can be removed once we move all the platforms to the Python scripts from the shell scripts. There's some cleanup to be done, which I'll be working on.
Please let me know if there are any issues or comments.
Thanks,
Deepak
I get the following warning when running cmake with no special options passed via -D
CMake Warning (dev) at tools/lldb/CMakeLists.txt:234 (target_link_libraries):
Policy CMP0023 is not set: Plain and keyword target_link_libraries
signatures cannot be mixed. Run “cmake --help-policy CMP0023” for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
The keyword signature for target_link_libraries has already been used with
the target “liblldb”. All uses of target_link_libraries with a target
should be either all-keyword or all-plain.
The uses of the keyword signature are here:
- cmake/modules/AddLLVM.cmake:331 (target_link_libraries)
Call Stack (most recent call first):
tools/lldb/source/CMakeLists.txt:214 (add_lldb_library)
This warning is for project developers. Use -Wno-dev to suppress it.
Also getting the following error:
For reference, I ran cmake as
cmake -DLLDB_DISABLE_PYTHON=0 -DPYTHON_INCLUDE_DIR=c:\python27\include -DPYTHON_LIBRARY=C:\Python27\libs\python27.lib …..
D:\src\llvm\build\ninja>ninja lldb
[88/433] Building lldb python wrapper
FAILED: cmd.exe /c cd /D D:\src\llvm\build\ninja\tools\lldb\scripts && env PYTHON_EXECUTABLE=C:/Python27/python.exe D:/src/llvm/tools/lldb/scripts/build-swig-wrapper-classes.sh D:/src/llvm/tools/lldb D:/src/llvm/build/ninja/tools/lldb/scripts D:/src/llvm/build/ninja/tools/lldb/scripts D:/src/llvm/bu
ild/ninja -m && env PYTHON_EXECUTABLE=C:/Python27/python.exe D:/src/llvm/tools/lldb/scripts/finish-swig-wrapper-classes.sh D:/src/llvm/tools/lldb D:/src/llvm/build/ninja/tools/lldb/scripts D:/src/llvm/build/ninja/tools/lldb/scripts D:/src/llvm/build/ninja -m
env: D:/src/llvm/tools/lldb/scripts/build-swig-wrapper-classes.sh: Exec format error
[88/433] Building CXX object tools\lldb\source\Plugins\Process\mach-core\CMakeFiles\lldbPluginProcessMachCore.dir\ProcessMachCore.cpp.obj
ninja: build stopped: subcommand failed.
Thanks, I'll look into the CMake warning.
For now, you have to enable the variable LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION specifically to use the new python scripts, when LLDB_DISABLE_PYTHON is disabled.
Which is why not using the variable would break the build on Windows. On Linux, it would work both ways.
I added this variable so that the new scripts can be tested without affecting normal builds on other platforms.
Could you please try,
cmake*-DLLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION=1* -DLLDB_DISABLE_PYTHON=0 -DPYTHON_INCLUDE_DIR=c:\python27\include -DPYTHON_LIBRARY=C:\Python27\libs\python27.lib ..\..
Thanks,
Deepak
Thanks, I’m trying that now, and there’s a few other errors, but I think I can work through them.
One more problem. Compiled successfully, and ran LLDB. Upon startup I get this warning:
Traceback (most recent call last):
File “”, line 1, in
ImportError: No module named lldb.embedded_interpreter
(lldb)
So something is wrong there. Typing “script” with no arguments gives this:
Traceback (most recent call last):
File “”, line 1, in
NameError: name ‘run_one_line’ is not defined
Traceback (most recent call last):
File “”, line 1, in
NameError: name ‘run_one_line’ is not defined
Traceback (most recent call last):
File “”, line 1, in
NameError: name ‘run_one_line’ is not defined
Traceback (most recent call last):
File “”, line 1, in
NameError: name ‘run_one_line’ is not defined
Traceback (most recent call last):
File “”, line 1, in
NameError: name ‘run_one_line’ is not defined
Just curious, what has been your use case for this so far? Do you have it working on your end? If so, what kind of things can you successfully do with it?
That problem is due to PYTHONPATH not being exported to the location where the python packages are built.
Similar to Linux, you have to export PYTHONPATH to build_dir/lib/site-packages/python.
The _lldb.pyd file symlinks to liblldb.dll on Windows.
Regardles, you would still get an error on the command-line due to the missing python termios module on Windows.
In ScriptInterpreterPython.cpp:2628, the termios module is imported, which would fail immediately.
PyRun_SimpleString ("sys.dont_write_bytecode = 1; import lldb.embedded_interpreter; from lldb.embedded_interpreter import run_python_interpreter; from lldb.embedded_interpreter import run_one_line; from termios import *");
We have yet to solve this dependency on Windows.
However, we can use the API directly for now.
AFAIK, these modules are only used for the command-line interpreter, so does not affect using the API directly.
If we comment out these out, we can run the examples in lldb/examples/python/, such as globals.py to load an ELF file and dump the globals using the Python API on Windows.
Thanks,
Deepak
Assuming that termios is used for what it sounds like (sending commands to the terminal), couldn’t this be solved by just not outputting to stdout in the python scripts, and instead using the SWIG-exported python wrappers to call whatever method accepts raw command strings?
Sure, I guess that might solve the issue.