[lldb-dev] debug server help
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
>> 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");
>> 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).
> 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:
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
More information about the lldb-dev