We might think about adding pipe support into the Host layer in LLDB. We use pipes in a few different places (IOHandlerProcessSTDIO, ScriptInterpreterPython and ConnectionFileDescriptor::OpenCommandPipe()).
It would be nice to wrap this up into a lldb_private::host::Pipe() and use this new abstract class in all places. Then the unix variants will have the default pipe() implementation, and Windows will use _pipe(). Right now the windows builds just disable pipes which will affect the ability to interrupt file reads, and interrupt the process IO. Greg > On Jul 1, 2014, at 5:34 PM, Zachary Turner <[email protected]> wrote: > > > > > On Tue, Jul 1, 2014 at 10:57 AM, Deepak Panickal <[email protected]> wrote: > > Modified: lldb/trunk/include/lldb/lldb-python.h > URL: > http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-python.h?rev=212111&r1=212110&r2=212111&view=diff > ============================================================================== > --- lldb/trunk/include/lldb/lldb-python.h (original) > +++ lldb/trunk/include/lldb/lldb-python.h Tue Jul 1 12:57:19 2014 > @@ -13,22 +13,46 @@ > // Python.h needs to be included before any system headers in order to avoid > redefinition of macros > > #ifdef LLDB_DISABLE_PYTHON > - > // Python is disabled in this build > - > #else > + // If this is a visual studio build > + #if defined( _MSC_VER ) > + // Special case for debug build since python unfortunately > + // adds library to the linker path through a #pragma directive > + #if defined( _DEBUG ) > + // Python forces a header link to python27_d.lib when > building debug. > + // To get around this (because most python packages > for Windows > + // don't come with debug python libraries), we > undefine _DEBUG, include > + // python.h and then restore _DEBUG. > + > + // The problem with this is that any system level > headers included from > + // python.h were also effectively included in > 'release' mode when we undefined > + // _DEBUG. To work around this we include headers > that python includes > + // before undefining _DEBUG. > + # include <stdlib.h> > + // Undefine to force python to link against the > release distro > + # undef _DEBUG > + # include <Python.h> > + # define _DEBUG > + > + #else > + #include <Python.h> > + #endif > + > + #else > + #if defined(__linux__) > + // features.h will define _POSIX_C_SOURCE if > _GNU_SOURCE is defined. This value > + // may be different from the value that Python > defines it to be which results > + // in a warning. Undefine _POSIX_C_SOURCE before > including Python.h The same > + // holds for _XOPEN_SOURCE. > + #undef _POSIX_C_SOURCE > + #undef _XOPEN_SOURCE > + #endif > What about specifying /NODEFAULTLIB:python27_d.lib and then manually link > against python27.lib instead? Seems like a better fix. > > Another problem with this header is that pymath.h on Windows does a check for > HAVE_ROUND, and if it's not found it provides its own implementation of > round(). VS2013 and above provide this function, however. Could you add a > line to the CMake along the lines of: > > if ((NOT MSVC) OR MSVC12) > add_definitions( -DHAVE_ROUND ) > endif() > > > > Modified: lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp > URL: > http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp?rev=212111&r1=212110&r2=212111&view=diff > ============================================================================== > --- lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp (original) > +++ lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp Tue Jul 1 > 12:57:19 2014 > @@ -589,7 +589,12 @@ ScriptInterpreterPython::ExecuteOneLine > input_file_sp = debugger.GetInputFile(); > // Set output to a temporary file so we can forward the > results on to the result object > > +#ifdef _MSC_VER > + // pipe is not supported on windows so default to a fail > condition > + int err = 1; > +#else > int err = pipe(pipe_fds); > +#endif > if (err == 0) > { > std::unique_ptr<ConnectionFileDescriptor> conn_ap(new > ConnectionFileDescriptor(pipe_fds[0], true)); > Windows actually does support pipe, it's just called _pipe and has a slightly > different signature. But I think you can make it work. > > http://msdn.microsoft.com/en-us/library/edze9h7e.aspx > > One more issue is that ScriptInterpreter::TerminateInterpreter() calls > ScriptInterpreterPython::TerminateInterpreter(), which is not defined, so the > function calls itself, leading to an infinite recursion warning. Can we fix > this warning? > _______________________________________________ > lldb-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
