[Lldb-commits] [lldb] r212111 - This creates a valid Python API for Windows, pending some issues. The changes included are -

[Zachary Turner]

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
> -
>  #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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140701/af5c0e52/attachment.html>