[lldb-dev] Where is lldb.py?
Deepak Panickal
deepak at codeplay.com
Wed Jul 2 12:56:22 PDT 2014
Sure, I guess that might solve the issue.
On 02/07/2014 20:49, Zachary Turner wrote:
> 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?
>
>
> On Wed, Jul 2, 2014 at 12:27 PM, Deepak Panickal <deepak at codeplay.com
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto:lldb-dev at cs.uiuc.edu>
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Todd Fiala | Software Engineer |
>>>>>> tfiala at google.com
>>>>>> <mailto:tfiala at google.com> |
>>>>>> 650-943-3180
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> lldb-dev mailing list
>>>>>> lldb-dev at cs.uiuc.edu <mailto: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
>>>>> <mailto: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 <mailto:lldb-dev at cs.uiuc.edu>
>>>> http://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/4462b1ef/attachment.html>
More information about the lldb-dev
mailing list