[lldb-dev] Where is lldb.py?

Zachary Turner zturner at google.com
Wed Jul 2 13:19:18 PDT 2014 

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 <deepak at codeplay.com>
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 <deepak at codeplay.com>
> 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 <zturner at google.com>
>> 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 <deepak at codeplay.com>
>>> 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 <zturner at google.com>
>>>> 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 <deepak at codeplay.com>
>>>>> 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
>>>>>> <http://llvm-reviews.chandlerc.com/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 <tfiala at google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> You can volunteer to write it more portably ;-)
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 23, 2014 at 1:55 PM, Zachary Turner <zturner at google.com>
>>>>>>> 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 <gclayton at apple.com>
>>>>>>>> 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 <zturner at google.com>
>>>>>>>>> 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
>>>>>>>>> > lldb-dev at cs.uiuc.edu
>>>>>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> lldb-dev mailing list
>>>>>>>> lldb-dev at cs.uiuc.edu
>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   --
>>>>>>>   Todd Fiala |  Software Engineer |  tfiala at google.com |
>>>>>>> 650-943-3180
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> lldb-dev mailing list
>>>>>> lldb-dev at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> lldb-dev mailing listlldb-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140702/a07c3af6/attachment.html>

More information about the lldb-dev mailing list