debugging ios-simul speed issue

I have a rather strange issue on some computers when (remote debugging from Windows) to iOS. I have a 5 second "gap" in the log file where it does nothing after just having finished loading the (what I hope/presume) is the MACH-O headers of libresolv.dylib.

1364376978.867000 163A0E38 ConnectionFileDescriptor::Read () ::read (fd = 5936, dst = 140ECA60, dst_len = 8192) => 6, error = (null)

1364376983.577000 08CD3898 Communication::Write (src = 140EE4E0, src_len = 14) connection = 163A0E38

I'm hoping someone can give a hint as to where I can start looking for this delay. (Unrelated, does it really need to load all these files at all if they're not used during debugging?)

Relevant part of the log file:
http://pastebin.com/EcHxfaeY

Full log file:
https://dl.dropbox.com/u/29927944/FullLog.txt

(note that the paths are all strange due to how I resolve this on windows, they do load/exist just file).

You will need to sample the application that is running LLDB (MSVC?) to see what it is doing. This delay happens _after_ a read and before the next write, so the program is up to something in between there.

Op 27-3-2013 23:28, Greg Clayton schreef:

You will need to sample the application that is running LLDB (MSVC?) to see what it is doing. This delay happens _after_ a read and before the next write, so the program is up to something in between there.

I did; one of the biggest slowdowns seems to be due to my "exception breakpoint":

self->m_target.BreakpointCreateForException(lldb::eLanguageTypeObjC, false, true);

When set, after libresolv.dylib got loaded, it loads the DWARF symbols for all referenced libraries then tries to find "objc_exception_throw",

Setting a BP in :
void
Breakpoint::ResolveBreakpointInModules (ModuleList &module_list)
{
     if (m_resolver_sp)
         m_resolver_sp->ResolveBreakpointInModules(*m_filter_sp, module_list);
}

the "ResolveBerakpointInModules" takes 6 seconds (for 120 modules)

If i press pause i get a callstack like:
msvcr100d.dll!unaligned_memcmp(const unsigned char * bLHS, const unsigned char * bRHS, unsigned int siz) + 0xcf bytes C
msvcr100d.dll!memcmp(const void * lhs, const void * rhs, unsigned int siz) + 0x19c bytes C
llvm::StringRef::compareMemory(const char * Lhs, const char * Rhs, unsigned int Length) Line 65 + 0x11 bytes C++
llvm::StringRef::equals(llvm::StringRef RHS) Line 131 + 0x1e bytes C++
llvm::operator==(llvm::StringRef LHS, llvm::StringRef RHS) Line 516 C++
llvm::StringMapImpl::LookupBucketFor(llvm::StringRef Name) Line 97 + 0x29 bytes C++
llvm::StringMap<char const *,llvm::BumpPtrAllocator>::GetOrCreateValue<char const *>(llvm::StringRef Key, const char * Val) Line 350 + 0x10 bytes C++
Pool::GetConstCStringWithLength(const char * cstr, int cstr_len) Line 96 + 0x15 bytes C++
Pool::GetConstCString(const char * cstr) Line 85 + 0x19 bytes C++
lldb_private::ConstString::ConstString(const char * cstr) Line 212 + 0x1e bytes C++
ObjectFileMachO::ParseSymtab(bool minimize) Line 2922 + 0x12 bytes C++
ObjectFileMachO::GetSymtab() Line 744 C++
SymbolFileSymtab::CalculateAbilities() Line 89 + 0x15 bytes C++
lldb_private::SymbolFile::GetAbilities() Line 96 + 0xf bytes C++
lldb_private::SymbolFile::FindPlugin(lldb_private::ObjectFile * obj_file) Line 39 + 0xf bytes C++
lldb_private::SymbolVendor::AddSymbolFileRepresentation(const std::tr1::shared_ptr<lldb_private::ObjectFile> & objfile_sp) Line 99 + 0xe bytes C++
lldb_private::SymbolVendor::FindPlugin(const std::tr1::shared_ptr<lldb_private::Module> & module_sp, lldb_private::Stream * feedback_strm) Line 63 + 0x1f bytes C++
lldb_private::Module::GetSymbolVendor(bool can_create, lldb_private::Stream * feedback_strm) Line 780 + 0x19 bytes C++
lldb_private::Module::FindFunctions(const lldb_private::ConstString & name, const lldb_private::ClangNamespaceDecl * namespace_decl, unsigned int name_type_mask, bool include_symbols, bool include_inlines, bool append, lldb_private::SymbolContextList & sc_list) Line 589 + 0x13 bytes C++
lldb_private::BreakpointResolverName::SearchCallback(lldb_private::SearchFilter & filter, lldb_private::SymbolContext & context, lldb_private::Address * addr, bool containing) Line 179 + 0x38 bytes C++
lldb_private::LanguageRuntime::ExceptionBreakpointResolver::SearchCallback(lldb_private::SearchFilter & filter, lldb_private::SymbolContext & context, lldb_private::Address * addr, bool containing) Line 153 + 0x2e bytes C++
lldb_private::SearchFilter::DoModuleIteration(const lldb_private::SymbolContext & context, lldb_private::Searcher & searcher) Line 198 + 0x1b bytes C++
lldb_private::SearchFilter::DoModuleIteration(const std::tr1::shared_ptr<lldb_private::Module> & module_sp, lldb_private::Searcher & searcher) Line 185 + 0x10 bytes C++
lldb_private::SearchFilter::SearchInModuleList(lldb_private::Searcher & searcher, lldb_private::ModuleList & modules) Line 173 + 0x13 bytes C++
lldb_private::BreakpointResolver::ResolveBreakpointInModules(lldb_private::SearchFilter & filter, lldb_private::ModuleList & modules) Line 53 + 0x17 bytes C++
lldb_private::Breakpoint::ResolveBreakpointInModules(lldb_private::ModuleList & module_list) Line 341 + 0x2d bytes C++
lldb_private::Breakpoint::ModulesChanged(lldb_private::ModuleList & module_list, bool load, bool delete_locations) Line 420 C++
lldb_private::BreakpointList::UpdateBreakpoints(lldb_private::ModuleList & module_list, bool added) Line 213 + 0x21 bytes C++
lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList & module_list) Line 1136 C++
DynamicLoaderMacOSXDYLD::AddModulesUsingImageInfos(std::vector<DynamicLoaderMacOSXDYLD::DYLDImageInfo,std::allocator<DynamicLoaderMacOSXDYLD::DYLDImageInfo> > & image_infos) Line 938 C++
DynamicLoaderMacOSXDYLD::AddModulesUsingImageInfosAddress(unsigned __int64 image_infos_addr, unsigned int image_infos_count) Line 836 + 0xc bytes C++
DynamicLoaderMacOSXDYLD::InitializeFromAllImageInfos() Line 1109 + 0x23 bytes C++
DynamicLoaderMacOSXDYLD::NotifyBreakpointHit(void * baton, lldb_private::StoppointCallbackContext * context, unsigned __int64 break_id, unsigned __int64 break_loc_id) Line 641 + 0x8 bytes C++
lldb_private::BreakpointOptions::InvokeCallback(lldb_private::StoppointCallbackContext * context, unsigned __int64 break_id, unsigned __int64 break_loc_id) Line 150 + 0x4c bytes C++
lldb_private::Breakpoint::InvokeCallback(lldb_private::StoppointCallbackContext * context, int bp_loc_id) Line 322 C++
lldb_private::BreakpointLocation::InvokeCallback(lldb_private::StoppointCallbackContext * context) Line 208 C++
lldb_private::BreakpointLocation::ShouldStop(lldb_private::StoppointCallbackContext * context) Line 340 + 0xc bytes C++
lldb_private::BreakpointLocationCollection::ShouldStop(lldb_private::StoppointCallbackContext * context) Line 144 + 0x2d bytes C++
lldb_private::BreakpointSite::ShouldStop(lldb_private::StoppointCallbackContext * context) Line 66 C++
lldb_private::StopInfoBreakpoint::ShouldStopSynchronous(lldb_private::Event * event_ptr) Line 163 + 0x2a bytes C++
lldb_private::thread::ShouldStop(lldb_private::Event * event_ptr) Line 602 + 0x34 bytes C++

(top part varies, but it always has GetSymtab in it.)

I haven't found a sampling profiler that works yet so I don't know how to get much more info from this yet. Is there any chance this is long optimized and I'm just behind on revisions on the Windows branch?

We recently did fix the exception breakpoints for Apple targets to only look in 2 shared libraries, but this cost is just going to push this delay a little further down the road until the next expression or other global query causes the shared libraries to each be queried.

Are you still having LLDB read all shared libraries from memory on every debug session? If you don't have local copies of the iOS SDK on your window machine, then yes, this is happening every time you debug and will continue to cause a slowdown. I would recommend trying to solve this issue as this will get you the greatest speed improvements. When running LLDB, you can currently select the "remote-ios" platform like:

(lldb) platform selecte remote-ios --sysroot /path/to/SDK/root

"/path/to/SDK/root" should contain "System/Library/Frameworks/*.framework", "/usr/lib/*", and everything else that is in the SDK on the Mac.

Op 28-3-2013 20:53, Greg Clayton schreef:

We recently did fix the exception breakpoints for Apple targets to
only look in 2 shared libraries, but this cost is just going to push
this delay a little further down the road until the next expression
or other global query causes the shared libraries to each be
queried.

Indeed. Same problem happens for "regular" breakpoints.

Are you still having LLDB read all shared libraries from memory on
every debug session? If you don't have local copies of the iOS SDK on
your window machine, then yes, this is happening every time you debug
and will continue to cause a slowdown. I would recommend trying to
solve this issue as this will get you the greatest speed
improvements. When running LLDB, you can currently select the
"remote-ios" platform like:

I have them locally now and use a trick like this (I override the WindowsPlatform class and override:
lldb_private::Error
     MyPlatformWindows::GetSharedModule (const lldb_private::ModuleSpec &module_spec,
                     lldb::ModuleSP &module_sp,
                     const lldb_private::FileSpecList *module_search_paths_ptr,
                     lldb::ModuleSP *old_module_sp_ptr,
                     bool *did_create_ptr)

Making it load with the new path. Pretty much the same thing as the sysroot would do except that I get notified over which files I need and I can download them on the fly (saving them). Loading them from memory was way too slow yes, takes over a minute to load them all.