On Sep 19, 2012, at 2:10 AM, Carlo Kok <[email protected]> wrote: > Op 18-9-2012 23:25, Greg Clayton schreef: >> >> On Sep 18, 2012, at 1:56 PM, Carlo Kok <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
