[lldb-dev] debug server help

[Greg Clayton]

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