# [lldb-dev] debug server help

Greg Clayton gclayton at apple.com
Wed Sep 19 14:50:49 PDT 2012

On Sep 19, 2012, at 2:10 AM, Carlo Kok <ck at remobjects.com> wrote:

> Op 18-9-2012 23:25, Greg Clayton schreef:
>>
>> On Sep 18, 2012, at 1:56 PM, Carlo Kok <ck at remobjects.com> wrote:
>>
>>> Op 18-9-2012 21:54, Carlo Kok schreef:
>>>> Op 18-9-2012 20:06, Greg Clayton schreef:
>>>>> I removed all uses of "%z" modifiers in our printf format strings in
>>>>> top of tree. Merge top of tree over to get the fixes:
>>>>>
>>>>
>>>>
>>>> Thanks for the help Greg (and João Matos). Limited remote debugging
>>>> works now on Windows (after my latest commit), start, continue,
>>>> breakpoint, kill and event handling (Through code only, the driver is
>>>> still not working on Windows).
>>>
>>>
>>> I noticed it transfers about 16mb worth of data (for a single bp on
>>> main in a printf("hello"); sleep() function). What options do I
>>> have to optimize this? It seems to be doing lots of "Read memory"
>>> from within the symbol loading code (and if I kill the process
>>> while it does it it sigsegv-s). I couldn't find a "need symbols for
>>> dylib/file X" event I could hook up to (i can get the files over
>>> and store them locally that way it could load it from disk)
>>
>> Yes, all shared libraries are being read from memory.
>>
>> Platforms do have the ability to set an sysroot:
>>
>> (lldb) platform select --sysroot \path\to\macosx\sysroot
>> remote-macosx
>>
>> If you make a local copy of the shared libraries from your remote Mac
>> OS (copy /usr/bin/* /usr/lib/* /System/Library/Frameworks/*
>> /System/Library/PrivateFrameworks/* and what ever else you neeed)
>> into a local directory like "\path\to\macosx\sysroot", then you wil
>> avoid this issue. So when we go asking for "/usr/lib/dyld" we will
>> look in "\path\to\macosx\sysroot\usr\lib\dyld". This is the real
>> reason we want to have a platform connection: so we can download SDK
>> files and cache them locally. For now we will need to just let it
>> copy stuff.
>>
>> The other way to do this, is ask users to mount the remote MacOSX
>> root partition so that it can be accessed locally. If you enable
>> windows sharing on your remote Mac, you should be able to connect to
>> it, and then just give that path for the "--sysroot". We don't expose
>> the platforms as objects through the public API at the moment, but
>> you can easily just execute the command:
>>
>> m_debugger.HandleCommand ("platform select --sysroot
>> \path\to\macosx\sysroot remote-macosx");
>>
>> m_debugger.CreateTarget(....)
>>
>> Does that make sense?
>>
>
> it does. First i want to try to make this work dynamically though (we have a "server app" like your "remote" host) that has the ability to download files to the computer on demand. I'm thinking I'll subclass "PlatformWindows" and override:

PlatformWindows is not the right thing. This would the right thing for remotely debugging another WindowsPlatform.

We already have PlatformMacOSX which is what you shuld use and modify (when "IsHost() == false" case).

>
>
>
> Error
> PlatformWindows::ResolveExecutable (const FileSpec &exe_file,
>                                    const ArchSpec &exe_arch,
>                                    lldb::ModuleSP &exe_module_sp,
>                                    const FileSpecList *module_search_paths_ptr)

Again, this would be: PlatformMacOSX::ResolveExecutable(). We do have code that already does much of this in our platform branch:

http://llvm.org/svn/llvm-project/lldb/branches/lldb-platform-work

So you need to check there and merge any changes you need from there into your windows branch. There is a lot of functionality that is already done (get/put files, auto caching of SDK in a local directory from the remote host, much much more).

>
> That triggers for each file, and download (if possible) from there.

Yes, again, use the platform branch.

>
> Forcing my users to download all files manually does not sound like a practical option for me.

No it isn't. Use the platform branch and that should give you a good starting point.

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