Re: [lldb-dev] Refactoring in LLDB Windows Plugin

2016-11-28 Thread Adrian McCarthy via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Vadim Chugunov via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Ted Woodward via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Vadim Chugunov via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Zachary Turner via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Vadim Chugunov via lldb-dev
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:

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Hans Wennborg via lldb-dev
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

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Zachary Turner via lldb-dev
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

[lldb-dev] [Bug 31192] New: Unwinding of noreturn functions fails if the function is the last function in a section

2016-11-28 Thread via lldb-dev
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