[lldb-dev] LLDB /w Windows and MinGW64

Mon Mar 28 10:58:19 PDT 2016

If you compile with MSVC or Clang-cl it wouldn't ask for lldb-server.  So
most likely there is some code that is using #if defined(_MSC_VER) when it
should be using #if defined(LLVM_ON_WINDOWS).

You'll have to hunt that down, but a good starting point might be to put a
breakpoint in ProcessWindowsLive::CreateInstance and then work backwards to
see why that isn't getting called (assuming it's not).

On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah <eran.ifrah at gmail.com> wrote:

> On Mon, Mar 28, 2016 at 6:56 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> Patches welcome. If you can split it into independent pieces that would
>> be helpful, but it's not always possible.
>>
>> Patch is attached, I think you will find it quite straight forward - feel
> free to comment and send it back for revise
> 
>
>
>> The NativeProcessProtocol error, that's the interface that converts
>> debugging events that occur on the inferior into packets that can be sent
>> to the server, and vice versa. Since Windows doesn't currently use lldb
>> server, this piece has never been written for Windows
>
> So this raises the question: how come lldb asks for it? (see my first
> emai inl this conversation)
> I would have build LLDB in debug mode, but it seems that MinGW as.exe
> fails to write some of the files "File too big"
> 
>
>
>>
>> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah <eran.ifrah at gmail.com> wrote:
>>
>>> On Mon, Mar 28, 2016 at 6:10 PM, Zachary Turner <zturner at google.com>
>>> wrote:
>>>
>>>> I'm the main Windows maintainer,
>>>
>>> Hi
>>> 
>>>
>>>
>>>> and while We've gotten things working pretty well on Windows, our
>>>> effort has been 100% on building with msvc and/or clang-cl. Building with
>>>> mingw has a different set of pre processor defines and some other subtle
>>>> differences, so it doesn't surprise me that things don't work quite right.
>>>>
>>>> I got it to compile (I have a big patch that I can send you if you are
>>> interested)
>>> mainly involves blocking code under __MINGW32__ and some updates to the
>>> various CMakeLists.txt and AddLLDB.cmake module files
>>> Some functions are missing in MinGW implementations (like gets_s and
>>> others :/)
>>> 
>>>
>>>
>>>> You can try getting lldb-server to build and run under Windows, or you
>>>> can try to get it to use the non lldb server codepath on MinGW, but you may
>>>> still run into some
>>>
>>> I got lldb-server to compile and run on Windows, however, it crashes
>>> immediately and the backtrace shows this:
>>>
>>> 0  0x0000000000724615
>>>  lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
>>> lldb_private::NativeProcessProtocol::NativeDelegate&,
>>> lldb_private::MainLoopBase&,
>>> std::shared_ptr<lldb_private::NativeProcessProtocol>&)
>>> 1  0x00000000005f815d
>>>  lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>>>
>>> 2  0x00000000004020e5
>>>  handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
>>> int, char const* const*)
>>> 3  0x000000000040335e  main_gdbserver(int, char**)
>>> 4  0x000000000188329c  main
>>>
>>>
>>> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains too
>>> much Linux code that can not be compiled under Windows (fork, exec*)
>>> and basically lldb-server calls the main_gdbserver instead of
>>> main_platform function
>>>
>>> Looking at the function that crashes, I see this:
>>>
>>> llvm_unreachable("Platform has no NativeProcessProtocol support");
>>>
>>> Any ideas?
>>> Thanks!
>>>
>>> issues after that as well, since you're the first person afaik to try
>>>> building with MinGW
>>>>
>>>
>>>
>>>> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
>>>> lldb-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort
>>>>> to get the job done...)
>>>>> When I tried to debug a simple hello world executable, I get this
>>>>> output:
>>>>>
>>>>> D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
>>>>> HelloWorld.exe
>>>>> (lldb) target create "HelloWorld.exe"
>>>>> Current executable set to 'HelloWorld.exe' (x86_64).
>>>>> (lldb) b main.cpp:7
>>>>> Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address
>>>>> = 0x000000000040154a
>>>>> (lldb) r
>>>>> error: process launch failed: unable to locate lldb-server
>>>>> (lldb)
>>>>>
>>>>> I can't seem to locate lldb-server anywhere, and according
>>>>> to LLDBConfig.cmake, this target should not get built on Windows:
>>>>>
>>>>> # Figure out if lldb could use lldb-server.  If so, then we'll
>>>>> # ensure we build lldb-server when an lldb target is being built.
>>>>> if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR
>>>>>     (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR
>>>>>     (CMAKE_SYSTEM_NAME MATCHES "Linux") OR
>>>>>     (CMAKE_SYSTEM_NAME MATCHES "NetBSD"))
>>>>>     set(LLDB_CAN_USE_LLDB_SERVER 1)
>>>>> else()
>>>>>     set(LLDB_CAN_USE_LLDB_SERVER 0)
>>>>> endif()
>>>>>
>>>>> and in the tools/CMakeLists.txt file we have this:
>>>>>
>>>>> if (LLDB_CAN_USE_LLDB_SERVER)
>>>>>   add_subdirectory(lldb-server)
>>>>> endif()
>>>>>
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> Eran Ifrah,
>>>>> Author of
>>>>> CodeLite
>>>>> , a cross platform open source C/C++ IDE: http://www.codelite.org
>>>>> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>
>>>>
>>>
>>>
>>> --
>>> Eran Ifrah,
>>> Author of codelite, a cross platform open source C/C++ IDE:
>>> http://www.codelite.org
>>> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>>>
>>
>
>
> --
> Eran Ifrah,
> Author of codelite, a cross platform open source C/C++ IDE:
> http://www.codelite.org
> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160328/dd35fa0d/attachment.html>