[lldb-dev] remote debugging from another platform

[Greg Clayton]

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.

Greg Clayton

> 
> 
> --
> Carlo Kok
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev