We'll be at Tied House as usual, starting on Thursday the 1st at 7pm!
If you can, help us plan and RSVP here: http://meetu.ps/31LkwJ
See everyone there! (And if you can't make it, early happy holidays :) )
___
lldb-dev mailing list
lldb-dev@lists.llvm.o
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 priority
One thing that we have talked about is to move the ProcessWindows stuff into
lldb-server (it has a NativeProcess and NativeThread class you would need to
subclass instead of making ProcessWindows and ThreadWindows classes) instead of
making a native plug-in that is only useful on the current sys
I'm looking at adding a FreeBSD timeout pre-kill hook, and I'm
interested in mirroring the data currently collected on Linux and OS
X. Is there a sample output from a timed-out LLDB test available
somewhere?
-Ed
___
lldb-dev mailing list
lldb-dev@lists.l
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
module.
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 pr
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 y
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 overlooked that part
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 correct me if I'm wrong,
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 ar
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 in
Windows has no concept of a default python installation, and I can’t be sure
what version of python my users have, if any, so I need to solve 2 problems:
1) Where is python when I’m building?
2) Where is python when I’m running?
To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, a
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
OS:
14 matches
Mail list logo
