[lldb-dev] remote debugging from another platform

[Carlo Kok]

Op 4-9-2012 21:43, Greg Clayton schreef:
>
> On Sep 4, 2012, at 12:38 PM, Carlo Kok <ck at remobjects.com> wrote:
>
>> Op 4-9-2012 21:35, Carlo Kok schreef:
>>> Op 4-9-2012 16:46, Greg Clayton schreef:
>>>>
>>>> On Sep 3, 2012, at 12:32 PM, Carlo Kok <ck at remobjects.com> wrote:
>>>>
>>>>> Op 27-8-2012 19:16, Greg Clayton schreef:
>>>>>> Yes it can, but work is definitely needed. Linux to OSX will work
>>>>>> because we have the lldb modified "debugserver" binary which can
>>>>>> debug macosx apps. There is no linux equivalent because the current
>>>>>> "debugserver" binary was initially made for the Mac only and it isn't
>>>>>> well orgnanized to be used as a starting point for porting to other
>>>>>> systems.
>>>>>>
>>>>>> What I would like see happen, is in our Host layer (in
>>>>>> "lldb/source/Host" and "lldb/include/lldb/Host"), we should have a
>>>>>> native debug API that is very closely based on
>>>>>> "lldb/tools/debugserver/source/DNB.h" and name it something like
>>>>>> "lldb_private::NativeDebug". Once we do this, we can then support
>>>>>> native debugging on every platform by making a new Process plugin in
>>>>>> "lldb/source/Plugins/Process" called "Host" which would link against
>>>>>> the new API in the lldb_private::NativeDebug. We then also have
>>>>>> classes which implement remote GDB debugging inside lldb:
>>>>>>
>>>>>> lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
>>>>>> lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Are there any technical limitations that keep these from working on
>>>>> windows (the client side of things, not the host)? (I tried to import
>>>>> it but there are a lot of missing include files which i presume is
>>>>> just because nobody ever did this and it's just missing defines).
>>>>
>>>> We have a host layer in our code that is designed to abstract you from
>>>> the OS your are running on, though I am sure it is far from perfect.
>>>> One of the big challenges in making a windows port will be correctly
>>>> implementing an abstraction layer that makes sense.
>>>>
>>>> Does anyone else have any experience and comments for Windows? I seem
>>>> to remember a few folks working on windows over that past year.
>>>>
>>>> Greg Clayton
>>>>
>>>
>>> There are quite a few places that presume unix (like spawn.h,
>>> pthread.h); the patch attached has some small tweaks for this but is far
>>> from complete. Atm I'm stuck with regex.h (completely missing on vc++)
>>> and a read/write lock primitive (readwritelock.h wants it). Win32
>>> doesn't seem to have an equivalent.
>>
>> Hmm rest got cut off.
>>
>> What I wanted to ask here is, is this the right way to go about this? (it's not a proper patch).
>
> There are two ways that I see:
> 1 - completely hide everything in the host layer, no unix headers anywhere that isn't in the host code.
> 2 - require that a posix compliant unix layer is needed. I believe windows has cygwin and a a few other *nix variants that can be installed.
>
> As far as the regular expression stuff goes, I believe llvm/clang have a regex implementation built in. We could switch over to using that.
>

If at all possible, avoiding the posix later (cygwin) would be good; 
llvm/clang don't need it either. Esp as cygwin does not work well with 
VC++.