Following up on pipe support for windows, I added a host layer which should improve things on windows. Please test the changes and make them work if I didn't catch everything as I can't build on windows, but tried to get everything right. The commit was:
% svn commit Sending include/lldb/Core/ConnectionFileDescriptor.h Adding include/lldb/Host/Pipe.h Sending lldb.xcodeproj/project.pbxproj Sending source/Core/ConnectionFileDescriptor.cpp Sending source/Host/common/CMakeLists.txt Adding source/Host/common/Pipe.cpp Sending source/Interpreter/ScriptInterpreterPython.cpp Sending source/Target/Process.cpp Transmitting file data ........ Committed revision 212220. > On Jul 2, 2014, at 1:23 PM, Zachary Turner <[email protected]> wrote: > > Ahh, yea that was it. Strange, I actually did a recursive file search from > the root and it didn't find anything. > > > On Wed, Jul 2, 2014 at 1:21 PM, Deepak Panickal <[email protected]> wrote: > The LLDB python package is created within the build directory. > Assuming it's a debug build, could you check > llvm/build/Debug/lib/site-packages? > > > On 02/07/2014 21:19, Zachary Turner wrote: >> So it seems something is still wrong. I'm generating the build files with >> this command: >> >> cmake -G Ninja -DLLDB_DISABLE_PYTHON=0 >> -DPYTHON_INCLUDE_DIR=c:\Python27\include >> -DPYTHON_LIBRARY=C:\Python27\libs\python27.lib ..\.. >> >> (I have the patch I posted in the other thread applied, so >> LLDB_DISABLE_PYTHON=0 implies >> LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION=1) >> >> I successfully run a build, and after the build I observe the following: >> >> 1) LLDBWrapPython.cpp and lldb.py are in llvm/build/ninja/tools/lldb/scripts >> >> 2) There is no _lldb.pyd anywhere. >> >> 3) My Python is installed in C:\Python27, and C:\Python27\Lib\site-packages >> is empty. >> >> #2 and #3 seem like an error, am I doing something wrong in my build? >> >> >> On Wed, Jul 2, 2014 at 12:27 PM, Deepak Panickal <[email protected]> wrote: >> 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 >> >> >> On 02/07/2014 19:48, Zachary Turner wrote: >>> One more problem. Compiled successfully, and ran LLDB. Upon startup I get >>> this warning: >>> >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> 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 "<string>", line 1, in <module> >>> NameError: name 'run_one_line' is not defined >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> NameError: name 'run_one_line' is not defined >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> NameError: name 'run_one_line' is not defined >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> NameError: name 'run_one_line' is not defined >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> 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? >>> >>> >>> On Tue, Jul 1, 2014 at 4:52 PM, Deepak Panickal <[email protected]> wrote: >>> 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 >>> >>> >>> On 01/07/2014 23:56, Zachary Turner wrote: >>>> 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. >>>> >>>> >>>> >>>> On Tue, Jul 1, 2014 at 3:41 PM, Zachary Turner <[email protected]> wrote: >>>> 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. >>>> >>>> >>>> On Tue, Jul 1, 2014 at 10:54 AM, Deepak Panickal <[email protected]> >>>> wrote: >>>> 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 >>>> >>>> >>>> On 24/06/14 12:23, Deepak Panickal wrote: >>>>> 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 >>>>> >>>>> On 24/06/14 01:24, Zachary Turner wrote: >>>>>> 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. >>>>>> >>>>>> >>>>>> On Mon, Jun 23, 2014 at 5:16 PM, Zachary Turner <[email protected]> >>>>>> wrote: >>>>>> 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. >>>>>> >>>>>> >>>>>> On Mon, Jun 23, 2014 at 5:09 PM, Deepak Panickal <[email protected]> >>>>>> wrote: >>>>>> 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. >>>>>> >>>>>> http://reviews.llvm.org/D2980 >>>>>> >>>>>> We're planning to fix it up quite soon to match with the current tip. >>>>>> >>>>>> Thanks, >>>>>> Deepak >>>>>> >>>>>> >>>>>> On 23/06/2014 22:09, Zachary Turner wrote: >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 23, 2014 at 2:07 PM, Todd Fiala <[email protected]> wrote: >>>>>>> You can volunteer to write it more portably ;-) >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 23, 2014 at 1:55 PM, Zachary Turner <[email protected]> >>>>>>> wrote: >>>>>>> Hmm, a shell script. kind of a non-starter for Windows. Any reason >>>>>>> this can't be a python script? >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 23, 2014 at 1:52 PM, Greg Clayton <[email protected]> >>>>>>> wrote: >>>>>>> It is generated by running swig with many options. See: >>>>>>> >>>>>>> lldb/scripts/build-swig-wrapper-classes.sh >>>>>>> >>>>>>> >>>>>>> >>>>>>> > On Jun 23, 2014, at 1:41 PM, Zachary Turner <[email protected]> >>>>>>> > wrote: >>>>>>> > >>>>>>> > 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? >>>>>>> > _______________________________________________ >>>>>>> > lldb-dev mailing list >>>>>>> > [email protected] >>>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lldb-dev mailing list >>>>>>> [email protected] >>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Todd Fiala | Software Engineer | [email protected] | >>>>>>> 650-943-3180 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lldb-dev mailing list >>>>>>> >>>>>>> [email protected] >>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> lldb-dev mailing list >>>>>> [email protected] >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> lldb-dev mailing list >>>>> >>>>> [email protected] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> >>>> >>>> >>> >>> >> >> > > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
