[Lldb-commits] [lldb] r212111 - This creates a valid Python API for Windows, pending some issues. The changes included are -
gclayton at apple.com
Tue Jul 1 17:47:30 PDT 2014
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.
> On Jul 1, 2014, at 5:34 PM, Zachary Turner <zturner at google.com> wrote:
> On Tue, Jul 1, 2014 at 10:57 AM, Deepak Panickal <deepak at codeplay.com> 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
> + // 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 )
> 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;
> int err = pipe(pipe_fds);
> if (err == 0)
> std::unique_ptr<ConnectionFileDescriptor> conn_ap(new ConnectionFileDescriptor(pipe_fds, 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.
> 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
> lldb-commits at cs.uiuc.edu
More information about the lldb-commits