[lldb-dev] Where is lldb.py?

Zachary Turner zturner at google.com
Wed Jul 2 11:48:54 PDT 2014 

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/e0bdbd25/attachment.html>

More information about the lldb-dev mailing list