[lldb-dev] remote debugging from another platform

Carlo Kok ck at remobjects.com
Wed Sep 5 10:08:33 PDT 2012

Op 4-9-2012 21:46, Carlo Kok schreef:
> 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++.

I continued with this to see how far I can get:
With a slight tweak in llvm (to get back the original string from a 
regex class), and a few tweaks over lldb itself the compile progress 
gets pretty far (doesn't compile as is with the patch yet, some of the 
errors I get on Windows stop me from seeing all errors)

SymbolVendorMacOSX.cpp has a dependency on libxml & AvailabilityMacros.h
process.cpp has a lot of platform dependent stuff
platform.cpp depends on getops.h, not sure if this works on windows too 
but it's not standard

replaced the regex with llvms' regex (Requiers a tiny patch in llvm itself)

GDBRemoteCommunicationServer.cpp has a lot of platform dependent stuff
objectcontainerbsdarchive.cpp depends on ar.h (which is missing)

For emulationstatearm.h:
Error	4241	error C2380: type(s) preceding 'sd_regs' (constructor with 
return type, or illegal redefinition of current class-name?) 
lldb\source\plugins\instruction\arm\emulationstatearm.h	90	1	lldb
which causes like 100 follow-up errors.

DisassemblerLLVMC.cpp depends on regex.h (c style); probably can be 
ported to llvm regex or llvm's internal_regex stuff, which seem to match 
in the apis.

Abstracting everything in a windows/ specific folder does not look like 
it's very practical, __attribute__ isn't even supported in VC++ and used 
all over the place.

That said, I think I can get this all working so at the very least 
remote debugging from windows to other platforms works, maybe with some 
help on the issues above.

Carlo Kok

-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_patch.zip
Type: application/x-zip-compressed
Size: 17197 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20120905/7bf56428/attachment.bin>

More information about the lldb-dev mailing list