Ahh, that would make sense as well, since LLDB links against liblldb as a dll. Don't see a good solution to this short of forcing dynamic linking. liblldb has to be a dll because it needs to be visible to python as an extension module. And if it's a dll and uses static linking, then we would have to require that lldb.exe not pass file handles across the dll boundary. If that's easy then great, but I suspect it probably isn't.
Honestly dynamic linking was created to solve exactly these kinds of problems. Yes there's the redist issue if on Windows < 10, but it seems like a small price to pay for something that doesn't have weird subtle bugs. And as time goes on, more and more people will be on windows 10 anyway. Does the redistributable issue present a challenge for your use case? On Wed, Jan 11, 2017 at 3:45 PM Vadim Chugunov <vadi...@gmail.com> wrote: > Okay, as far as I can see, the issue is not with Python, but that lldb.exe > and liblldb.dll have their own private copies of the CRT. > > When startup script is given on the command line, lldb.exe creates a pipe, > writes the script into the write end, wraps a stdio file around the read > end, and gives the resulting FILE* to SBDebugger::SetInputFileHandle(). > Unfortunately, since SBDebugger lives in liblldb.dll, with its own copy of > the CRT, that handle is not valid there. Later, it tries to read from that > handle, and... boom. > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
