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

[Todd Fiala]

Looking at this now.


On Tue, Jul 1, 2014 at 5:54 PM, Zachary Turner <zturner at google.com> wrote:

> Sorry, I'm used to using -U999999 for Phab.  Here's a more compact diff.
>
>
> On Tue, Jul 1, 2014 at 5:53 PM, Zachary Turner <zturner at google.com> wrote:
>
>> Here's a patch that fixes all the stuff I've found so far (except the
>> CMake warning, haven't looked at that).  Don't want to commit it yet
>> without you looking at it first though, so PTAL.
>>
>>
>> On Tue, 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
>>>> -
>>>>  #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
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140702/ff513238/attachment.html>