I have no objection to moving in that direction (enabling remote
debugging). Zach just pointed out that we'd first have to port lldb-server
to Windows. Offhand, I don't know how much of an effort that would be.
In the near-term, I'm focused on postmortem debugging, so this wouldn't be
a
Is there a tarball somewhere that I can pull those files out from?
I tried with an older build I have on my machine; and copying site-packages
over into %LLVM%\lib did allow lldb module loading to get a bit further,
but it still failed because SWIG-generated wrapper does not match the .pyd
LLDB_DEFAULT_PYTHONHOME is an internal thing; I haven’t upstreamed it – for a
while, it conflicted with Zach’s implementation, but I redid it, and everything
is happy now. If you think it would be useful, I could upstream it. It’s fairly
small, and plays nice with Zach’s Python stuff.
The
BTW, _lldb.pyd is just a symlink of liblldb.dll. Perhaps you could try
creating the symlink manually and copying the other files (e.g.
embedded_interpreter.py, six.py, etc) over to see if it works. If it does,
it would at least confirm that this is everything we need to do to get it
working for
At least on my machine, finding Python is not the problem, because Python
installer has added C:\Python35 to the PATH. (It can also be found in the
Registry at
HKLM\SOFTWARE\Python\PythonCore\3.5-32\InstallPath).
On Mon, Nov 28, 2016 at 10:17 AM, Zachary Turner wrote:
> I
I overlooked that part of it, but yes that is another separate issue.
(BTW, _lldb.pyd is simply a symlink to liblldb.dll).
In any case, yea I think the entire lib/site-packages folder needs to be
included.
On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov wrote:
> Please
Please correct me if I'm wrong, but isn't the issue here that LLDB's Python
support files don't get packaged into the Windows installer? Does
packaging them somehow depend on knowing what the Python installation path
is?
On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg wrote:
The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and -DPYTHON_HOME=.
I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
On Mon, Nov 28, 2016
So it sounds like you're saying that in order for Python support to work as
part of an LLDB shipped in the installer, we need to do set 3 variables at
CMake time.
1) -DLLDB_RELOCATABLE_PYTHON=TRUE
2) -DPYTHON_HOME =
3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
Now because of #3, the lldb shipped in the
https://llvm.org/bugs/show_bug.cgi?id=31192
Bug ID: 31192
Summary: Unwinding of noreturn functions fails if the function
is the last function in a section
Product: lldb
Version: unspecified
Hardware: All
10 matches
Mail list logo