[lldb-dev] Where is lldb.py?
Zachary Turner
zturner at google.com
Wed Jul 2 14:41:54 PDT 2014
Thanks! I will probably not be able to test it until Monday as the holiday
starts soon, but I will fix anything up unless someone beats me to it.
On Wed, Jul 2, 2014 at 2:20 PM, Greg Clayton <gclayton at apple.com> wrote:
> 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 <zturner at google.com> 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 <deepak at codeplay.com>
> 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 <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
> >>>>>>
> >>>>>> 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 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140702/ee039eb0/attachment.html>
More information about the lldb-dev
mailing list